IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Microsoft rend open source Checked C, une version du langage C
Qui permet aux développeurs d'écrire des programmes C plus sécurisés et fiables

Le , par Michael Guilloux

96PARTAGES

11  0 
Une bonne partie du système logiciel existant, qu’il s’agisse des systèmes d'exploitation, des navigateurs, des bases de données ou encore des interprètes de langage de programmation, repose sur le langage C ou sur C++, qui lui-même est basé sur C.

Mais comme l’explique Microsoft dans un billet de blog, il y a certains types d'erreurs de programmation tels que les dépassements de mémoire tampon que les programmeurs peuvent faire pendant qu’ils écrivent des programmes C ou C++ ; lesquelles erreurs pouvant conduire à des failles de sécurité ou des problèmes de fiabilité du logiciel.

Pour s’attaquer à ce problème et pour permettre aux développeurs d’écrire des programmes C plus sécurisés et plus fiables, Microsoft a donc commencé le développement de Checked C. Il s’agit d’une extension du langage C qui permettra aux développeurs d'ajouter un contrôle statique et dynamique à leurs programmes. Cela, dans le but de détecter ou éviter les erreurs de programmation courantes telles que les dépassements de mémoire tampon entre autres. Checked C pourra donc être utilisé avec des programmes en cours d’exécution ou pendant qu'ils sont en cours d'écriture.

Microsoft Research rend maintenant son projet open source pour permettre aux chercheurs et aux développeurs de contribuer à la spécification et à l'implémentation du compilateur sur GitHub.

Ce qu’il est important de noter, c’est que Checked C devrait être compatible avec les programmes C existants, dans la mesure où les changements introduits par le langage open source n’invalident pas le code C existant. Microsoft souligne en effet que les programmes C existants « peuvent être modifiés de manière incrémentielle d’une manière rétrocompatible pour avoir ce contrôle » offert par Checked C. Ainsi, les développeurs n’auront pas besoin de convertir tout leur programme en même temps. Selon leur choix, ils pourront convertir leur code fichier par fichier ou fonction par fonction. Cela en soi donne un grand avantage à Checked C qui pourrait inciter les développeurs à l’adopter une fois qu’il sera officiellement disponible.

En ce qui concerne la chaine d’outils pour accompagner Checked C, il faut noter que Microsoft travaille également sur l’implémentation d’une version de LLVM/clang modifiée pour supporter l’extension open source du langage C. Checked C et sa spécification sont disponibles sur GitHub.

Sources : Microsoft Research, Dépôt Checked C, Dépôt LLVM pour Checked C, Dépôt clang pour Checked C

Et vous ?

Que pensez-vous de ce nouveau projet open source de Microsoft ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/06/2016 à 21:50
Citation Envoyé par Grogro Voir le message
Pour un développeur java qui n'a pas touché au C depuis la L2 de fac (et encore, une fac de physique ), et qui n'a pas la moindre idée des problématiques de gestion de la mémoire, vous pouvez résumer les difficultés du C ?
Ca va être dur de faire un cours de sécurité en un message mais le principaux problèmes qui me viennent en tête sont:
  • Le dépassement de mémoire : En gros dans un tableau de taille 10, on essaie d'écrire le 11eme élément. On va donc écrire dans une zone mémoire située après le tableau qui n'a rien a voir et qui si ça ne plante pas va probablement provoquer des comportement incohérents du programme qui peuvent mener a une faille de sécurité.
  • L'utilisation après libération : Quand on a besoin de mémoire on la réserve et on obtient un pointeur vers la zone mémoire. Une fois libérée cette mémoire peut-être ré-allouée ailleurs. Donc si on continue à utiliser l'ancien pointeur on va avoir deux pointeurs qui pointent vers une même zone pour faire des choses qui n'ont rien à voir. La encore le programme devient imprévisible et des faille sont souvent a la clé
  • La double libération. Quand on essaie de libérer une zone mémoire déjà libérée, on a au mieux un plantage mais il peut se passer tout un tas de chose bizarres. Par exemple on peut désallouer la zone mémoire qui avait été ré-allouée entre temps, provoquant une utilisation après libération à l'autre bout du programme.
  • Les comportements non définis. De nombreux points de la spécification du C sont volontairement non définis et laissent le compilateur libre de faire ce qu'il veux. Il vaut mieux les éviter au risque de se retrouver avec des comportements imprévisibles suivant les envies d'optimisation du compilateur.

Certaines de ces erreurs peuvent te paraître grossières quand on les explique simplement, mais je te garantis que dans les programmes complexes, il est bien plus facile qu'on ne le croit de les faire sans que ce soit évident a détecter.
9  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/06/2016 à 14:02
Citation Envoyé par Ph. Marechal Voir le message
"...il y a certains types d'erreurs de programmation tels que les dépassements de mémoire tampon que les programmeurs peuvent faire pendant qu’ils écrivent des programmes C..." : autant apprendre à bien utiliser C ainsi qu'un bon compilateur / débogueur, c'est une tâche passionnante que d'apprendre à corriger ses erreurs !
C'est peut-être passionnant a déboguer pour toi, mais c'est surtout un risque de comportements anormaux, ou même de failles de sécurité, si ça n'est pas détecté. Et dire "Y'a qu'a bien faire", c'est bien beau, mais tant que les humains seront faillibles, ça n'est clairement pas la solution.
C'est quelque chose qui peux parfois être très vicieux et même les meilleurs peuvent se faire avoir.

Citation Envoyé par Ph. Marechal Voir le message
Chaque multinationale veut créer son propre petit langage / framework ou autre machine virtuelle, curieusement elles utilisent C pour ce faire
Ce n'est plus systématique.
Par exemple le compilateur Go est maintenant entièrement écrit en Go. Le compilateur Rust était en OCaml avant d'être réécrit en Rust avec une base LLVM (en C++)

Citation Envoyé par Ph. Marechal Voir le message
C est un langage magnifique par ses performances et la liberté qu'il offre et valgrind est un vieux copain.
C'est tout le problème du C. Il est tellement omniprésent qu'il est systématiquement utilisé pour le bas niveau malgré ses défauts, parce que la plupart des gens qui font du bas niveau ne connaissent que ça, ce qui entretient son omniprésence.
Du coup plutôt que d’empêcher les erreurs en amont, on accumule les outils permettant de limiter la casse.
8  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/06/2016 à 10:27
Citation Envoyé par MagnusMoi Voir le message
So what ?

Just do it yourself !
Si c’était aussi simple que ça ça fait longtemps que les erreur mémoires en C auraient disparu, si on veut vraiment sécuriser le C il faut faire bien plus. Y'a qu'a voir tous les mécanismes qu'a du introduire le langage Rust pour arriver a faire ça sans Garbage Collector.
Je suis curieux de voir comment Microsoft compte s'y prendre en restant sur une base aussi peut adaptée à la sécurité que le C. J'ai pas encore lu les specs (saleté de format Latex), mais j'ai l'impression que ça va être bien loin de ce que propose Rust.

Citation Envoyé par Ph. Marechal Voir le message
Autant C est beau
On va dire que l'amour est aveugle alors.
4  0 
Avatar de Grogro
Membre extrêmement actif https://www.developpez.com
Le 21/06/2016 à 10:05
Pour un développeur java qui n'a pas touché au C depuis la L2 de fac (et encore, une fac de physique ), et qui n'a pas la moindre idée des problématiques de gestion de la mémoire, vous pouvez résumer les difficultés du C ?
2  0 
Avatar de AoCannaille
Expert confirmé https://www.developpez.com
Le 10/09/2018 à 18:07
Citation Envoyé par transgohan Voir le message

Un coup de Valgrind et de Sonar suffit par exemple à détecter toutes les erreurs citées par Uther.
Dans une chaîne de développement je ne vois pas pourquoi on aurait l'absence de ce genre d'outil (ce serait comme dire qu'on n'utilise pas de gestion de conf), du coup pourquoi vouloir combler un trou qui est déjà comblé ?
Bien que je sois d'accord avec la necessité de ces outils, le fait est qu'ils restent des rustines correctives nécessaires pour éviter des erreurs dues, selons les points de vues, soit à des défauts du langages, soit à l'incompétence du développeur.

Selon moi la performance du C vient en partie grâce à ces défauts et utiliser ces outils est selon moi la bonne solution.

Il n’empêche qu'ils ne corrigent pas les problèmes cités.

Pour moi si vous voulez éviter ce genre de problème à la compilation, il ne faut pas choisir le C, mais plus l'ADA par exemple...
2  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 10/09/2018 à 17:00
J'en pense que ce n'est pas forcément utile.
On trouve tout le confort nécessaire avec des outils d'analyse statique ou dynamique.
Un coup de Valgrind et de Sonar suffit par exemple à détecter toutes les erreurs citées par Uther.
Dans une chaîne de développement je ne vois pas pourquoi on aurait l'absence de ce genre d'outil (ce serait comme dire qu'on n'utilise pas de gestion de conf), du coup pourquoi vouloir combler un trou qui est déjà comblé ?
2  1 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 10/09/2018 à 18:53
Citation Envoyé par AoCannaille Voir le message
Pour moi si vous voulez éviter ce genre de problème à la compilation, il ne faut pas choisir le C, mais plus l'ADA par exemple...
Pour moi l'intérêt n'est pas d'éviter ce genre de problème à la compilation mais à la livraison.
Après toutes les méthodes sont bonnes avec certaines plus coûteuses que d'autres.
Mais introduire un nouveau langage ne supprimera pas les outils que j'ai cité, donc c'est redondant pour moi.
1  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 10/09/2018 à 20:14
Aujourd'hui, les intérêts du langage C sont qu'il est performant, interopérable, portable et stable. Si le langage C n'évolue quasiment pas, c'est pour rester portable et stable.

Si on veut un langage rétrocompatible avec le C, performant et qui évolue, ce langage existe déjà : c'est le C++.
À quelques rares incompatibilités près (par exemple, en C, void* est implicitement convertible en tout type de pointeur), du code écrit en C compile en C++. Donc il n'y a pas beaucoup d'efforts à fournir pour que du code C compile à la fois en C et en C++.
Il existe bien quelques rares fonctionnalités du C qui n'existent pas en C++ officiel, par exemple le mot-clef restrict de C99. Mais, si on utilise un compilateur comme GCC, on peut choisir d'écrire dans un C++ étendu avec les quelques fonctionnalités spécifiques au C.
Toujours avec GCC, on peut supprimer l'overhead ajouté par le C++, par exemple avec des options comme -fno-exceptions (pour désactiver la gestion des exceptions).
Une fois qu'on a un code qui compile à la fois en C et en C++, on peut migrer progressivement vers le C++.

Sur la page Extension overview du Wiki sur le Checked C, j'ai regardé rapidement les liens donnés par la section More information et je ne vois pas de vrai intérêt du Checked C par rapport au C++ : parmi ce que j'ai lu, toutes les fonctionnalités présentées en Checked C peuvent être implémentées sous la forme d'une simple bibliothèque C++ grâce aux templates et à la surchage d'opérateurs.

Donc j'ai l'impression que le seul intérêt du Checked C est de ne pas avoir à apprendre le C++.

À part ça, si on veut faire de la programmation bas niveau avec de bons contrôles à la compilation, il faut se tourner vers Rust. Mais du code écrit en C ne compilera pas en Rust. Il faudra alors interfacer du Rust et du C.

Citation Envoyé par AoCannaille Voir le message
Selon moi la performance du C vient en partie grâce à ces défauts et utiliser ces outils est selon moi la bonne solution.
Je t'invite à jeter un œil au langage Rust. Tu constateras que la majorité des défauts du C viennent plus d'un problème de conception que d'un besoin de performance.
Pour être honnête, il y a bien des cas en Rust où il faut choisir entre la performance et la robustesse. Mais il y a beaucoup de cas où on peut bénéficier des deux à la fois.
1  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 13/09/2018 à 8:51
Citation Envoyé par Uther Voir le message
Les outils d'analyse dynamique sont très utiles mais c'est loin d'être aussi complet que ce que permet l'analyse statique d'un langage qui s'y prête bien comme Rust (Ada aussi, mais je vais plutôt parler de Rust que je connais mieux).
Ces outils se contentent de détecter les cas d'erreurs quand ils se produisent. C'est un grand progrès par rapport a pas d'analyse du tout, mais ils ne peuvent pas garantir que tous les cas d'utilisation ont été couverts.
Sonar est un outil d'analyse statique.
1  0 
Avatar de Guntha
Membre expérimenté https://www.developpez.com
Le 17/06/2016 à 10:00
Citation Envoyé par MagnusMoi Voir le message
Autant j'aime bien Microsoft, autant là où est l'intérêt ?

Si tu fait du C et que tu as peur des dépassements mémoires, ou de mal gérer la mémoire :
=> tu te fais ta structure pour stocker un pointeur et la taille allouée
=> tu te crées une liste global d'instance de cette structure
=> tu te crées une fonction "find" sur une liste de cette structure pour trouver l'index d'un pointeur
=> tu te crées une fonction "getsizeof" appelant celle "find" pour obtenir la taille alloué à un pointeur
=> tu te crées une fonction "Mon_malloc" appelant malloc et stockant le pointeur dans une instance de structure, elle même mise dans la liste globale
=> tu te crées une fonction "Is_alloc" appelant ta fonction "find" sur la liste global, retournant 0 ou 1
=> tu te crées une fonction "Mon_free" appelant ta fonction "find" sur la liste global, et qui si il trouve le pointeur, le retire (retire la structure le contenant) de la liste globale, puis le détruit avec "free"
=> tu te crées une fonction "clear_all" appelant qui supprime tous les pointeurs de la liste global (évidemment, on ne l'utilise que en fin de programme !!!)
Du coup quand tu alloues ou veux vérifier un pointeur pas de soucie !
Est-ce long à coder et mettre en place ?
nope !
Et puis-je le mettre dans une bibliothèque ?
Yep !

So what ?

Just do it yourself !
Ça, ça détecte les fuites, mais pas les corruptions, qui dans certains cas pourraient être détectées facilement à la compilation (genre dans le cas d'un tableau de taille statique; Java le fait d'ailleurs).
0  0