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 |
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 
Envoyé par chrtophe
Merci d'avoir verbalisé ce constat qui m'a fait abandonner le C++ il y a une grosse décennie.