Discussion :

[Michael Guilloux]

Microsoft rend open source Checked C, une version modifiée du langage C
Conçue pour permettre aux développeurs d’écrire des programmes C plus sécurisés et fiables

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 ?

[MagnusMoi]

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 !

[Ph. Marechal]

Autant C est beau que Microsoft est laid
Au risque de me faire ésharpé !

[Guntha]

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).

[Uther]

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.

Autant C est beau

On va dire que l'amour est aveugle alors.

[Ph. Marechal]

"...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 !
Chaque multinationale veut créer son propre petit langage / framework ou autre machine virtuelle, curieusement elles utilisent C pour ce faire
C est un langage magnifique par ses performances et la liberté qu'il offre et valgrind est un vieux copain.

[Uther]

"...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.

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++)

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.

[Grogro]

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 ?

[Médinoc]

Et pendant ce temps-là, on attend toujours C99, sans parler de C11...

[Uther]

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.

[Christian Olivier]

Microsoft publie un document décrivant les progrès réalisés dans le cadre du projet Checked C
Visant à rendre le développement sous C plus sûr

Une bonne partie de l’environnement logiciel existant (navigateurs, bases de données, interprètes de langage de programmation ou systèmes d’exploitation pour ne citer que ceux-là) repose toujours sur le C, un langage de programmation qui a fait son apparition dans les années 70 et qui est à la base de nombreux autres langages tels que le C++ et le C #.

En 2016, Microsoft a lancé une initiative qui, à terme, devait permettre de rendre le développement sous C plus fiable et plus sûr. Baptisé Checked C, cette initiative visait l’introduction d’une nouvelle extension du langage C qui serait rétro compatible et intègrerait des outils de vérifications et des garde-fous afin de limiter la survenue d’erreurs durant les phases de développement et l’apparition ultérieure de bogues et/ou de vulnérabilités au sein des logiciels codés en C.

Microsoft a récemment publié un document décrivant les progrès réalisés par ses équipes dans le cadre de son projet visant à rendre le développement sous C plus fiable et plus sûr. Il sera présenté lors de la conférence sur le développent et la cybersécurité de l’IEEE (IEEE SecDev) qui sera organisé du 30 septembre au 2 octobre 2018 à Cambridge, aux États-Unis.

Ce document confirme que Checked C permettra aux développeurs d’ajouter un contrôle statique et dynamique à leurs programmes pour les aider à déceler plus rapidement ou à éviter les erreurs de programmation courantes telles que le « buffer overflow » (les dépassements de mémoire tampon) ou les erreurs de conversion de type d’objets.

Il révèle ainsi qu’afin de garantir un meilleur contrôle sur les pointeurs, Checked C utilise une forme de pointeur vérifié, dont les accès peuvent être vérifiés statiquement ou dynamiquement. Checked C a été conçu comme une extension du compilateur Clang/LLVM et devrait introduire les notions de « checked region » et « bounds-safe interfaces ». Signalons au passage que les programmes codés en C pourront être convertis vers Checked C de manière progressive, fonction par fonction, grâce à la conversion incrémentielle.

Checked C proposera aussi des outils permettant de procéder à des vérifications durant l’écriture du code source, avant que celui-ci ne soit compilé et exécuté.

Source : Checked C (PDF)

Et vous ?

Qu’en pensez-vous ?

[pboulanger]

Une bonne façon de résoudre une grande partie des problèmes serait de:
- ajouter un typage "array of" comme il y avait en pascal pour retirer l'ambiguïté entre pointeur sur un élément et pointeur sur tableau
- rajouter les références pour diminuer les pointeurs nuls
- retirer tous les 'cast' implicites

[sergio_is_back]

Une bonne façon de résoudre une grande partie des problèmes serait de:
- ajouter un typage "array of" comme il y avait en pascal pour retirer l'ambiguïté entre pointeur sur un élément et pointeur sur tableau
- rajouter les références pour diminuer les pointeurs nuls
- retirer tous les 'cast' implicites

En gros rapprocher le C du Pascal... Typage fort, Pointeurs typés, etc...

[transgohan]

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é ?

[AoCannaille]

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...

[transgohan]

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.

[Pyramidev]

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.

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.

[archqt]

Y a t il une option de compilation, comme il y avait en Turbo Pascal (eh oui ça date ) qui permette de forcer lors de l'accès à un tableau si l'indice est bien dans le tableau ? de base, si ma mémoire est bonne, le pascal faisait une vérification que l'on pouvait ensuite supprimer via une option.
Mais en C je n'ai pas trouvé cela.

Après c'est sûr qu'il faudrait peut être passer tout simplement en C++

[Pyramidev]

Y a t il une option de compilation, comme il y avait en Turbo Pascal (eh oui ça date ) qui permette de forcer lors de l'accès à un tableau si l'indice est bien dans le tableau ?

En C, avec GCC tout seul, je ne pense pas.
Par contre, si on travaille avec des fonctions personnalisées, on peut faire de la compilation conditionnelle pour décider si les contrôles de ces fonctions sont actifs.

En complément de mon message précédent, en C++, on peut bricoler ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#include <cassert>
#include <exception> // std::terminate

#if defined(NDEBUG) && defined(CHECK)
# define MY_ASSERT(cond)\
	if(cond)\
		static_cast<void>(0);\
	else\
		std::terminate() // code bourrin pour l'exemple
#elif defined(NDEBUG)
# define MY_ASSERT(cond) static_cast<void>(0)
#else
# define MY_ASSERT(cond) assert(cond)
#endif

template<class T, size_t Size>
class MyArray
{
public:
	T& operator[](size_t index) {
		MY_ASSERT(index < Size);
		return m_values[index];
	}

	T const& operator[](size_t index) const {
		MY_ASSERT(index < Size);
		return m_values[index];
	}

	template<size_t Index>
	T& get() {
		static_assert(Index < Size);
		return m_values[Index];
	}

	template<size_t Index>
	T const& get() const {
		static_assert(Index < Size);
		return m_values[Index];
	}

private:
	T m_values[Size];
};

int main()
{
	MyArray<int, 2> myArray; // tableau de 2 éléments de type int
	myArray.get<0>() = 10; // contrôle l'indice à la compilation : OK
	myArray[1] = 11; // contrôle OK à l'exécution (si les contrôles sont actifs)
//	myArray.get<2>() = 12; // erreur de compilation
	myArray[2] = 12; // signale une erreur à l'exécution (si les contrôles sont actifs)
	return 0;
}

Dans mon exemple, le modèle de fonction get prend en argument de modèle un indice qui doit être connu à la compilation et signale une erreur de compilation si cet indice est en dehors des bornes.
L'opérateur avec des crochets, lui, prend en argument un indice qui peut être inconnu à la compilation. Il effectue un contrôle à l'exécution, ou pas, selon le comportement de la macro MY_ASSERT.
Le comportement de la macro MY_ASSERT dépend si les macros NDEBUG et CHECK sont définies. C'est dans les options de compilation que l'on choisit si on définit NDEBUG et si on définit CHECK.

Remarque 1 : à la place de ma macro illustrative MY_ASSERT, il existe déjà BOOST_ASSERT (de la bibliothèque Boost) qui est meilleure, mais un peu plus compliquée à expliquer.

Remarque 2 : en C++20, MY_ASSERT et BOOST_ASSERT seront obsolètes, car on aura enfin une manière standardisée de faire de la programmation par contrats. Par exemple, les préconditions seront exprimées avec un attribut expects.
Le comportement adopté par le programme en cas de violation de contrat devrait être personnalisable.

[Uther]

Qu’en pensez-vous ?

J'ai regardé l'article en lien, visiblement ils ne se sont penché que sur le problème des buffer overflow, ce qui est très très loin d'être suffisant. Au niveau de la sécurité, ça reste a des année lumière de ce que proposent Rust et Ada. Le soucis, c'est que C est un langage conçu sans aucune idée de sécurité, vouloir le sécuriser en restant compatible ressemble pour moi a une mission impossible.
L’intérêt de sécuriser un langage est de fournir des garanties, si les anciens mécanisme pas sûrs sont gardés à l'identique, ils vont juste se retrouver dans la situation de C++.

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é ?

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.

Selon moi la performance du C vient en partie grâce à ces défauts

C'est pas tout a fait vrai si on regarde du coté de Rust qui arrive a lier performance et sécurité.

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.

Non toute les méthodes ne sont pas "aussi" bonnes que les autres. Une bonne analyse dynamique n'est pas parfaite et peut laisser passer des cas d'erreur. Avec une bonne analyse statique sur un langage qui s'y prete bien, on peut garantir que certaines erreurs n'arrivent jamais.
Les outils que tu as cité restent utiles en Rust principalement parce qu'il permet de s'interfacer avec du code C et qu'il existe un mécanisme qui permet d'ignorer localement certaines sécurités. Mais le langage de base garantit que les erreurs de sécurité mémoire ne peuvent arriver.