Discussion :

[Astraya]

Sans attendre l'ISO et Stroustrup. La communauté C++ à la chance d'être une des plus compétentes avec des décennies d'expériences.

Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.

L'équipe de Clang commence déjà a proposer des solutions.
https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377

[Uther]

Ok le borrow-checker c'est top...
mais quid du paradigme TRAIT ?
je trouve ca plus souple que la poo.

C'est vrai que les traits sont une fonctionnalité indiscutablement au cœur de Rust tout aussi importante sinon plus que le borrow checker. Je dirais aussi que les enum sont au moins aussi importante. Mais le sujet c'est la sécurité, et pour le coup, ça n'est ni les trait ni les enums qui font la sécurisation du Rust.
Ce qui fait sa sécurisation mémoire comparé au C++, c'est principalement le borrow checker et des choix par défaut sécurisés (initialisation obligatoire des variables, contrôles de dépassement, ...)

Une réflexion est déjà lancée et j'ai bonne espoir que C++ rattrape son retard sur ce point.

C'est pas les initiatives qui manquent pour améliorer la sécurité du C++, mais la difficulté c'est de faire quelque chose qui, à la fois :

• soit vraiment efficace
• s’intègre bien a la syntaxe du langage
• marche bien avec la base de code existante
• est acceptable pour des utilisateurs qui n'ont jamais eu de contraintes fortes jusqu’à présent

La plupart des initiatives que j'ai vu pèchent lourdement sur un ou plusieurs de ces points.
L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.

L'équipe de Clang commence déjà a proposer des solutions.
https://discourse.llvm.org/t/rfc-lif...ns-for-c/61377

C'est intéressant ça. Pour le coup ça a l'air complétement calqué sur le système des lifetimes de Rust. Reste a voir ce que ça pourra donner en pratique.

[walfrat]

L'avantage de Rust c'est il n'a pas eu a se soucier de l'existant en partant d'une page blanche et en posant dès le début la sécurité comme comportement par défaut.
.

Ca me fait penser au passage de Python 2 à Python 3 ou en tout cas un exemple de ce qui peut arriver sur une évolution de langage "brutale".

[Patrick Ruiz]

Les Agences des Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust
Qui « offre de meilleures garanties de sécurisation des plages mémoire des logiciels»

Faut-il arrêter d’initier de nouveaux projets en C++ et passer à Rust ? La question divise dans la communauté des développeurs dont certains recommandent le langage Rust plutôt que le C ou le C++. Les raisons : la parité du Rust en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec une sortie des agences de l’alliance Five Eyes. Elles insistent pour que les organisations abandonnent C++ pour le langage Rust, ce, après que la prise de position du créateur du langage C++ selon laquelle : « la sécurisation des logiciels par le Rust n’est pas supérieure à celle offerte par le C++. »

Les comparatifs des langages Rust et C++ ont un dénominateur commun : la mise en avant de la supériorité de Rust à C++ en matière de sécurisation de la mémoire.

La publication des Five Eyes ne s’en écarte pas : « Les langages de programmation tels que C et C++ sont des exemples de langages de programmation qui peuvent conduire à un code non sûr pour la mémoire et qui sont encore parmi les langages les plus utilisés aujourd'hui. Pour tenter d'atténuer les dangers du code à mémoire non sécurisée obtenu en C et C++, de nombreux fabricants de logiciels investissent dans des programmes de formation à l'intention de leurs développeurs.

Nombre de ces programmes de formation comprennent des tactiques conçues pour réduire la prévalence des vulnérabilités de sécurité de la mémoire produites par ces langages. En outre, il existe de nombreux programmes de formation organisés par des associations commerciales et industrielles. En outre, diverses organisations et universités proposent des formations et un certificat professionnel pour démontrer la connaissance des pratiques de codage sécurisé en C et en C++.

Bien que la formation puisse réduire le nombre de vulnérabilités qu'un codeur peut introduire, étant donné l'omniprésence des défauts de sécurité de la mémoire, il est presque inévitable que des vulnérabilités de sécurité de la mémoire se produisent encore. Même les développeurs les plus expérimentés introduisent des bogues desquels peuvent résulter des vulnérabilités importantes. La formation doit servir de transition pendant qu'une organisation met en œuvre des contrôles techniques plus robustes, tels que des langages à sécurité mémoire. »

« Rust garantit la sécurisation de la mémoire et des threads au moment de la compilation en introduisant des règles de propriété. Il va au-delà du RAII, un mécanisme de gestion de la mémoire couramment utilisé en C++. Il présente deux avantages. Le premier est évident : une fois que le compilateur Rust a validé notre programme, nous n'aurons pas de défauts de segmentation ou de conditions de concurrence lors de l'exécution, ce qui nécessiterait des dizaines d'heures de débogage, en particulier dans une base de code hautement concurrente et principalement asynchrone. La seconde est plus subtile : le compilateur Rust restreint simplement les types de fautes, ce qui réduit les fragments de code étroitement imbriqués qui peuvent causer un tel comportement bogué. La réplication des bogues est considérablement améliorée avec l'aide de l'exécution déterministe », indique l'éditeur RisingWave à propos de la réécriture de son SGBD Cloud natif depuis zéro en Rust après abandon du projet en C++.

C’est une sortie qui fait suite à celle d’Amazon qui est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. » En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que Mark Russinovich recommande le Rust plutôt que le C ou le C++.

Néanmoins, Bjarne Stroustrup s’inscrit en faux avec le fait que les comparatifs entre Rust et C++ limitent la notion de sécurisation des logiciels à celle de sécurisation de la mémoire : « Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique. » Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui
garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.

L’équipe de Google dont la publication est parue au troisième trimestre de l’année précédente est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

Code Rust :

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
#include <type_traits> 
#include <utility> 
#include <assert.h> 
#include <stddef.h> 
enum NoRefs {}; 
enum HasMutRef {}; 
enum HasRefs {}; 
template <class T, typename Mode> 
class Own; 
template <class T> 
class MutRef; 
template <class T> 
class Ref; 
template <class T, typename... Args> 
inline Own<T, NoRefs> make(Args... args) { 
  return Own<T, NoRefs>(std::forward<Args>(args)...); 
} 
template <class T> 
inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) { 
  return Own<T, NoRefs>(std::move(own)); 
} 
template <class T> 
inline Own<T, NoRefs> consume(Own<T, HasRefs> own) { 
  return Own<T, NoRefs>(std::move(own)); 
} 
template <class T> 
std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) { 
  T* t = own.t_; 
  own.t_ = nullptr; 
  return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t)); 
} 
template <class T> 
std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) { 
  T* t = own.t_; 
  own.t_ = nullptr; 
  return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t)); 
} 
// No refs exist. 
template <class T> 
class [[clang::trivial_abi]] Own<T, NoRefs> { 
 public: 
  template <typename... Args> 
  Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {} 
  ~Own() { delete t_; } 
  Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; } 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
 private: 
  friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref); 
  friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own); 
  friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  Own(Own<T, HasMutRef>&& own) : t_(own.t_) {} 
  Own(Own<T, HasRefs>&& own) : t_(own.t_) {} 
  T* t_; 
}; 
// A mut ref exists. 
template <class T> 
class [[clang::trivial_abi]] Own<T, HasMutRef> { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
 private: 
  friend class Own<T, NoRefs>; 
  Own(T* t) : t_(t) {} 
  ~Own() {} 
  T* t_; 
}; 
// Non-mut refs exist. 
template <class T> 
class [[clang::trivial_abi]] Own<T, HasRefs> { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  Ref<T> ref() { return Ref<T>(t_, &count_); } 
 private: 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  explicit Own(T* t) : t_(t) {} 
  ~Own() { assert(count_ == 0u); } 
  T* t_; 
  uint32_t count_; 
}; 
template <class T> 
class MutRef { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  ~MutRef() = default; 
  MutRef(MutRef&& other) : t_(other.t_) {} 
 private: 
  friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
  MutRef(T* t) : t_(t) {} 
  T* t_; 
}; 
template <class T> 
class Ref { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  ~Ref() { --(*count_); } 
  Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); } 
  Ref(Ref&& other) : t_(other.t_), count_(other.count_) {} 
 private: 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); } 
  T* t_; 
  uint32_t* count_; 
}; 
MutRef<int> Borrows(MutRef<int> i) { 
  (*i)++; 
  return i; 
} 
TEST(Borrow, HelloWorld) { 
  // Can't do this. The HasMutRefs type is not destructible outside of 
  // consume()in order to have compiler check it is re-owned, but it won't 
  // compile. To pass the HasMutRefs to consume() it has to be destroyed both 
  // inside and outside of consume(). This is true even if trivial_abi is 
  // used and only one destructor would actually run. 
  Own<int, NoRefs> i = make<int>(5); 
  auto& hasmut = mut(std::move(i)); 
  MutRef<int> ref = Borrows(std::move(hasmut.second)); 
  Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref));

}

La sortie des agences Five Eyes intervient dans un contexte où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

Après 31 ans, un deuxième langage a fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

Source : Five Eyes

Et vous ?

Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

Voir aussi :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

[Steinvikel]

La comparaison de Rust face à C++ m'a toujours paru assez fallacieuse :
Je la vois toujours évoqué sans tenir compte de l'écosystème du développeur, à croire que ces 2 langages sont comparés nus.

Comparer un langage qui tire parti d'un complément de fonctionnalités par des outils externes, à un autre qui en incorpore certaines en natif, mais le faire sans ces dit outils a-t-il du sens ?


Dans un second temps, Bjarne Stroustrup rappelait à l'occasion de la cppCon 2023 (billet dvp.com du 6 octobre ici) que la question de la sécurité (et la sûreté) n'a pas démarré il y a quelques années, et que les principales règles de codage qui gouverne la sécurité par le code existent depuis au minimum les années 90.
Depuis cette époque la problématique n'a pas changé --> le difficulté n°1 est de trouver une solution pour que la masse des développeurs aient connaissance de ces règles, la difficulté n°2, qu'ils finissent par avoir l'habitude de les appliquer.
La difficulté n°2 vient du fait que l'on code avant tout pour répondre à un besoin pratique, et que parmi tous les aspects à traiter sur les concepts à choisir et leur implémentation, les développeurs finissent par oublier d'appliquer certaines notions de sécurité. En découle des erreurs types, comme :
Les erreurs de logique - où ce qui est écrit s'écarte de la manière dont le codeur le pensait (ex : utiliser '<' là où '>' était pensé)
les fuites de ressources
les erreurs de concurrence
les erreurs de typage
les overflow et les conversions implicites
les erreurs de timing - ex : coder un retour à 1,2 ms à un périphérique qui répond aux évènements externe en 1 ms max
les allocations non prédictibles
les erreurs d'arrêt -


NB : pour les diapos de la conférence : lien_github
NB : pour la conférence :

Il rappel également que bien qu'une alternative soit "memory safety", ce n'est pas suffisant, la sécurité doit être traité globalement, sur tous ses aspects.
Une question revient alors assez souvent : si Rust permet plus facilement de produire du code "memory safety" pour une plus grande part de développeurs, Rust permet-il d'atteindre un plus haut degré final de sécurité ?
Que la réponse soit "oui" ou "non", Rust permet-il à un plus grand nombre de développeurs de produire du code plus sûr ?
A cette dernière question, je pense pouvoir dire "oui", car permet de le faire de manière plus accessible tous niveaux de maîtrise confondu.

Une chose est sûr : l'aspect déterministe du code produit en Rust semble être l'un des atouts majeur en terme de garantie sur la sécurité du code produit et son analyse.
Mais je constate aussi que beaucoup de code produit sont lourd à l'exécution (mémoire, CPU...) parce que le code n'est pas suffisamment verbeux (explicitement écrit).
Un exemple flagrant, lors d'une démonstration par Jason Turner à la cppCon 2016, où après avoir fait un mapping des couleurs, il faisait face à un overhead.
Une simple transformation de " static std::array<Color, 16> colors {{... " en " static const std::array<Color, 16> colors {{... " et ses 354 instructions d'assembleur se transforment tout à coup en 7 instructions.
La conférence cppCon 2016 : lien_youtube

[Regulus136]

On aimerait bien que les personnes qui osent sortir un avis aussi tranché aient codé au minimum une application en langage Rust. Parce que si programmer (correctement) en C++ (1X/2X) réclame des compétences sérieuses et un investissement important, alors programmer en Rust est autrement plus délicat. En fait il faut expérimenter ce langage incroyablement verbeux pour comprendre sa douleur.

[Pyramidev]

En fait il faut expérimenter ce langage incroyablement verbeux pour comprendre sa douleur.

Je peux comprendre que Rust soit qualifié de verbeux par rapport à du Python. Mais, qualifier Rust d'"incroyablement verbeux" par rapport à C++, cela m'étonne. Il y a des choses plus concises en C++ et d'autres plus concises en Rust. Aurais-tu un exemple de code "incroyablement verbeux" en Rust sous la main à partager ?

[seedbarrett]

Les agences Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust

Quand je lis ça, j'ai plutôt envie de rester sur C++

[fdecode]

Mais, qualifier Rust d'"incroyablement verbeux" par rapport à C++, cela m'étonne.

Moi aussi, ça m'étonne. En ce qui me concerne, je trouve que ce langage permet de produire du code élégant, et surtout j'aime la manière dont il permet de structurer les librairies dans une perspective de généricité.

Ceci-dit, les contraintes liées aux sémantiques d'emprunt et de durée de vie peuvent parfois demander un certain exercice intellectuel si on veut aboutir à un code léger.

Et si on se laisse aller à utiliser les puissants paradigmes de rust n'importe comment, on peut aussi produire du code un peu lourd (e.g. des codes génériques avec des contraintes sur les variables de type un peu dans tous les sens...).

Il faut aussi programmer avec la philosophie des paradigmes de Rust et adapter ses réflexes en ce sens. A contrario, je me souviens au début m'être exercé à simuler des classes d'objets au sens 'classique' en utilisant les mécanismes de traits, de mod et de généricité (histoire de me prouver que rust avait l'expressivité suffisante pour programmer objet de la manière que je l'avais appris...). J'y suis arrivé, mais c'était très lourd!

La programmation des macros (procédurales ou non) n'est pas particulièrement légère non plus, de mon point de vue.

Mais il ne s'agit pas là de cas d'usage usuels.

[kiruahxh]

Chaque langage a ses avantages et ses inconvénients.
Rust met en avant la sécurité mémoire, mais je lui vois surtout un écosystème plus pratique que C et C++ (cargo, arborescence de projet standardisée, 1 seul compilateur/lib standard officiel, cross compilation triviale, librairies réutilisables).
D'un autre côté c'est un langage plus bas niveau que C++, pas bien adapté pour coder la logique métier d'une application desktop.

C++ a un écosystème et une lib standard pas top, difficilement portable (pas d'unicode), mais le langage lui même est très poussé.
Il permet de créer de très bons frameworks, ex Qt.

Dans les développements que je fait, la sécurité mémoire n'est pas très importante.

La plupart des autres langages à la mode conviennent mal aux interfaces graphiques parce qu'ils sont garbage collectés

[fdecode]

D'un autre côté c'est un langage plus bas niveau que C++, pas bien adapté pour coder la logique métier d'une application desktop.

Qu'entendez-vous par bas niveau ou haut niveau ici? Les deux langages permettent des manipulations bas niveau, et les deux langages sont multi-paradigmes et permettent des constructions abstraites et de haut niveau.
Et pour ce qui est de Rust, les mécanismes de traits associés aux types génériques, aux possibilités qu'on a de les conditionner, et aux systèmes de macro permettent de cibler très finement les aspect de la logique métier que l'on souhaite implémenter et mettre à disposition d'un utilisateur tiers.

[Jade Emy]

Les futurs logiciels devraient être sûrs pour la mémoire, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyber-attaques.

L'Office of the National Cyber Director (ONCD) de la Maison Blanche a publié un rapport appelant la communauté technique à réduire de manière proactive la surface d'attaque dans le cyberespace. De leur côté, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyberattaques.

L'ONCD fait valoir que les fabricants de technologies peuvent empêcher des catégories entières de vulnérabilités d'entrer dans l'écosystème numérique en adoptant des langages de programmation sans danger pour la mémoire. L'ONCD encourage également la communauté des chercheurs à se pencher sur le problème de la mesurabilité des logiciels afin de permettre le développement de meilleurs diagnostics mesurant la qualité de la cybersécurité.

Le rapport s'intitule “Back to the Building Blocks: A Path Toward Secure and Measurable Software.”

"En tant que nation, nous avons la capacité - et la responsabilité - de réduire la surface d'attaque dans le cyberespace et d'empêcher des catégories entières de bogues de sécurité d'entrer dans l'écosystème numérique, mais cela signifie que nous devons nous attaquer au problème difficile de l'adoption de langages de programmation sans danger pour la mémoire", a déclaré Harry Coker, directeur national du cyberespace. "Grâce au travail de l'équipe de l'ONCD et à l'excellente collaboration de la communauté technique et de nos partenaires des secteurs public et privé, le rapport publié aujourd'hui décrit les menaces et les possibilités qui s'offrent à nous alors que nous nous dirigeons vers un avenir où les logiciels seront sans danger pour la mémoire et sécurisés dès leur conception. Je me réjouis également que nous travaillions avec la communauté universitaire et que nous fassions appel à elle pour nous aider à résoudre un autre problème difficile : comment développer de meilleurs diagnostics pour mesurer la qualité de la cybersécurité ? Il est impératif de relever ces défis pour garantir la sécurité à long terme de notre écosystème numérique et protéger la sécurité de notre pays".

En adoptant une approche de l'élaboration des politiques axée sur l'ingénierie, l'ONCD veille à ce que l'expertise de la communauté technique se reflète dans la manière dont le gouvernement fédéral aborde ces problèmes. Les créateurs de logiciels et de matériel peuvent avoir un impact considérable sur la sécurité partagée de la nation en intégrant les résultats de la cybersécurité dans le processus de fabrication.

"Certains des événements cybernétiques les plus tristement célèbres de l'histoire - le ver Morris de 1988, le ver Slammer de 2003, la vulnérabilité Heartbleed de 2014, l'exploit Trident de 2016, l'exploit Blastpass de 2023 - ont été des cyberattaques qui ont fait la une des journaux et qui ont causé des dommages réels aux systèmes sur lesquels la société s'appuie chaque jour. Toutes ces attaques ont une cause fondamentale commune : les vulnérabilités de la sécurité de la mémoire. Depuis trente-cinq ans, les failles de sécurité de la mémoire sont un fléau pour l'écosystème numérique, mais il n'est pas nécessaire qu'il en soit ainsi", déclare Anjana Rajan, directrice nationale adjointe de la cybernétique pour la sécurité technologique. "Ce rapport a été créé par des ingénieurs pour des ingénieurs, car nous savons qu'ils peuvent prendre des décisions en matière d'architecture et de conception des composants qu'ils consomment, ce qui aura un effet considérable sur notre capacité à réduire la surface des menaces, à protéger l'écosystème numérique et, en fin de compte, la nation."

L'ONCD s'est engagé auprès d'un groupe diversifié de parties prenantes, les ralliant à l'effort de l'administration.

Conformément à deux thèmes majeurs de la stratégie nationale de cybersécurité du président publiée il y a près d'un an, le rapport publié marque une étape importante dans le transfert de la responsabilité de la cybersécurité des particuliers et des petites entreprises vers les grandes organisations, telles que les entreprises technologiques et le gouvernement fédéral, qui sont plus à même de gérer une menace en constante évolution. Ces travaux s'inscrivent également dans le prolongement des programmes "secure by design" et des efforts de recherche et de développement déployés par l'ensemble du gouvernement fédéral, notamment par la CISA, la NSA, le FBI et le NIST, et s'appuient sur eux.

Les travaux sur la sécurité des mémoires présentés dans le rapport complètent l'intérêt du Congrès pour ce sujet. Il s'agit notamment des efforts des commissions des crédits du Sénat et de la Chambre des représentants des États-Unis, qui ont inclus dans la législation sur les crédits de l'exercice fiscal 2023 un libellé de rapport directif exigeant un exposé de l'ONCD sur cette question. En outre, le président de la commission sénatoriale de la sécurité intérieure et des affaires gouvernementales, Gary Peters (D-MI), et le sénateur Ron Wyden (D-OR) ont fait part à l'ONCD de leurs efforts législatifs en matière de sécurité de la mémoire.


Lire le rapport complet : Retour aux éléments de base : un chemin vers des logiciels sûrs et mesurables, un rapport de la Maison Blanche sur la sécurité de la mémoire et sur la qualité de la cybersécurité


Source : Communiqué de presse de la Maison Blanche

Et vous ?

Pensez-vous que ce rapport est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Les Agences des Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust, qui « offre de meilleures garanties de sécurisation des plages mémoire des logiciels »

Il est urgent de renforcer la sécurité de la mémoire dans les produits logiciels, selon la CISA. L'utilisation d'un langage de programmation à sécurité mémoire comme Rust serait une solution

La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

[Patrick Ruiz]

La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust
Jugés supérieurs pour sécuriser les espaces mémoire des logiciels

Faut-il arrêter d’initier de nouveaux projets en C ou C++ et passer à Rust ? La question divise dans la communauté des développeurs dont certains recommandent le langage Rust plutôt que le C ou le C++. Les raisons : la parité du Rust en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec un rapport de la Maison Blanche sur la sécurisation de la mémoire qui invite les développeurs à abandonner C ou C++ pour passer à des langages comme le Rust jugés supérieurs pour sécuriser les espaces mémoire des logiciels. C’est une sortie qui fait suite à la prise de position du créateur du langage C++ selon laquelle : « la sécurisation des logiciels par le Rust n’est pas supérieure à celle offerte par le C++. »

« En tant que nation, nous avons la capacité - et la responsabilité - de réduire la surface d'attaque dans le cyberespace et d'empêcher des catégories entières de bogues de sécurité d'entrer dans l'écosystème numérique, mais cela signifie que nous devons nous attaquer au problème difficile de l'adoption de langages de programmation sans danger pour la mémoire », écrit l'Office of the National Cyber Director (ONCD) de la Maison Blanche qui cite le Rust parmi les langages à adopter.

Les comparatifs des langages Rust et C++ ont un dénominateur commun : la mise en avant de la supériorité de Rust à C++ en matière de sécurisation de la mémoire.

« Les langages de programmation tels que C et C++ sont des exemples de langages de programmation qui peuvent conduire à un code non sûr pour la mémoire et qui sont encore parmi les langages les plus utilisés aujourd'hui. Pour tenter d'atténuer les dangers du code à mémoire non sécurisée obtenu en C et C++, de nombreux fabricants de logiciels investissent dans des programmes de formation à l'intention de leurs développeurs.

Nombre de ces programmes de formation comprennent des tactiques conçues pour réduire la prévalence des vulnérabilités de sécurité de la mémoire produites par ces langages. En outre, il existe de nombreux programmes de formation organisés par des associations commerciales et industrielles. En outre, diverses organisations et universités proposent des formations et un certificat professionnel pour démontrer la connaissance des pratiques de codage sécurisé en C et en C++.

Bien que la formation puisse réduire le nombre de vulnérabilités qu'un codeur peut introduire, étant donné l'omniprésence des défauts de sécurité de la mémoire, il est presque inévitable que des vulnérabilités de sécurité de la mémoire se produisent encore. Même les développeurs les plus expérimentés introduisent des bogues desquels peuvent résulter des vulnérabilités importantes. La formation doit servir de transition pendant qu'une organisation met en œuvre des contrôles techniques plus robustes, tels que des langages à sécurité mémoire », soulignent les Five Eyes dans un appel à abandonner C ou C++ et à passer à Rust.

« Rust garantit la sécurisation de la mémoire et des threads au moment de la compilation en introduisant des règles de propriété. Il va au-delà du RAII, un mécanisme de gestion de la mémoire couramment utilisé en C++. Il présente deux avantages. Le premier est évident : une fois que le compilateur Rust a validé notre programme, nous n'aurons pas de défauts de segmentation ou de conditions de concurrence lors de l'exécution, ce qui nécessiterait des dizaines d'heures de débogage, en particulier dans une base de code hautement concurrente et principalement asynchrone. La seconde est plus subtile : le compilateur Rust restreint simplement les types de fautes, ce qui réduit les fragments de code étroitement imbriqués qui peuvent causer un tel comportement bogué. La réplication des bogues est considérablement améliorée avec l'aide de l'exécution déterministe », indique l'éditeur RisingWave à propos de la réécriture de son SGBD Cloud natif depuis zéro en Rust après abandon du projet en C++.

« Choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre », déclare Amazon. En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que Mark Russinovich recommande le Rust plutôt que le C ou le C++.

« En 2021, nous avons annoncé que Google rejoignait la Rust Foundation. À l'époque, Rust était déjà largement utilisé dans Android et d'autres produits Google. Notre annonce soulignait notre engagement à améliorer les examens de sécurité du code Rust et son interopérabilité avec le code C++. Rust est l'un des outils les plus puissants dont nous disposons pour résoudre les problèmes de sécurité de la mémoire. Depuis cette annonce, les leaders de l'industrie et les agences gouvernementales se sont fait l'écho de notre sentiment.

Nous sommes ravis d'annoncer que Google a accordé une subvention d'un million de dollars à la Fondation Rust pour soutenir les efforts visant à améliorer la capacité du code Rust à interopérer avec les bases de code C++ existantes. Nous poursuivons également notre engagement envers la communauté open-source Rust en regroupant et en publiant des audits pour les crates Rust que nous utilisons dans les projets open-source de Google. Ces contributions, ainsi que nos précédentes contributions en matière d'interopérabilité, nous rendent enthousiastes quant à l'avenir de Rust », écrit Google dans le cadre de l’annonce de l’accord d’une subvention d’un million de dollars de la Fondation Rust pour soutenir les efforts d’interopérabilité avec C++.

« Nous sommes ravis de soutenir ce travail par le biais de l'initiative Interop de la Fondation Rust et en collaboration avec le projet Rust afin de s'assurer que tous les ajouts effectués sont appropriés et répondent aux défis de l'adoption de Rust auxquels les projets utilisant C++ sont confrontés. L'amélioration de la sécurité de la mémoire dans l'industrie du logiciel est l'un des principaux défis technologiques de notre époque, et nous invitons la communauté et l'industrie à se joindre à nous pour travailler ensemble à la sécurisation de l'écosystème open source pour tous », ajoute le géant technologique.

Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. De façon graduelle, Microsoft migre vers ce dernier au détriment d’autres langages que l’entreprise juge moins outillés pour la mise sur pied d’applications dites système. Motif : Rust offre de meilleures garanties en matière de sécurisation des accès mémoire des logiciels.

« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui. Nous devons utiliser de façon systématique des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants », déclare Neal Ziring, directeur technique de la cybersécurité de la NSA.

En effet, il y a une liste de griefs qui reviennent à l’encontre de langages de programmation comme le C et le C++ : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

Le créateur du C++ est d’avis que « La sécurisation des logiciels via le langage Rust n'est pas supérieure à celle offerte par le C++ »

Mark Russinovich de Microsoft a déclaré que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. » Motif : le Rust offre de meilleures garanties de sécurisation des logiciels que les langages C ou C++. La position reprise quelques mois plus tard par la NSA trouve contradicteur et pas des moindres. Sans détour, le créateur du langage C++ déclare : « la sécurisation des logiciels par le langage Rust n’est pas supérieure à celle offerte par le C++. »

En effet, Bjarne Stroustrup s’inscrit en faux avec le fait que la publication de la NSA limite la notion de sécurisation des logiciels à celle de sécurisation de la mémoire. En réalité, cet aspect est un dénominateur commun de toutes les publications qui conseillent de mettre le C ou le C++ au rebut au profit du langage Rust en raison des garanties de sécurisation des logiciels que plusieurs grandes entreprises (Microsoft, Amazon, etc.) lui reconnaissent.

« Il n'y a pas qu'une seule définition de la notion de "sécurité" et nous pouvons réaliser une variété de types de sécurité par une combinaison de styles de programmation, de bibliothèques de support et grâce à la mise à profit de l'analyse statique », indique-t-il. Bjarne Stroustrup suggère ainsi que ce qu’il est possible d’obtenir du C++ en matière de sécurisation des logiciels dépend entre autres du développeur et notamment de la connaissance des outils que lui offre le langage, de sa maîtrise du compilateur, etc.

Des ingénieurs de Google au fait de ce que le C++ leur offre comme possibilités se sont donc lancés dans la mise sur pied dans ce langage d’un borrow-checker. C’est une fonctionnalité du compilateur Rust qui garantit la sécurisation de la mémoire grâce à une gestion des allocations en mémoire des pointeurs.

L’équipe de Google dont la publication est parvenue à la conclusion que le système de types du C++ ne se prête pas à un tel exercice. Et donc que la sécurisation de la mémoire en C++ est réalisable avec des vérifications lors de l’exécution du programme. En d’autres termes, c’est avec du code C++ lent qu’il est possible d’atteindre un niveau de sécurisation équivalent à celui du Rust.

Code Rust :

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
#include <type_traits> 
#include <utility> 
#include <assert.h> 
#include <stddef.h> 
enum NoRefs {}; 
enum HasMutRef {}; 
enum HasRefs {}; 
template <class T, typename Mode> 
class Own; 
template <class T> 
class MutRef; 
template <class T> 
class Ref; 
template <class T, typename... Args> 
inline Own<T, NoRefs> make(Args... args) { 
  return Own<T, NoRefs>(std::forward<Args>(args)...); 
} 
template <class T> 
inline Own<T, NoRefs> consume(Own<T, HasMutRef> own, MutRef<T> ref) { 
  return Own<T, NoRefs>(std::move(own)); 
} 
template <class T> 
inline Own<T, NoRefs> consume(Own<T, HasRefs> own) { 
  return Own<T, NoRefs>(std::move(own)); 
} 
template <class T> 
std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own) { 
  T* t = own.t_; 
  own.t_ = nullptr; 
  return std::make_pair(Own<T, HasMutRef>(t), MutRef<T>(t)); 
} 
template <class T> 
std::pair<Own<T, HasRefs>, MutRef<T>> ref(Own<T, NoRefs> own) { 
  T* t = own.t_; 
  own.t_ = nullptr; 
  return std::make_pair(Own<T, HasRefs>(t), Ref<T>(t)); 
} 
// No refs exist. 
template <class T> 
class [[clang::trivial_abi]] Own<T, NoRefs> { 
 public: 
  template <typename... Args> 
  Own(Args... args) : t_(new T(std::forward<Args>(args)...)) {} 
  ~Own() { delete t_; } 
  Own(Own<T, NoRefs>&& other) : t_(other.t_) { other.t_ = nullptr; } 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
 private: 
  friend Own<T, NoRefs> consume<T>(Own<T, HasMutRef> own, MutRef<T> ref); 
  friend Own<T, NoRefs> consume<T>(Own<T, HasRefs> own); 
  friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  Own(Own<T, HasMutRef>&& own) : t_(own.t_) {} 
  Own(Own<T, HasRefs>&& own) : t_(own.t_) {} 
  T* t_; 
}; 
// A mut ref exists. 
template <class T> 
class [[clang::trivial_abi]] Own<T, HasMutRef> { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
 private: 
  friend class Own<T, NoRefs>; 
  Own(T* t) : t_(t) {} 
  ~Own() {} 
  T* t_; 
}; 
// Non-mut refs exist. 
template <class T> 
class [[clang::trivial_abi]] Own<T, HasRefs> { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  Ref<T> ref() { return Ref<T>(t_, &count_); } 
 private: 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  explicit Own(T* t) : t_(t) {} 
  ~Own() { assert(count_ == 0u); } 
  T* t_; 
  uint32_t count_; 
}; 
template <class T> 
class MutRef { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  ~MutRef() = default; 
  MutRef(MutRef&& other) : t_(other.t_) {} 
 private: 
  friend std::pair<Own<T, HasMutRef>, MutRef<T>> mut(Own<T, NoRefs> own); 
  MutRef(T* t) : t_(t) {} 
  T* t_; 
}; 
template <class T> 
class Ref { 
 public: 
  T& operator*() const noexcept { return *t_; } 
  T* operator->() const noexcept { return t_; } 
  ~Ref() { --(*count_); } 
  Ref(const Ref& other) : t_(other.t_), count_(other.count_) { ++(*count_); } 
  Ref(Ref&& other) : t_(other.t_), count_(other.count_) {} 
 private: 
  friend std::pair<Own<T, HasRefs>, Ref<T>> ref(Own<T, NoRefs> own); 
  Ref(T* t, uint32_t* count) : t_(t), count_(count) { ++(*count); } 
  T* t_; 
  uint32_t* count_; 
}; 
MutRef<int> Borrows(MutRef<int> i) { 
  (*i)++; 
  return i; 
} 
TEST(Borrow, HelloWorld) { 
  // Can't do this. The HasMutRefs type is not destructible outside of 
  // consume()in order to have compiler check it is re-owned, but it won't 
  // compile. To pass the HasMutRefs to consume() it has to be destroyed both 
  // inside and outside of consume(). This is true even if trivial_abi is 
  // used and only one destructor would actually run. 
  Own<int, NoRefs> i = make<int>(5); 
  auto& hasmut = mut(std::move(i)); 
  MutRef<int> ref = Borrows(std::move(hasmut.second)); 
  Own<int, NoRefs> i2 = consume(std::move(hasmut.first), std::move(ref)); 
}

Sources : Rapport Maison Blanche sur la sécurisation de la mémoire, Communiqué de presse de la Maison Blanche

Et vous ?

Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Le C et le C++ ont-ils vraiment besoin de remplaçants surtout en matière de programmation système ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?

Voir aussi :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

[Issam]

heuu 1 sec ,


c'est quoi le rapport entre la maison blanche et les languages de programmation ?

[eatse21]

heuu 1 sec ,


c'est quoi le rapport entre la maison blanche et les languages de programmation ?

Sûrement une question de sécurité nationale parmi de nombreuses autres, tout comme une nation européenne pourrait s’intéresser à l’utilisation d’une distribution libre pour son parc de machine plutôt que d’autres solutions contrôlée par une entreprise étrangère, introduisant potentiellement certaines failles pour sa sécurité nationale par exemple.

[commandantFred]

heuu 1 sec ,

c'est quoi le rapport entre la maison blanche et les languages de programmation ?

Les cyber attaques sont de plus en plus commanditées par des états. Elles concernent tout le software déployé dans un pays dont les machines sont retournées pour en faire des zombies qui attaquent d'autres machines ou sont détournées pour servir de vpn' like à l'attaquant. Même dans le cas d'une infection par ransomware, l'activité d'une entité économique est détruite, entrainant sa faillite, chômage ou simplement des coûts énormes en assurance.
Coordonnée par les états, l'accumulation de telles attaques peut détruire l'économie d'un pays.
Autre scénario : l'attaque militaire : on infecte le software de pilotage de machines peu critiques donc mal protégées pour forcer la consommation électrique tandis que des applications de gestion d'énergie domestiques (thermostats intelligents) sont hackées ou désactivées par saturation pour empêcher la régulation de la consommation. Dans le même temps, on attaque le réseau électrique et les centrales pour provoquer un blackout.
Une fois que tout est en panne, une vraie attaque militaire est possible.
Même sans attaque physique, le pays est durablement affaibli par un blackout.

les politiques ne savent pas de quoi il parlent.

le rust pour remplacer le c => ok
le rust pour remplacer le c++ => pas totalement ok

C++ est un compilateur C auquel on applique une surcouche. (Théoriquement, des directives de préprocessing suffisent)

Les vulnérabilités viennent de la cohabitation de pointeurs sur data et pointeurs sur code. Les premiers permettent de trouver les seconds et même de les modifier (buffer overflow)
Je connais trop mal Rust pour savoir comment il sécurise la ram mais une simple garbage collection rend les pointeurs indépendants de la compilation. Les adresses changent à chaque appel de GC, le pointeur de pile n'est pas le registre SP du CPU... etc...

C'est, en très résumé, le problème de tous les compilos de cette génération.

Personnellement, je lis le C comme ma langue maternelle et sa disparition me met un méchant coup de vieux. J'espère que LLVM et WebAssembly permettront de continuer à écrire en C mais pour les performances imbattables, il faudra sans doute migrer vers Rust (ou go ?)

Bref, c'est dommage !

A l'origine du CC++, les experts étaient rares et les machines coûtaient des mois de salaire. Aujourd'hui, on se forme en ligne et on trouve des machines utilisables pour quelques centaines d'euros. La démocratisation du matériel et la gratuité du logiciel poussent pas mal de standards vers l'obsolescence (e-mail ? SMTP, pop, FTP, ...)

Je me fais vieux

[Uther]

C++ est un compilateur C auquel on applique une surcouche. (Théoriquement, des directives de préprocessing suffisent)

C'était vrai aux débuts de C++, mais de nos jours il s'est trop complexifié et a divergé sur certains points. Même s'il embarque encore une bonne partie de l'héritage du C, ce n'est plus une simple surcouche depuis au moins 20 ans.

Les vulnérabilités viennent de la cohabitation de pointeurs sur data et pointeurs sur code. Les premiers permettent de trouver les seconds et même de les modifier (buffer overflow)
Je connais trop mal Rust pour savoir comment il sécurise la ram mais une simple garbage collection rend les pointeurs indépendants de la compilation. Les adresses changent à chaque appel de GC, le pointeur de pile n'est pas le registre SP du CPU... etc...

C'est malheureusement plus compliqué que ça. Il existe des technologies, tout à fait utilisables en C, qui permettent déjà de se protéger de ce que vous décrivez, comme la DEP (protection contre l’exécution des données) ou l'ASLR (positionnement aléatoire des adresses). C'est très bien, mais ça n’est que de la mitigation : les bugs sont toujours là et des attaquants assez malins arrivent encore à trouver des moyens pour les exploiter.

Rust n'utilise pas de Garbage Collector pour la gestion mémoire. Sur ce point il fonctionne exactement comme C ou C++, excepté qu'il impose au programmeur des règles à respecter sur la façon d'utiliser les références (l’équivalent des pointeurs), ce qui permet, dès la compilation de garantir que l'on ne peut jamais manipuler une données non valide.

J'espère que LLVM et WebAssembly permettront de continuer à écrire en C mais pour les performances imbattables, il faudra sans doute migrer vers Rust (ou go ?)

Je vois pas trop le rapport avec WebAssembly ou LLVM. Le C n'est de toute façon pas près de disparaitre ou de perdre en performance. Si on a pas pu se débarrasser de COBOL alors que ça fait plus de 30 ans qu'on essaie, je pense que le C en a pour au moins encore autant, probablement plus

Quant au C, c'est un langage très simple, facilement compréhensible. Je suis d'accord qu'il PERMET de faire des bêtises, mais ce n'est pas à cause du C en lui-même, mais de développeurs incompétents et/ou dont on ne laisse pas le temps d'écrire du code propre et lisible. Si un charpentier se tape sur les doigts avec un marteau, ce n'est pas le marteau qu'on accuse.

Sauf que les deux tiers des vulnérabilités critiques qu'on trouve dans tous les gros logiciels C++ viennent d'erreurs mémoire. Donc soit les incompétents sont partout, soit les meilleurs experts font aussi parfois des erreurs (probablement un mix des deux). Dans tous les cas, on a un gros problème à résoudre, connu depuis plus de 40 ans, et tous les moyens qui on un effet mesurable sont bon à prendre. S'il suffisait de désigner des coupables, on aurait tourné la page depuis longtemps.

Rust plus que ça, mais j'ai regardé son système de gestion de la mémoire, et il n'est pas si exceptionnel que ça.

Tout dépend de la définition que l'on a d'exceptionnel.

En un sens il est vrai que, techniquement, la manière de gérer la mémoire n'est pas exceptionnelle. Structurellement, on a une pile classique et un tas alloué dynamiquement, tout comme en C. On gère les ressources en RIIA comme en C++. Même les principes centraux en Rust que sont l'ownership et les lifetime n'ont pas été inventées par Rust. Ce sont des bonnes pratiques que l'on recommandais déjà en C et C++.

Mais le fait que le compilateur garantisse la stricte application de ces principes est exceptionnel, car pour le moment sans d’équivalent dans aucun autre langage (actuellement utilisable) de ma connaissance. Le fait de pouvoir à la fois empêcher totalement les vulnérabilités mémoires tout en conservant l'efficacité du système de gestion mémoire de C fait tout l’intérêt du Rust.

Il y a d'ailleurs un langage qui traite déjà ce "problème", et c'est le langage Ada.

En effet Ada permet de traiter des problématiques de sécurité y compris certaines que Rust ne sait pas (encore) traiter, mais inversement il y a des problématique de sécurité que Rust traite mieux que Ada, qui est d'ailleurs en train d'ajouter un système de borrow checker, inspiré directement de Rust.
Les deux langages ont leur intérêt propre, Rust étant quand même plus orienté productivité et il reste plus proche du C que Ada, ne serait-ce qu'au niveau de la syntaxe.

Le chiffre de +/- 15% des bugs dans linux dû aux "dépassement de buffer", soit. Mais que fait t'on des 85% des autres causes de bug ? On les oublies ?

Les dépassement de buffer ne sont qu'un seul type d'erreur de sureté mémoire. Rust prévient aussi les autre erreurs de sureté mémoire comme l'utilisation de mémoire déjà libérée, les doubles libérations, les accès à la mémoire non initialisée ou les accès concurrents à la même donnée mémoire.
Je connais pas le compte exact pour le cas particulier de Linux, mais dans quasiment tout les gros projets C et C++ qui ont fait le calcul, on arrive à environ 2/3 des vulnérabilités importantes liées à des erreur de sureté mémoire. Ça en laisse un bon tiers, mais ça reste un progrès très important.

Il vont disparaître d'eux-mêmes en réécrivant tout ?

Il n'y a pas forcément besoin de tout réécrire du jour au lendemain. C'est sur que réécrire de zéro une base de code complexe mais bien maitrisée n'est pas forcément une bonne idée. Rust n'a pas vocation à écraser systématiquement l’existant si on n'en ressent pas le besoin. Par contre pour les nouveaux projets et les cas on on a de toute façon besoin de faire une réécriture, il serait idiot de ne pas considérer ces avantages face aux langages qui n'offrent pas la même sécurité.

Avec de la rigueur, en ne se laissant pas emporté par les "ajouts" plus que douteux, en en restant à du code SIMPLE, LISIBLE et MAINTENABLE, le C est un langage plus que suffisant, même si lui aussi, il a évolué pas forcément dans le bon sens.

Je pense qu'il y a confusion entre le C et le C++, parce que le C est probablement le langage qui a le moins évolué ces 20 dernières années, et le peu qui a changé c'est surtout pour le rendre plus propre, pas plus complexe.

On est à une époque où, plus généralement, on complexifie inutilement trop de choses pas par nécessité, mais parce que c'est possible.
...

Alors autant je suis en partie d'accord sur le fait qu'on a beaucoup trop complexifié certaine choses, il faut pas non plus tomber dans le "c'était mieux avant". Il reste beaucoup de choses qui changent de manière tout à fait justifiées.

[imperio]

C++ est un compilateur C auquel on applique une surcouche. (Théoriquement, des directives de préprocessing suffisent)

C'est plus le cas depuis 20 ans déjà.

Les vulnérabilités viennent de la cohabitation de pointeurs sur data et pointeurs sur code. Les premiers permettent de trouver les seconds et même de les modifier (buffer overflow)

Rien à voir mais c'est bien essayé.

Je connais trop mal Rust pour savoir comment il sécurise la ram mais une simple garbage collection rend les pointeurs indépendants de la compilation. Les adresses changent à chaque appel de GC, le pointeur de pile n'est pas le registre SP du CPU... etc...

C'est, en très résumé, le problème de tous les compilos de cette génération.

Bon déjà Rust n'a pas de GC. Et je vois pas le lien entre un GC et un compilo, mais bon, le reste n'a guère de sens non plus donc on est pas à ça près.

Personnellement, je lis le C comme ma langue maternelle et sa disparition me met un méchant coup de vieux. J'espère que LLVM et WebAssembly permettront de continuer à écrire en C mais pour les performances imbattables, il faudra sans doute migrer vers Rust (ou go ?)

Lire un langage comme sa langue maternelle n'empêche pas ce langage d'être criblé de défaut (et c'est le cas de tous les langages, même Rust). Le problème dans le cas du C c'est que la gestion de la mémoire est manuelle et surtout qu'il y a énormément de undefined behaviours (

Code :

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

i++ + ++i

bonjouuuuur).

Que l'on n'utilise plus le C++, je peut le comprendre. Mais pas à cause de "fuites mémoire", mais plutôt parce qu'il est devenu un monstre tentaculaire, et cela totalement inutilement. J'ai arrêté le C++ (alors qu'à ses débuts, il apportait vraiment un + par rapport au C) il y a bien longtemps. J'ai eu ce déclic d'éviter le C++ quant j'ai voulus apprendre en profondeur le système de "Template", et que pour se faire, j'avais acheté le livre d'Andrescu (ou un nom assez proche, je ne me rappel plus bien), et qui nécessitait plus de 700 pages, pour expliquer comment maîtriser le sujet). 700 pages, pour une fonctionnalité, c'est délirant, tout simplement. Et ça ne s'est pas arrangé avec le temps. On a ajouté au C++ des fonctionnalité "de pointe" parce que c'était POSSIBLE, mais pas parce c'était NECESSAIRE. Le C++ est maintenant un gloubiboulga imbuvable.

Ah clairement, le C++ est horriblement complexe. Par-contre oui, la gestion de la mémoire (de manière générale) est aussi un sujet horriblement complexe que C++ ne gère pas du tout (un poil mieux que le C grâce aux destructeurs et les smart pointers mais ça reste insuffisant).

Quant au C, c'est un langage très simple, facilement compréhensible. Je suis d'accord qu'il PERMET de faire des bêtises, mais ce n'est pas à cause du C en lui-même, mais de développeurs incompétents et/ou dont on ne laisse pas le temps d'écrire du code propre et lisible. Si un charpentier se tape sur les doigts avec un marteau, ce n'est pas le marteau qu'on accuse.

Oula, dire que le C est simple, c'est une grave erreur. C'est un langage très difficile. Et c'est pas qu'il PERMET de faire des bêtises mais qu'il requiert du développeur une quantité phénoménale d'efforts supplémentaires pour s'assurer que tout fonctionne correctement. Et c'est sans parler de tous les undefined behaviours. Ce n'est pas une histoire de compétence (sinon je suppose que tu te considères meilleur que les ingés chez google/linux et consorts qui sont tous en train de lentement mais sûrement passer à Rust justement parce que la gestion de la mémoire notamment est trop complexe) mais bien d'un langage qui ne fournit pas ce qu'il faut pour permettre d'écrire du code qualitatif.

Il y a d'ailleurs un langage qui traite déjà ce "problème", et c'est le langage Ada. Le chiffre de +/- 15% des bugs dans linux dû aux "dépassement de buffer", soit. Mais que fait t'on des 85% des autres causes de bug ? On les oublies ? Il vont disparaître d'eux-mêmes en réécrivant tout ? Avec de la rigueur, en ne se laissant pas emporté par les "ajouts" plus que douteux, en en restant à du code SIMPLE, LISIBLE et MAINTENABLE, le C est un langage plus que suffisant, même si lui aussi, il a évolué pas forcément dans le bon sens.

Donc parce que ça ne résoud pas 100% des problèmes on doit laisser tomber ? Logique... Et le code du kernel linux ou même de projets aussi gros/vieux ont des millions de lignes de code. Clairement, même du code SIMPLE (comment ça peut être simple quand c'est aussi gros ? Mystère), LISIBLE (ba je suppose qu'avec des commentaires ça aide) et MAINTENABLE (ah ba là va falloir définir ce que t'entends par là), le C n'est pas suffisant (sinon pourquoi y aurait-il d'autres langages ?). Par-contre les seuls ajouts du C depuis C89 ce sont des types avec des tailles définies (j'apprécie d'être sûr que mon char soit signé et de un octet, ce qui n'est pas défini dans la norme C) et des undefined behaviours qui sont lentement mais sûrement définis.

On est à une époque où, plus généralement, on complexifie inutilement trop de choses pas par nécessité, mais parce que c'est possible.

Je suis totalement opposé à cette manie.

Ouf, ba faut avertir le monde et lui dire de s'arrêter parce que t'es pas d'accord alors.

...

Il y a des points sur lesquels je suis d'accord, mais les raisons ne sont pas juste "parce que les gens veulent tout complexifier pour le fun". C'est un mélange de marketing douteux, d'effet de mode bien pourri (l'écosystème front-end du web est une catastrophe) mais aussi des fois des besoins légitimes pour tenter de faire des projets bien cool pour faire avancer nos connaissances. Bref, les nuances, etc.

[Kannagi]

Personnellement, je lis le C comme ma langue maternelle et sa disparition me met un méchant coup de vieux. J'espère que LLVM et WebAssembly permettront de continuer à écrire en C mais pour les performances imbattables,

Ce n'est pas le C qui est performant, c'est le compilateur qui l'est nuance.
Rien n’empêcherai que Rust soit plus performant que du C, si son compilateur est mieux foutu.

il ressort que les pointeurs sur code sont trop exposés et que l'adressage des registres CPU est trop explicite (en particulier AX et le pointeur de pile).

J'ai rien compris, je ne vois pas le rapport avec le C, sauf s'il code en asm.
(Après si on parle de sécurité , je crois que faut d'abord oublier le x86).

[SQLpro]

En matière de SGBD il faudra donc se débarrasser des logiciels libre comme MariaDB, MySQL, SQLite et PostGreSQL. En effet, ils sont incapables de protéger la mémoire qu'ils utilisent et ceci pour deux raisons :
1) la gestion des threads et du cache est confiée à l'OS, alors que dans les SGBDR d'entreprise comme IBM DB2, Oracle Database ou MS SQL Server elle est traitée de manière interne et relativement protégée...
2) certains SGBDR d'Entreprise y ajoute des enclaves sécurisées pour les données sensibles, chiffrées... C'est le cas par exemple de Microsoft SQL Server
https://learn.microsoft.com/fr-fr/sq...l-server-ver16

A +