Google a adopté Rust dans Android pour des raisons de sécurité

Citation:

---

Envoyé par fdecode

...

---

Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carrément impossible, l'algorithme de la racine carré-inverse rapide ne semble pas non plus pouvoir être tolérée par le compilateur (spéculatif, je n'ai pas essayé ; mais étant donné qu'il faille jouer avec les différents motifs mémoire fonction du types des nombres, en Rust ça doit être un enfer) ; la compilation est affreusement lente quand il faut récupérer tous les paquets Cargo pour un gros projet. Franchement passé la hype, je ne vois pas comment Rust pourrait avoir une trajectoire différente d'Ocaml ou Haskell, c'est un truc d'université/laboratoire qui ne semble pas pouvoir s'adapter à la réalité des entreprises.

Citation:

---

Envoyé par 23JFK

Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carrément impossible, l'algorithme de la racine carré-inverse rapide ne semble pas non plus pouvoir être tolérée par le compilateur (spéculatif, je n'ai pas essayé ; mais étant donné qu'il faille jouer avec les différents motifs mémoire fonction du types des nombres, en Rust ça doit être un enfer) ; la compilation est affreusement lente quand il faut récupérer tous les paquets Cargo pour un gros projet. Franchement passé la hype, je ne vois pas comment Rust pourrait avoir une trajectoire différente d'Ocaml ou Haskell, c'est un truc d'université/laboratoire qui ne semble pas pouvoir s'adapter à la réalité des entreprises.

---

Cela a l'air très personnels et émotionnels comme griefs. Je vais simplement répondre à la demande concrète de votre message: "algorithme de la racine carré-inverse rapide" (de quake, je suppose).
Dans la mesure où c'est un algorithme de calcul très approximatif, et que l'instruction SSE RSQRT existe désormais, il me paraît assez peu intéressant, mais il a quand même été facile de trouver un exemple d'implémentation [playground]:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

fn inv_sqrt(x: f32) -> f32 { let i = x.to_bits(); let i = 0x5f3759df - (i >> 1); let y = f32::from_bits(i);   y * (1.5 - 0.5 * x * y * y) }     fn print_both(v: f32) { println!("quake: {}", inv_sqrt(v)); println!("real: {}", 1.0 / v.sqrt()); println!(); }   fn main() { print_both(4.0); print_both(10.0); print_both(3.1415); }

---

Ceci-dit, le code de quake n'est pas très intéressant puisque le calcul exact tient en 3 instructions machine.

Citation:

---

Envoyé par 23JFK

Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carrément impossible

---

Je vais supposer que tu t'es mal expliqué parce qu'il est évident que Rust peut faire des bibliothèques. Le dépôt standard de Rust contient plus de 150 000 crates dont la plupart sont des bibliothèques.
Si tu voulais parler de bibliothèque qui s'interface avec d'autre langages, c'est aussi possible, à condition d'avoir une interface qui respecte l'ABI C. C'est en effet limitant, mais c'est pareil pour tout les langages qui veulent s'interfacer avec d'autres.

Citation:

---

Envoyé par 23JFK

l'algorithme de la racine carré-inverse rapide ne semble pas non plus pouvoir être tolérée par le compilateur (spéculatif, je n'ai pas essayé ; mais étant donné qu'il faille jouer avec les différents motifs mémoire fonction du types des nombres, en Rust ça doit être un enfer) ;

---

C'est un peu le problème, beaucoup de gens ont un avis très tranché sur Rust, basé sur des spéculations fausses. Rust peut tout à fait faire des manipulations de bit basiques, c'est juste que les hacks comme les conversions douteuses ou les dépassement volontaires, sont remplacés par des fonctions explicites pour être sur qu'ils sont fait à dessein et que ce n'est pas des erreurs.

Citation:

---

Envoyé par 23JFK

la compilation est affreusement lente quand il faut récupérer tous les paquets Cargo pour un gros projet.

---

Ça c'est vrai, mais pour le coup on ne compile pas un gros projet de zéro si souvent que ça. Quand on recompile un projet sur lequel on travaille, ça va beaucoup plus vite. Ça reste plus lent que le C mais pas vraiment plus lent que des langages plus complexes comme le C++.

Citation:

---

Envoyé par fdecode

Ceci-dit, le code de quake n'est pas très intéressant puisque le calcul exact tient en 3 instructions machine.

---

Il me semble que la racine inverse rapide est encore pas mal utilisée dans la 3D, l’approximation étant relativement bonne et le gain sensible. Toutes les instructions machines ne se valent pas, 3 instructions complexes, peuvent prendre plus de cycles qu'une dizaine d'instructions plus simples.

Après vérification, la racine inverse rapide est environ 2,5 fois plus rapide sur ma machine.

Citation:

---

Envoyé par Uther

Après vérification, la racine inverse rapide est environ 2,5 fois plus rapide sur ma machine.

---

Je n'ai pas fait de tests de performance pour ma part.
Le résultat de la compilation (en release) aboutit à ça:

Code:

---

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

.LCPI4_0: .long 0xbf000000   .LCPI4_1: .long 0x3fc00000   inv_sqrt_quake: movd %xmm0, %eax shrl %eax movl $1597463007, %ecx subl %eax, %ecx movd %ecx, %xmm1 mulss .LCPI4_0(%rip), %xmm0 mulss %xmm1, %xmm0 mulss %xmm1, %xmm0 addss .LCPI4_1(%rip), %xmm0 mulss %xmm1, %xmm0 retq   .LCPI5_0: .long 0x3f800000   inv_sqrt: sqrtss %xmm0, %xmm1 movss .LCPI5_0(%rip), %xmm0 divss %xmm1, %xmm0 retq

---

Donc 10 instructions pour la méthode rapide contre 3 instructions pour la méthode exacte.
Toutefois, la méthode rapide n'utilise pas de division ni d'opération racine carrée.

Ceci-dit, si je devais vraiment l'implémenter pour ma part, j'inlinerais l'instruction rsqrtss.

C'est pour ça que le nombre d'instruction machine n'est pas une métrique suffisante pour mesurer la performance. Il faut aussi avoir une bonne idée de l'efficacité des instructions. Et encore le nombre de cycle d'une instruction peut varier en fonction du contexte.

Les instructions de division et de racines carrée sont connues pour être lentes. Toute l'intérêt de l’algorithme de Quake, c'est qu'il n'utilise rien de plus complexe que la multiplications.

Citation:

---

Envoyé par Uther

C'est pour ça que le nombre d'instruction machine n'est pas une bonne métrique pour mesurer la performance. Il faut aussi avoir une bonne idée de l'efficacité des instruction. Et encore le nombre de cycle d'une instruction peut varier en fonction du contexte.

Les instructions de division et de racines carrée sont connues pour être lentes. Toute l'intérêt de l’algorithme de quake, c'est qu'il n'utilise rien de plus complexe que la multiplications.

---

Bon, pour compléter ma réponse, voici une variante qui utilise l'instruction sse rsqrt.
C'était plus facile que je ne le pensais. Je n'ai pas eu besoin d'inliner de l'assembleur (Playground) :

Code:

---

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

mod inner { #![allow(unused)] #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; #[target_feature(enable = "sse")] pub unsafe fn inv_sqrt_sse(four_floats: [f32;4]) -> [f32;4] { let reg: __m128 = bytemuck::cast(four_floats); let inv_sqrt4 = _mm_rsqrt_ps(reg); bytemuck::cast(inv_sqrt4) } }   #[no_mangle] fn inv_sqrt_sse(four_floats: [f32;4]) -> [f32;4] { unsafe { inner::inv_sqrt_sse(four_floats) } }   #[no_mangle] fn inv_sqrt_quake(x: f32) -> f32 { let i = x.to_bits(); let i = 0x5f3759df - (i >> 1); let y = f32::from_bits(i);   y * (1.5 - 0.5 * x * y * y) }   #[no_mangle] fn inv_sqrt(x: f32) -> f32 { 1.0 / x.sqrt() }     fn print_both(v: f32) { println!("quake: {}", inv_sqrt_quake(v)); println!("real: {}", inv_sqrt(v)); println!(); }   fn main() { print_both(4.0); print_both(10.0); print_both(3.1415);   println!("sse features"); if is_x86_feature_detected!("sse") { let f_4 = [4.0, 10.0, 3.1415, 2.0]; let sf_4 = inv_sqrt_sse(f_4); for (f,sf) in f_4.into_iter().zip(sf_4) { println!("rsqrt({f}) = {sf}"); } } }

---

J'utilise des fonctions du core Rust pour l'architecture x86 (par conséquent, non compilable sur d'autres architectures). Cela se programme en unsafe : là on touche à des choses plutôt nightly pour l'instant. Bien sûr, ces quelques lignes unsafe ne sont pas UB.
Dans quelques années (ou mois), ces fonctions de calcul SIMD seront pleinement accessibles en safe et en stable.
Voici le code compilé de la fonction basée sur l'architecture sse:

Code:

---

1 2 3 4 5 6 7

inv_sqrt_sse: movq %rdi, %rax movups (%rsi), %xmm0 rsqrtps %xmm0, %xmm0 movups %xmm0, (%rdi) retq

---

Mais même après cet exemple, il va encore y avoir quelqu'un qui va m'écrire que 'Rust ne permet pas de faire de l'optimisation de code', 'parce qu'on ne peut pas travailler bit à bit', 'qu'on n'accède pas aux subtilités du code machine', ♫♫♫♬ etc.

Citation:

---

Envoyé par fdecode

...

---

Ou que l'on obligé de faire de l'unsafe et l'unstable.:aie:

Citation:

---

Envoyé par 23JFK

Ou que l'on obligé de faire de l'unsafe et l'unstable.:aie:

---

Et bien non! Il ne vous a pas échappé si vous êtes allés sur le Playground, que le code en question fonctionne dans une version stable de Rust:
Pièce jointe 659312
Ce qui est nighty, c'est la librairie SIMD, pas les instructions machines répliquées dans le core Rust.

Pour ce qui est de l'unsafe, il est tout naturellement utilisé ici pour inclure du code machine, donc extérieur à Rust, tout comme on utilise de l'unsafe pour inclure une librairie C : cela sert à isoler les parties du code non contrôlées par la sémantique de sécurisation de Rust. Il s'agit pour le coup du contexte d'utilisation le plus simple de l'unsafe: délimiter le code externe. Pas de risque d'UB. Vous ne risqueriez donc pas d'y perdre des dents.

Citation:

---

Envoyé par fdecode

...

---

Désolé, mais dans le code d'en haut, from_bits() semble tagué unstable. :aie:

Citation:

---

Envoyé par 23JFK

Désolé, mais dans le code d'en haut, from_bits() semble tagué unstable. :aie:

---

f32::from_bits est stable depuis Rust 1.20.0. C'est le fait que cette fonction soit const (l'équivalent de constexpr en C++) qui n'est pas encore stable.

Citation:

---

Envoyé par 23JFK

Désolé, mais dans le code d'en haut, from_bits() semble tagué unstable. :aie:

---

En complément de la réponse de Pyramidev:

https://doc.rust-lang.org/book/appen...htly-rust.html

Unstable Features

There’s one more catch with this release model: unstable features. Rust uses a technique called “feature flags” to determine what features are enabled in a given release. If a new feature is under active development, it lands on master, and therefore, in nightly, but behind a feature flag. If you, as a user, wish to try out the work-in-progress feature, you can, but you must be using a nightly release of Rust and annotate your source code with the appropriate flag to opt in.

If you’re using a beta or stable release of Rust, you can’t use any feature flags. This is the key that allows us to get practical use with new features before we declare them stable forever. Those who wish to opt into the bleeding edge can do so, and those who want a rock-solid experience can stick with stable and know that their code won’t break. Stability without stagnation.

This book only contains information about stable features, as in-progress features are still changing, and surely they’ll be different between when this book was written and when they get enabled in stable builds. You can find documentation for nightly-only features online.

Autrement dit, il n'est pas possible d'utiliser des composants nightly dans une configuration stable de Rust. Le fait que le playground soit exécuté en mode stable impose donc que tout le code utilisé soit stable.

Il existe des moyens de contourner cette règle, mais un tel crime est tout à fait déconseillé :

https://crates.io/crates/nightly-crimes

J'ai testé cette macro de Mara Bos et elle semble toujours fonctionner (mais pas son exemple, puisque la syntaxe expérimentale box value a été abandonnée).

Marrant, je savais qu'on pouvait contourner l'interdiction d'utiliser les fonctionnalités nightly, mais je pensais que le seul moyen était d'utiliser une variable d’environnement non documentée.
Je savais pas que c'était possible avec une simple macro même si elle est tordue, pour le coup ça ressemble plutôt a un bug.

Citation:

---

Envoyé par Uther

pour le coup ça ressemble plutôt a un bug.

---

Un bug qui date de 3 ans, sachant qui est Mara Bos?

https://www.rust-lang.org/governance...ership-council

Non, je ne pense pas que ce soit un bug, ou alors, c'est considéré comme mineur. Peut-être une tolérance qu'ils rendront inutilisable un jour.

Bonus:

https://marabos.nl/atomics/

https://cppcast.com/rust_lt_eq_gt_cpp/

https://www.youtube.com/watch?v=DnYQKWs_7EA

Je sais qui est Mara Bos, mais il y a des bugs bien plus vieux et plus impactants que ça dans le compilateur qui ne sont pas encore corrigés car ils impliqueraient une refonte technique complexe et qu'on considère improbable de les déclencher sans faire exprès.
Le plus connu étant le bug https://github.com/rust-lang/rust/issues/57893 qui permet de faire un transmute sans bloc unsafe. En théorie il casse complètement la sécurité de Rust mais vu que le code qui peut déclencher le problème n'a pas vraiment de sens dans du code normal, il n'est pas considéré urgent et attend la refonte du borrow checker à venir.

Au vu du code tordu de la crate de Mairia Bos, j'ai l'impression qu'on est bien dans cette catégorie.

Citation:

---

Envoyé par Uther

Je sais qui est Mara Bos, mais il y a des bugs bien plus vieux et plus impactants que ça dans le compilateur qui ne sont pas encore corrigés car ils impliqueraient une refonte technique complexe et qu'il sont considérés impossible à déclencher sans faire exprès.
Le plus connu étant le bug https://github.com/rust-lang/rust/issues/57893 qui permet de faire un transmute sans bloc unsafe. En théorie il casse complètement la sécurité de Rust mais vu les condition improbables pour le déclencher, il n'est pas considéré urgent et attend la refonte du borrow checker a venir.

---

Excellent! Je ne connaissais pas!

En relisant plus attentivement, ce n'est en effet pas un bug mais une exploitation particulièrement gore des macro procédurales et de la variable d’environnement non documentée dont je parlais.

En gros le code du projet qui contient la macro est transformé en un sous projet et le projet en cours deviens un script de compilation qui va compiler le sous-projet avec la variable d’environnement secrète qui permet d'ignorer l’interdiction. Bref une horreur a éviter.

Citation:

---

Envoyé par Uther

En relisant plus attentivement, ce n'est en effet pas un bug mais une exploitation particulièrement gore des macro procédurales et de la variable d’environnement non documentée dont je parlais.

En gros le code du projet qui contient la macro est transformé en un sous projet et le projet en cours deviens un script de compilation qui va compiler le sous-projet avec la variable d’environnement secrète qui permet d'ignorer l’interdiction. Bref une horreur a éviter.

---

Je n'ai pas eu le temps de lire le code, mais je me doutais d'un truc comme ça.
Les macros procédurales permettent des choses vraiment tordues, et il faut s'astreindre à ne pas céder à la tentation.
Moi il m'était arrivé de m'égarer à associer une macro procédurale avec un serveur pour certaines historisations et contrôles de métadonnées (e.g. gérer certaines constantes associées à des types) lors des compilations. C'était une vraie machine à gaz, surtout quand on utilisait en plus l'analyseur syntaxique de l'IDE.

La transition de Google vers des langages à mémoire sécurisée comme Rust prendra plusieurs années : en attendant, Google applique également des principes de conception sécurisée à sa base de code C++ existante.

Selon Google, la transition C++ vers Rust prendra plusieurs années. Pour garantir la sécurité de ces utilisateurs, Google décide d'appliquer également les principes de conception sécurisée à sa base de code C++ existante "chaque fois que cela est possible". Google a partagé comment elle a déployé ses principes ainsi que l'impact qu'elle a constaté dans son code C++.

Dans le monde de la programmation, les langages C et C++ ont longtemps dominé le développement de firmware. Cependant, Google a récemment fait une déclaration audacieuse : remplacer ces langages par Rust serait non seulement possible, mais aussi relativement facile. Les ingénieurs d'Android avait notamment affirmé : "Vous verrez à quel point il est facile de renforcer la sécurité avec des remplacements Rust".

Un responsable de Google avait même déclaré : "Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++". Ajoutant : "Nous avons noté une réduction de 50 % de l’effort nécessaire pour mettre sur pied un service en langage Rust ainsi que pour en assurer la maintenance". Si ces déclarations lancent un débat de la productivité entre Rust et C++, elles confirment que Google est convaincu de la transition C++ vers Rust.

Cependant, Google a récemment annoncé que sa transition vers le Safe Coding et les langages à mémoire sécurisée "prendra plusieurs années". C'est pourquoi ils appliquent également les principes de conception sécurisée à la base de code C++ existante "dans la mesure du possible". Google précise qu'ils travaillent également à "faciliter l'interopérabilité avec les langages à mémoire sécurisée". La migration de C++ vers Safe Buffers réduit l'écart entre les langages, "ce qui simplifie l'interopérabilité et potentiellement même une éventuelle traduction automatisée".

En effet, les attaquants exploitent régulièrement les vulnérabilités liées à la sécurité de la mémoire spatiale, qui se produisent lorsque le code accède à une allocation de mémoire en dehors des limites prévues, pour compromettre les systèmes et les données sensibles. Ces vulnérabilités représentent un risque majeur pour la sécurité des utilisateurs. Sur la base d'une analyse de Google, les vulnérabilités de sécurité spatiale représentent 40 % des exploits de sécurité de la mémoire au cours de la dernière décennie :

Pièce jointe 661881

Voici les déclarations de Google concernant sa base de code C++ :

Citation:

---

Google adopte une approche globale de la sécurité de la mémoire. L'un des éléments clés de notre stratégie est le codage sécurisé et l'utilisation de langages sans risque pour la mémoire dans le nouveau code. Cela entraîne une diminution exponentielle des vulnérabilités liées à la sécurité de la mémoire et améliore rapidement le niveau de sécurité global d'une base de code, comme le montre notre article sur l'évolution d'Android vers la sécurité de la mémoire.

Toutefois, cette transition prendra plusieurs années, le temps d'adapter nos pratiques de développement et notre infrastructure. Pour garantir la sécurité de nos milliards d'utilisateurs, nous devons donc aller plus loin : nous appliquons également les principes de conception sécurisée à notre base de code C++ existante chaque fois que cela est possible.

À cette fin, nous nous efforçons d'introduire la sécurité de la mémoire spatiale dans le plus grand nombre possible de nos bases de code C++, y compris Chrome et la base de code monolithique qui alimente nos services.

Nous avons commencé par activer la libc++ renforcée, qui ajoute la vérification des limites aux structures de données C++ standard, éliminant ainsi une catégorie importante de bogues liés à la sécurité spatiale. Bien que le C++ ne devienne pas totalement sûr pour la mémoire, ces améliorations réduisent les risques, comme nous l'expliquons plus en détail dans notre point de vue sur la sécurité de la mémoire, ce qui permet d'obtenir des logiciels plus fiables et plus sûrs.

---

Voici comment Google met en place la libc++ renforcée dans sa base de code :

Structures de données dont les limites sont vérifiées : Le fondement de la sécurité spatiale

L'une des principales stratégies de Google pour améliorer la sécurité spatiale en C++ consiste à mettre en place un contrôle des limites pour les structures de données courantes, en commençant par renforcer la bibliothèque standard C++ (libc++ de LLVM). La libc++ renforcée introduit un ensemble de contrôles de sécurité conçus pour détecter les vulnérabilités telles que les accès hors limites en production.

Par exemple, la libc++ renforcée garantit que chaque accès à un élément d'un std::vector reste dans les limites qui lui ont été attribuées, en empêchant les tentatives de lecture ou d'écriture au-delà de la zone de mémoire valide. De même, la libc++ renforcée vérifie qu'un std::optional n'est pas vide avant d'autoriser l'accès, empêchant ainsi l'accès à une mémoire non initialisée.

Cette approche reflète ce qui est déjà une pratique standard dans de nombreux langages de programmation modernes comme Java, Python, Go et Rust. Ils intègrent tous la vérification des limites par défaut, reconnaissant son rôle crucial dans la prévention des erreurs de mémoire. Le C++ a été une exception notable, mais des efforts comme la libc++ renforcée visent à combler cette lacune. Il convient également de noter qu'un renforcement similaire est disponible dans d'autres bibliothèques standard C++, telles que libstdc++.


Rehausser le niveau de sécurité de base dans tous les domaines

Après le déploiement de la libc++ renforcée dans Chrome en 2022, Google a décidé de la mettre par défaut dans ses systèmes de production côté serveur. Google affirme que cela a amélioré la sécurité de la mémoire spatiale dans tous ses services, y compris les composants essentiels aux performances de produits tels que Search, Gmail, Drive, YouTube et Maps. Bien qu'un très petit nombre de composants restent exclus, Google annonce travailler activement pour réduire ce nombre et à relever la barre de la sécurité dans tous les domaines, même dans les applications présentant un risque d'exploitation plus faible.

Google commente notamment :

Citation:

---

L'impact de ces changements sur les performances a été étonnamment faible, bien que la base de code C++ moderne de Google fasse un usage intensif de libc++. Le renforcement de libc++ a eu un impact moyen de 0,30 % sur les performances de nos services (oui, seulement un tiers de pour cent).

Cela est dû à la fois à la capacité du compilateur à éliminer les vérifications redondantes lors de l'optimisation et à la conception efficace de la libc++ renforcée. Bien qu'une poignée de chemins de code critiques en termes de performances requièrent encore l'utilisation ciblée d'accès explicitement non sécurisés, ces cas sont soigneusement examinés en termes de sécurité. Des techniques telles que les optimisations guidées par le profil ont encore amélioré les performances, mais même sans ces techniques avancées, la surcharge de la vérification des limites reste minime.

Nous surveillons activement l'impact de ces vérifications sur les performances et nous nous efforçons de minimiser toute surcharge inutile. Par exemple, nous avons identifié et corrigé une vérification inutile, ce qui a conduit à une réduction de 15 % de la surcharge (de 0,35 % à 0,3 %), et nous avons reversé la correction au projet LLVM pour partager les avantages avec la communauté C++ au sens large.

Si, dans la plupart des cas, la surcharge de libc++ renforcée est minime pour les applications individuelles, son déploiement à l'échelle de Google a nécessité un engagement substantiel en termes de ressources informatiques. Cet investissement souligne notre volonté d'améliorer la sûreté et la sécurité de nos produits.

---

https://youtu.be/umhxH_AxG7I

Des tests à la production

L'activation de libc++ renforcée nécessite un déploiement en plusieurs étapes afin d'éviter de perturber accidentellement les utilisateurs ou de provoquer une panne. Voici les étapes que Google a suivi :

Citation:

---

1. Tests : Nous avons activé pour la première fois la libc++ renforcée dans nos tests il y a plus d'un an. Cela nous a permis d'identifier et de corriger des centaines de bogues non détectés auparavant dans notre code et nos tests.
   
2. Adaptation : Nous avons laissé le runtime renforcé "travailler" dans nos environnements de test et de pré-production, ce qui a donné aux développeurs le temps de s'adapter et de résoudre les nouveaux problèmes qui sont apparus. Nous avons également procédé à des évaluations approfondies des performances, en veillant à ce que l'impact sur l'expérience de nos utilisateurs soit minimal.
   
3. Déploiement progressif de la production : Nous avons ensuite déployé la version renforcée de libc++ en production sur plusieurs mois, en commençant par un petit ensemble de services et en l'étendant progressivement à l'ensemble de notre infrastructure. Nous avons surveillé de près le déploiement, en corrigeant rapidement tout plantage ou régression des performances.

---

Google a également partagé l'impact de ce choix dans la base de code C++ :

Prévention des exploits : La version renforcée de libc++ a perturbé un exercice interne de l'équipe rouge (test d'attaque) et en aurait empêché un autre qui s'est déroulé avant le renforcement. Selon Google, cela démontre son efficacité à contrecarrer les exploits. Les contrôles de sécurité ont permis de découvrir plus de 1 000 bogues et permettraient d'éviter 1 000 à 2 000 nouveaux bogues par an au rythme actuel de développement du C++.

Amélioration de la fiabilité et de la correction : Le processus d'identification et de correction des bogues découverts par la libc++ renforcée a entraîné une réduction de 30 % du taux de défaillance de segmentation de base dans la production, ce qui indique une amélioration de la fiabilité et de la qualité du code. Au-delà des pannes, les vérifications auraient également permis de détecter des erreurs qui se seraient autrement manifestées sous la forme d'un comportement imprévisible ou d'une corruption de données.

Pièce jointe 661882

Débogage facilité : La libc++ renforcée aurait permis d'identifier et de corriger de nombreux bogues qui se cachaient dans la base de code C++ de Google depuis plus de dix ans. Les vérifications transforment de nombreuses corruptions de mémoire difficiles à diagnostiquer en erreurs immédiates et faciles à déboguer, ce qui permet aux développeurs d'économiser un temps et des efforts précieux.

Combler le fossé avec des langages à mémoire sécurisée

Si le renforcement de libc++ offre des avantages immédiats en ajoutant la vérification des limites aux structures de données standard, il ne s'agit que d'une pièce du puzzle en ce qui concerne la sécurité spatiale. Google continue d'étendre le contrôle des limites à d'autres bibliothèques et travaillent à la migration de son code vers Safe Buffers, qui exige que tous les accès soient contrôlés par les limites. Pour la sécurité spatiale, les structures de données renforcées, y compris leurs itérateurs, et les Safe Buffers sont nécessaires.

Google commente ce choix en concluant :

Citation:

---

La libc++ renforcée est un moyen pratique et efficace d'améliorer la sécurité, la fiabilité et le débogage du code C++ avec un surcoût minimal. C'est pourquoi nous encourageons vivement les organisations qui utilisent le langage C++ à activer le mode renforcé de leur bibliothèque standard de manière universelle et par défaut.

Chez Google, l'activation du mode renforcé de libc++ n'est que la première étape de notre voyage vers une base de code C++ spatialement sûre. En développant la vérification des limites, en migrant vers Safe Buffers et en collaborant activement avec l'ensemble de la communauté C++, nous souhaitons créer un avenir où la sécurité spatiale sera la norme.

---

Conclusion

Ces annonces peuvent questionner sur le projet de Google de migrer son code C++ vers Rust. Mais au-delà de l'amélioration de la sécurité du code C++, Google s'efforcerait également de faciliter l'interopérabilité avec les langages à sécurité mémoire. La migration du code C++ vers les Safe Buffers réduit l'écart entre les langages, ce qui simplifie l'interopérabilité et potentiellement même une éventuelle traduction automatisée.

Dans ce sens, Google avait accordé 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.

Source : Google

Et vous ?

:fleche: Pensez-vous que ce choix de Google de renforcée son code C++ est crédible ou pertinent ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Google fait état d'une baisse des vulnérabilités liées à la sécurité de la mémoire sur Android à mesure que l'utilisation de Rust augmente. Elles seraient passées de 223 en 2019 à 85 en 2022

:fleche: Les détracteurs du Rust s'unissent autour de l'initiative Fil-C : Une implémentation sécurisée des langages C et C++, destinée à redonner au langage C sa grandeur

:fleche: Éjecté du top 3, le langage C recule dans l'indice TIOBE, Java et Rust gagnent en popularité, car les développeurs recherchent des langages sécurisés et faciles à apprendre

Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire, comparé à C et C++

Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire, un taux de rollback 4 fois plus faible et une réduction de 25 % du temps consacré à la révision du code par rapport au C et au C++. Google a partagé comment une stratégie de sécurité mémoire axée sur la prévention des vulnérabilités ne se contente pas de corriger les problèmes, mais aide également à aller plus vite. Selon Google, les données de 2025 continuent de valider cette approche, les vulnérabilités liées à la sécurité mémoire passant pour la première fois sous la barre des 20 % du total des vulnérabilités.

Dans le monde de la programmation, les langages C et C++ ont longtemps dominé le développement de firmware. Cependant, Google a fait une déclaration audacieuse : remplacer ces langages par Rust serait non seulement possible, mais aussi relativement facile. Les ingénieurs d'Android avait notamment affirmé : "Vous verrez à quel point il est facile de renforcer la sécurité avec des remplacements Rust".

Rust est un langage de programmation polyvalent. Il est réputé pour l'importance qu'il accorde aux performances, à la sécurité des types, à la concurrence et à la sécurité de la mémoire. Rust est réputé pour garantir la sécurité de la mémoire (c'est-à-dire que toutes les références pointent vers une mémoire valide) sans collecteur de mémoire classique. À la place, les erreurs de sécurité de la mémoire et les conflits d'accès aux données sont évités grâce au « vérificateur d'emprunt », qui suit la durée de vie des objets référencés au moment de la compilation.

Mais en novembre 2024, Google a affirmé que la transition C++ vers Rust prendra plusieurs années. Pour garantir la sécurité de ces utilisateurs, Google a décidé d'appliquer également les principes de conception sécurisée à sa base de code C++ existante "chaque fois que cela est possible". Google avait alors partagé comment elle a déployé ses principes ainsi que l'impact qu'elle a constaté dans son code C++.

Récemment, un an après cette affirmation, Google partage comment une stratégie de sécurité mémoire axée sur la prévention des vulnérabilités ne se contente pas de corriger les problèmes, mais aide également à aller plus vite. Selon Google, les données de 2025 continuent de valider cette approche, les vulnérabilités liées à la sécurité mémoire passant pour la première fois sous la barre des 20 % du total des vulnérabilités, notamment dans Android.

Android est un système d'exploitation basé sur une version modifiée du noyau Linux et d'autres logiciels open source, conçu principalement pour les appareils mobiles à écran tactile tels que les smartphones et les tablettes. Android a été développé par un consortium de développeurs connu sous le nom d'Open Handset Alliance, mais sa version la plus largement utilisée est principalement développée par Google.

Pièce jointe 671765

Google a adopté Rust pour sa sécurité et constate une réduction de 1 000 fois de la densité des vulnérabilités de sécurité de la mémoire par rapport au code C et C++ d'Android. Mais la plus grande surprise a été l'impact de Rust sur la livraison des logiciels. Avec un taux de rollback quatre fois plus faible et un temps de révision du code réduit de 25 %, la voie la plus sûre est désormais aussi la plus rapide.

Construire de meilleurs logiciels, plus rapidement

Le développement d'un système d'exploitation nécessite le contrôle de bas niveau et la prévisibilité des langages de programmation système tels que C, C++ et Rust. Si Java et Kotlin sont importants pour le développement de la plateforme Android, leur rôle est complémentaire à celui des langages système plutôt qu'interchangeable. Google a introduit Rust dans Android comme alternative directe à C et C++, offrant un niveau de contrôle similaire, mais sans la plupart de leurs risques. Ils ont concentré cette analyse sur le code nouveau et activement développé, car les données montrent que cette approche est efficace.

Lorsqu'on examine le développement dans les langages système (à l'exclusion de Java et Kotlin), deux tendances se dégagent : une forte augmentation de l'utilisation de Rust et un déclin plus lent mais constant du nouveau C++.

Pièce jointe 671766

Le graphique montre que le volume de nouveau code Rust rivalise désormais avec celui de C++, ce qui permet de comparer de manière fiable les mesures du processus de développement logiciel. Pour mesurer cela, ils utilisent le cadre DORA, un programme de recherche mené depuis dix ans qui est devenu la norme industrielle pour évaluer les performances des équipes d'ingénierie logicielle. Les mesures DORA se concentrent sur :

- Débit : la vitesse de livraison des modifications logicielles.
- Stabilité : la qualité de ces modifications.

Les comparaisons entre langages peuvent être difficiles. Ils ont utilisé plusieurs techniques pour garantir la fiabilité des comparaisons.

- Changements de taille similaire : Rust et C++ ont une densité fonctionnelle similaire, bien que Rust soit légèrement plus dense. Cette différence favorise C++, mais la comparaison reste valable. Ils utilisent les définitions de taille de changement de Gerrit.

- Pools de développeurs similaires : l'équipe de Google ne prend en compte que les changements effectués par les développeurs de la plateforme Android. La plupart sont des ingénieurs logiciels chez Google, et il existe un chevauchement considérable entre les pools, beaucoup contribuant aux deux.

-Suivi des tendances au fil du temps : à mesure que l'adoption de Rust augmente, les indicateurs changent-ils de manière régulière, s'accélèrent-ils ou reviennent-ils à la moyenne ?

Débit

La révision du code est une partie du processus de développement qui prend beaucoup de temps et qui présente un temps de latence élevé. La refonte du code est l'une des principales sources de ces retards coûteux. Les données montrent que le code Rust nécessite moins de révisions. Cette tendance est constante depuis 2023. Les modifications Rust d'une taille similaire nécessitent environ 20 % de révisions en moins que leurs équivalents C++.

Pièce jointe 671767

De plus, les modifications Rust prennent actuellement environ 25 % moins de temps en révision de code que celles en C++. Selon Google, le changement significatif en faveur de Rust entre 2023 et 2024 est dû à l'expertise accrue de l'équipe Android en matière de Rust.

Pièce jointe 671768

Si la réduction des retouches et l'accélération de la révision du code offrent des gains de productivité modestes, les améliorations les plus significatives concernent la stabilité et la qualité des modifications.

Stabilité

Rust se distingue par des modifications stables et de haute qualité. DORA utilise le taux de rollback pour évaluer la stabilité des modifications. Le taux de rollback de Rust est très faible et continue de diminuer, même si son adoption dans Android dépasse celle du C++.

Pièce jointe 671769

Pour les modifications moyennes et importantes, le taux de rollback des modifications Rust dans Android est environ quatre fois inférieur à celui du C++. Ce faible taux de rollback n'est pas seulement un gage de stabilité, il améliore aussi activement le débit global du développement. Les retours en arrière perturbent fortement la productivité, créant des frictions organisationnelles et mobilisant des ressources bien au-delà du développeur qui a soumis la modification défectueuse. Les retours en arrière nécessitent des retouches et davantage de révisions de code, et peuvent également entraîner des remaniements, des analyses a posteriori et le blocage d'autres équipes. Les analyses a posteriori qui en résultent introduisent souvent de nouvelles mesures de sécurité qui alourdissent encore davantage la charge de développement.

Dans une enquête auto-déclarée réalisée en 2022, les ingénieurs logiciels de Google ont indiqué que Rust était à la fois plus facile à réviser et plus susceptible d'être correct. Les données concrètes sur les taux de rollback et les délais de révision confirment ces impressions.

Pour résumer

Historiquement, les améliorations en matière de sécurité avaient souvent un coût. Une sécurité accrue impliquait davantage de processus, des performances plus lentes ou des fonctionnalités retardées, ce qui obligeait à faire des compromis entre la sécurité et d'autres objectifs liés au produit. Le passage à Rust est différent : Google améliore la sécurité, l'efficacité du développement et les indicateurs de stabilité des produits.


Élargir le champ d'action

La prise en charge de Rust étant désormais mature pour la création de services et de bibliothèques système Android, Google se concentre sur l'extension de ses avantages en matière de sécurité et de productivité à d'autres domaines.

- Noyau : le noyau Linux 6.12 d'Android est notre premier noyau avec prise en charge de Rust et notre premier pilote Rust en production. D'autres projets passionnants sont en cours, tels que la collaboration continue de Google avec Arm et Collabora sur un pilote GPU en mode noyau basé sur Rust.

- Micrologiciel : la combinaison de privilèges élevés, de contraintes de performances et d'une applicabilité limitée de nombreuses mesures de sécurité rend le micrologiciel à la fois très risqué et difficile à sécuriser. Le passage du micrologiciel à Rust peut apporter une amélioration majeure en matière de sécurité. Google déploit Rust dans le micrologiciel depuis des années et avons même publié des tutoriels, des formations et du code pour la communauté au sens large. Google déclare être particulièrement enthousiastes à l'idée de sa collaboration avec Arm sur Rusted Firmware-A.

- Applications propriétaires : Rust garantit la sécurité de la mémoire dès le départ dans plusieurs applications Google critiques pour la sécurité, telles que :

° Présence à proximité : le protocole permettant de détecter de manière sécurisée et privée les appareils locaux via Bluetooth est implémenté dans Rust et fonctionne actuellement dans Google Play Services.

° MLS : le protocole pour la messagerie RCS sécurisée est implémenté dans Rust et sera inclus dans l'application Google Messages dans une prochaine version.

° Chromium : les analyseurs syntaxiques pour les formats PNG, JSON et les polices web ont été remplacés par des implémentations sécurisées en Rust, ce qui permet aux ingénieurs Chromium de traiter plus facilement les données provenant du web tout en respectant la règle de 2.

Ces exemples soulignent le rôle de Rust dans la réduction des risques de sécurité, mais les langages sécurisés en mémoire ne sont qu'une partie d'une stratégie globale de sécurité en mémoire. Google continue à employer une approche de défense en profondeur, dont la valeur a été clairement démontrée lors d'un récent incident évité de justesse.

https://youtu.be/umhxH_AxG7I

Une première vulnérabilité de sécurité mémoire Rust... ou presque

Google rapporte avoir évité de livrer sa toute première vulnérabilité de sécurité mémoire basée sur Rust : un débordement de tampon linéaire dans CrabbyAVIF. Pour garantir que le correctif soit traité en priorité et suivi tout au long du processus de publication, Google lui a attribué l'identifiant CVE-2025-48530.

Voici les principales conclusions de l'analyse rétrospective de Google :

Allocateur renforcé Scudo pour la victoire

Une conclusion importante est que l'allocateur renforcé Scudo d'Android a rendu cette vulnérabilité inexploitable de manière déterministe grâce aux pages de garde entourant les allocations secondaires. Bien que Scudo soit l'allocateur par défaut d'Android, utilisé sur Google Pixel et de nombreux autres appareils, Google continue à travailler avec ses partenaires pour le rendre obligatoire. En attendant, Ils publieront des CVE d'une gravité suffisante pour les vulnérabilités qui pourraient être évitées par Scudo.

En plus de protéger contre les débordements, l'utilisation de pages de garde par Scudo a permis d'identifier ce problème en transformant un débordement de mémoire silencieux en un crash bruyant. Cependant, ils ont découvert une lacune dans le système de signalement des crashes : il ne montrait pas clairement que le crash était le résultat d'un débordement, ce qui ralentissait le triage et la réponse. Ce problème a été corrigé et Google dispose désormais d'un signal clair lorsque des débordements se produisent dans les pages de garde Scudo.

Révision et formation sur les codes non sécurisés

Le développement de systèmes d'exploitation nécessite des codes non sécurisés, généralement en C, C++ ou Rust non sécurisé (par exemple, pour FFI et l'interaction avec le matériel), il n'est donc pas envisageable de simplement interdire les codes non sécurisés. Lorsque les développeurs doivent utiliser des codes non sécurisés, ils doivent comprendre comment le faire de manière sûre et responsable.

À cette fin, ils ajoutent une nouvelle formation approfondie sur le code non sécurisé à notre formation complète sur Rust. Ce nouveau module, actuellement en cours de développement, vise à enseigner aux développeurs comment raisonner sur le code Rust non sécurisé, la sécurité et les comportements indéfinis, ainsi que les meilleures pratiques telles que les commentaires de sécurité et l'encapsulation du code non sécurisé dans des abstractions sécurisées.

Une meilleure compréhension du code Rust non sécurisé permettra d'obtenir un code de meilleure qualité et plus sécurisé dans l'écosystème des logiciels open source et au sein d'Android.


Comparaison des densités de vulnérabilité

Cette quasi-catastrophe soulève inévitablement la question suivante : « Si Rust peut présenter des vulnérabilités en matière de sécurité mémoire, alors à quoi bon ? »

L'intérêt réside dans le fait que la densité est plus faible. Tellement faible qu'elle représente un changement majeur en matière de sécurité. Sur la base de son accident évité de justesse, Google a fait une estimation prudente. Avec environ 5 millions de lignes de code Rust dans la plateforme Android et une vulnérabilité potentielle de sécurité mémoire détectée (et corrigée avant la sortie), ils estiment la densité de vulnérabilité de Rust à 0,2 vulnérabilités par million de lignes (MLOC).

Les données historiques de Google pour C et C++ montrent une densité plus proche de 1 000 vulnérabilités de sécurité mémoire par MLOC. Le code Rust affiche actuellement une densité inférieure d'un ordre de grandeur : une réduction de plus de 1 000 fois.

La sécurité mémoire fait à juste titre l'objet d'une attention particulière, car cette catégorie de vulnérabilités est particulièrement puissante et (historiquement) très répandue. Une densité de vulnérabilité élevée compromet une conception de sécurité par ailleurs solide, car ces failles peuvent être enchaînées pour contourner les défenses, y compris celles qui ciblent spécifiquement les exploits de sécurité mémoire. Réduire considérablement la densité de vulnérabilité ne se limite pas à réduire le nombre de bogues ; cela augmente considérablement l'efficacité de l'ensemble de notre architecture de sécurité.

La principale préoccupation en matière de sécurité concernant Rust concerne généralement les quelque 4 % de code écrits dans des blocs unsafe{}. Ce sous-ensemble de Rust a alimenté d'importantes spéculations, des idées fausses et même des théories selon lesquelles Rust non sécurisé pourrait être plus bogué que C. Les preuves empiriques montrent que cela est tout à fait faux.

Les données indiquent que même une hypothèse plus conservatrice, selon laquelle une ligne de Rust non sécurisé est aussi susceptible de contenir un bogue qu'une ligne de C ou de C++, surestime considérablement le risque lié à Rust non sécurisé. Plusieurs facteurs contribuent probablement à cette situation :

- unsafe{} ne désactive pas réellement tous les contrôles de sécurité de Rust, ni même la plupart d'entre eux (une idée fausse courante).

- La pratique de l'encapsulation permet un raisonnement local sur les invariants de sécurité.

- L'examen supplémentaire dont font l'objet les blocs unsafe{}.

Google conclut son rapport : "Historiquement, nous devions accepter un compromis : atténuer les risques liés aux défauts de sécurité de la mémoire nécessitait des investissements substantiels dans l'analyse statique, les mesures d'atténuation à l'exécution, le sandboxing et les correctifs réactifs. Cette approche visait à aller vite, puis à réparer les dégâts par la suite. Ces protections multicouches étaient essentielles, mais elles avaient un coût élevé en termes de performances et de productivité des développeurs, tout en offrant une assurance insuffisante.

Si les langages C et C++ continueront d'exister et que les mécanismes de sécurité logiciels et matériels resteront essentiels pour une défense multicouche, la transition vers Rust constitue une approche différente où la voie la plus sûre s'avère également plus efficace. Au lieu d'avancer rapidement puis de réparer les dégâts plus tard, nous pouvons avancer plus vite tout en corrigeant les problèmes. Et qui sait, à mesure que notre code deviendra de plus en plus sûr, nous pourrons peut-être commencer à récupérer encore plus de performances et de productivité que nous avons sacrifiées au profit de la sécurité, tout en améliorant cette dernière."

Ce rapport rappelle que depuis 2024, 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. En février 2024, Google a notamment accordé une subvention d’un million de dollars à la Fondation Rust pour soutenir les efforts d’interopérabilité avec le langage C++. En mars 2024, un responsable de l'entreprise a également déclaré : « Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ ».

Source : Google

Et vous ?

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

Voir aussi :

:fleche: Google annonce la prise en charge du langage Rust pour le développement d'Android, l'intérêt est de résoudre les problèmes de sécurité de la mémoire

:fleche: Rust, réalité et fiction : 5 leçons tirées de l'expérience Rust de Google en 2022, selon l'enquête de Lars Bergstrom et Kathy Brennan

:fleche: La communauté Rust reconnaît que le langage n'est pas sécurisé au travers d'une récente annonce, de lancement d'une initiative de vérification de 7500 fonctions non sûres de la bibliothèque standard Rust