Discussion :

[Patrick Ruiz]

Google accorde une subvention d’1 million de $ à la Fondation Rust pour soutenir les efforts d’interopérabilité avec C++
Et faciliter la transition à Rust jugé supérieur pour sécuriser les logiciels

Google accorde une subvention d’un million de dollars à la Fondation Rust pour soutenir les efforts d’interopérabilité avec le langage C++. En toile de fond, le géant technologique cherche à faciliter la transition à Rust que de plus en plus d’observateurs jugent supérieur à C et à C++ pour la sécurisation des logiciels. La tendance dans l’industrie technologique est telle que même Linus Torvalds reconnaît que Rust, qui a été adopté comme deuxième langage pour le développement du noyau Linux, est digne d’intérêt d’un point de vue technique.


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

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

C’est là qu’intervient le langage Rust considéré par des acteurs de la filière comme le futur de la programmation système en lieu et place du langage C ou encore comme la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées. Chez Amazon par exemple, on 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 de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++. Ainsi, les adoptions du langage Rust visent à mettre à profit ces atouts du langage sur le C et le C++.

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)); 
}

Source : Google

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

[prisme60]

Dans mon entreprise, je me bas pour qu'on mette en place le Rust, que j'utilise sur mes projets persos.
Le seul frein, c'est qu'en général on part d'un existant (du bon vieux code legacy C++ comme on l'aime, miamm!), et que tout refaire prendrait trop de temps. Faire des mixes de langages, c'est assez déconseillé, la compilation, le debug, tout devient plus compliqué.

Dans le cadre du Web, on peut aussi utiliser un Framework Rust qui fait du WebAssembly. Je pense en ce moment à Leptos qui se démarque des autres Frameworks (Yew, Sycamore, Dioxus). Le problème, c'est que c'est en pleine évolution, et il est difficile de trouver un framework pérenne qui existera encore dans 10 ans. Les technologies du Web sont très versatiles. Il suffit de voir React, AngularJS, ... où les versions se suivent avec des ruptures de compatibilité ou tout simplement la technologie est devenue désuète / obsolète (Par exemple : JQuery).

[abriotde]

Le problème n'est-il pas plutôt celui de la qualité des développeurs ?

Ca c'est un mythe. Évidement, qu'un bon développeur expérimenté fera un code de meilleure qualité et donc moins de problème de sécurité. Néanmoins, dans la vrai vie, on a besoin de former des jeunes et donc d'avoir des développeurs de tout niveau. Évidemment, qu'il y aura de la relecture par des développeurs plus expérimenté, mais cela ne suffit pas. Dans la vrai vie, aussi parfait soit le développeurs et tous les outils que l'on peut mettre, l'humain est toujours faillible. Alors évidement, en mettant bretelles et ceintures, on arrive à un code de qualité, peut-être équivalent à Rust. Mais au final, s'il faut acheter des analyseurs statique et dynamiques de codes, se payer des développeurs de haut vols et beaucoup de relecture pour au final ne pas pouvoir faire un patch "à l'arrache" sans risques ce n'est pas viable.

En fait c'est détourner la question que de dire, oui mais C++ peut-être sécurisé. C'est oublié que l'on a un outils (Rust) qui fait déjà tout (ou presque) sans avoir besoin d'autant de précautions. Après, évidemment, comme pour COBOL, ce n'est pas demain que l'on aura tout recodé en Rust et quand le code est en C++, il n'est pas vraiment possible de rajouter un bout de code en Rust (C'est un peu l'objet de cette subvention de Google). La base de code en C/C++ est immense (Sans doute bien plus grande que celle de COBOL au moins aujourd'hui), les développeurs C/C++ ont donc du travail pour au moins 50 ans.
J'ai une mention spécial pour C. C est un peu à part. Il est un peu irremplaçable dans certains cas dans l'embarqué ou dans le très bas niveau. Rust ou C++ se prêtent assez mal à des manipulation très spécifiques et pas toujours sécurisé mais nécessaire. Quand on travail au plus bas niveau il faut parfois faire des choses qui n'ont pas trop de sens autrement, et C est un peu le seul à pouvoir le faire. C'est cependant un code très restreint en volume. Et même parfois ce n'est pas assez bas niveau, on doit passer en assembleur. A cette exception près, le C devrait être remplacer par le Rust. D'ailleurs, le choix du C au lieu du C++, à l'exception du très bas niveau, est fait pour des questions de performances, car en C++ on peut trop facilement utiliser des raccourcis qui ne sont pas optimisé en performances (Rapides mais pas très rapides), je pense entre autre aux smart-pointer... Ceux qui connaissent comprendront les 3 points de suspensions, pour les autres disons que simplement ce sont justement les super-pouvoirs de C++ qui sont vanté comme sécurisés.

[fdecode]

Ca c'est un mythe. Évidement, qu'un bon développeur expérimenté fera un code de meilleure qualité et donc moins de problème de sécurité. Néanmoins, dans la vrai vie, on a besoin de former des jeunes et donc d'avoir des développeurs de tout niveau. Évidemment, qu'il y aura de la relecture par des développeurs plus expérimenté, mais cela ne suffit pas. Dans la vrai vie, aussi parfait soit le développeurs et tous les outils que l'on peut mettre, l'humain est toujours faillible. Alors évidement, en mettant bretelles et ceintures, on arrive à un code de qualité, peut-être équivalent à Rust. Mais au final, s'il faut acheter des analyseurs statique et dynamiques de codes, se payer des développeurs de haut vols et beaucoup de relecture pour au final ne pas pouvoir faire un patch "à l'arrache" sans risques ce n'est pas viable.

Merci d'avoir verbalisé ce constat qui m'a fait abandonner le C++ il y a une grosse décennie.

J'ai une mention spécial pour C. C est un peu à part. Il est un peu irremplaçable dans certains cas dans l'embarqué ou dans le très bas niveau. Rust ou C++ se prêtent assez mal à des manipulation très spécifiques et pas toujours sécurisé mais nécessaire. Quand on travail au plus bas niveau il faut parfois faire des choses qui n'ont pas trop de sens autrement, et C est un peu le seul à pouvoir le faire.

Je ne sais pas si le C est irremplaçable.

Il y a des projets d'OS bien avancés écrits en Rust https://www.redox-os.org/.

Le unsafe est possible en Rust, mais il faut en avoir une véritable maîtrise: pour développeurs expérimentés en Rust.

Enfin, ce n'est pas parce qu'un code est sécurisé qu'il est nécessairement moins rapide ou moins bas niveau. L'exemple suivant [Playground] montre le code généré suite à une compilation Release. L'utilisation de références mutables plutôt que des pointeurs induit un code machine simplifié, qui est similaire à ce qu'on pourrait obtenir avec le mot clef `restrict` du C (les références mutables interdisent le chevauchement en mémoire):

[chrtophe]

Je ne suis pas développeur, mais l'exemple ne montre rien de concret, pas de code dans les fonctions.

Je suppose qu'un compilateur digne de ce nom ne ferait même pas ce code, qui ne contient qu'une signature de fonction.

Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise pour s'en sortir car o en reviendrait au même travers du C/C++, que Rust est censé pallier.

Et qu'en est il des fonctions de la libc ? il y a une bibliothèque équivalente ? on peut appeler ses fonctions (probablement en unsafe) ?

[fdecode]

Je ne suis pas développeur, mais l'exemple ne montre rien de concret, pas de code dans les fonctions.

Je ne vais pas vous faire un code complet... et surement pas sur le playground... Pour ce qui est de l'exemple, il est là pour illustrer ce que peut apporter la sémantique du mode safe en termes d'optimisation de code. Dans le cas présent, cela permet d'économiser des échanges avec la mémoire. Sans le mot-clé restrict en C ou certaines directives non standard en C++ et propres au compilateur, vous ne pouvez pas obtenir ce genre d'optimisation, qui est par ailleurs permis par le FORTRAN.

Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise

En effet, mais un développeur inexpérimenté doit-il faire du code critique dans des développements systèmes? Car c'est un peu ça l'intérêt du unsafe en Rust. En dehors de fractions de codes critiques devant être particulièrement optimisés, je ne vois pas l'intérêt d'un usage de unsafe.

Et qu'en est il des fonctions de la libc ? il y a une bibliothèque équivalente ? on peut appeler ses fonctions (probablement en unsafe) ?

Actuellement, la dépendance de Rust est liée au linkage. L'infrastructure de l'OS d'accueil est utilisé. Typiquement Microsoft C++ build tools pour windows. Des librairies compilées de la libc, sans doute, pour linux.
L'OS Redox fournit une relibc implémentée en Rust https://github.com/redox-os/relibc.
Cette dépendance venant au moment du linkage, elle est transparente au niveau du code en rust lors de l'utilisation de la libraire standard; au pire, on héritera de contraintes de l'OS.
Bien entendu, il est possible d'appeler des fonctions provenant d'une librairie C en utilisant du unsafe. Ce cas d'usage de unsafe est bien documenté et ne pose aucun problème. Le vrai problème vient d'un usage de unsafe qui serait UB (undefined behavior). Et c'est la connaissance des cas UB qui nécessite une certaine expertise. Car il y en a beaucoup plus qu'en C.

[fdecode]

qui ne contient qu'une signature de fonction.

???
La signature de la fonction, c'est ça:

Code :

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

 fn adds(a: &mut i32, b: &mut i32)

Ça, c'est le code de la fonction (j'ajoute b à a, puis j'ajoute b à a; comme ce sont des références mutables, rust interdit la situation où a et b partagent le même emplacement mémoire, ce qui rend inutile les échanges en mémoire par movl):

Code :

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

{ *a += *b; *a += *b; }

Je suppose qu'un compilateur digne de ce nom ne ferait même pas ce code, qui ne contient qu'une signature de fonction.

En pratique, le compilateur Rust vous génèrera un message d'alerte si votre projet contient du code non publique (donc non utilisable dans un autre projet), qui n'est jamais utilisé. Cette fonctionnalité vient par défaut, et peut être désactivée pour certaines parties du code. Visiblement, la directive no_mangle désactive ce message d'alerte. J'espère avoir répondu à votre question non formulée...

[chrtophe]

J'ai pas utilisé le bon terme, je voulais dire prologue.

Merci pour la réponse en tout cas.

[fdecode]

Pour le unsafe, il ne faudrait pas qu'un développeur inexpérimenté l'utilise pour s'en sortir car o en reviendrait au même travers du C/C++

Je n'avais pas noté cette petite subtilité psychologique dans votre question à la première lecture: le développeur inexpérimenté qui transgresse les règles pour faire le job vite fait mais salement fait.
Vous avez différents outils de diagnostic à disposition: miri pour détecter à l'exécution des undefined behaviour ; des add-on à cargo pour faire une statistique des codes unsafe, etc.
Mais le plus simple est d'interdire l'usage des unsafe en plaçant la directive #![forbid(unsafe_code)] à la racine du projet ou du sous-projet.

[Pyramidev]

Mais le plus simple est d'interdire l'usage des unsafe en plaçant la directive #![forbid(unsafe_code)] à la racine du projet ou du sous-projet.

Remarque : Depuis Rust 1.74.0, la manière idiomatique est de le faire dans le Cargo.toml :

Code :

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

1
2
[lints.rust]
unsafe_code = "forbid"