Discussion :

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

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

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 :

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

[Uther]

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.

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.

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

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.

[Uther]

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

[fdecode]

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 :

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

[Uther]

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.

[fdecode]

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 :

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

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

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.

[23JFK]

...

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

[fdecode]

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

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:

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.

[23JFK]

...

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

[Pyramidev]

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

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.

[fdecode]

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

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

[Uther]

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.

[fdecode]

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/

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

[fdecode]

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!

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

[fdecode]

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.

[Jade Emy]

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 :

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

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 :

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.

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 :

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.

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 :

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 ?

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

Voir aussi :

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

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

É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