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.

[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