Existe-t-il un consensus au sein de l'industrie sur l'abandon de C/C++ ? Sécuriser par la conception : Le point de vue de Google sur la sécurité de la mémoire
Le 2024-03-05 16:32:51, par Jade Emy, Communiqués de presse
Dans un livre blanc, Google partage son point de vue sur la sécurité de la mémoire. Voici les raisons pour lesquelles Google publie ce livre blanc.
Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire - défauts de sécurité causés par de subtiles erreurs de codage liées à la manière dont un programme accède à la mémoire - ont été "la norme pour attaquer les logiciels au cours des dernières décennies et c'est toujours la manière dont les attaquants réussissent". Leur analyse montre que deux tiers des exploits "0-day" détectés dans la nature utilisent des vulnérabilités liées à la corruption de la mémoire. Malgré des investissements substantiels pour améliorer les langages peu sûrs pour la mémoire, ces vulnérabilités continuent de figurer en tête des classes de vulnérabilités les plus couramment exploitées.
Dans ce document, Google examine les données, les défis liés à la sécurité de la mémoire, et discute des approches possibles pour atteindre la sécurité de la mémoire et leurs compromis. Elle y souligne également son engagement à mettre en œuvre plusieurs des solutions décrites dans le livre blanc, tout récemment avec une subvention de 1 000 000 dollars à la Rust Foundation, faisant ainsi progresser le développement d'un écosystème robuste de sécurité de la mémoire.
Pourquoi Google publie ce livre blanc maintenant ?
L'année 2022 a marqué le 50e anniversaire des vulnérabilités en matière de sécurité de la mémoire. Depuis lors, les risques liés à la sécurité de la mémoire sont devenus plus évidents. Comme d'autres, les données et recherches internes de Google sur les vulnérabilités montrent que les bogues liés à la sécurité de la mémoire sont très répandus et constituent l'une des principales causes de vulnérabilités dans les bases de code non sécurisées en termes de mémoire. Ces vulnérabilités mettent en danger les utilisateurs finaux, l'industrie et la société dans son ensemble. Google est encouragé par le fait que les gouvernements prennent également ce problème au sérieux, comme l'a montré la publication d'un document sur le sujet la semaine dernière par l'Office of the National Cyber Director (bureau du directeur national du cyberespace) des États-Unis.
Le point de vue de Google
Chez Google, ils ont des dizaines d'années d'expérience dans la résolution, à grande échelle, de grandes catégories de vulnérabilités qui étaient autrefois aussi répandues que les problèmes de sécurité de la mémoire. Leur approche, qu'ils appellent "Safe Coding", traite les constructions de codage sujettes à la vulnérabilité comme des dangers (c'est-à-dire indépendamment et en plus de la vulnérabilité qu'elles peuvent causer), et est centrée sur l'assurance que les développeurs ne rencontrent pas de tels dangers lors de leurs pratiques de codage régulières.
Sur la base de cette expérience, ils pensent qu'une sécurité élevée de la mémoire ne peut être obtenue que par une approche de conception sécurisée centrée sur l'adoption complète de langages offrant des garanties rigoureuses en matière de sécurité de la mémoire. Par conséquent, ils envisagent une transition progressive vers des langages à sécurité mémoire tels que Java, Go et Rust.
Au cours des dernières décennies, outre les vastes bases de code à mémoire sécurisée de Java et Go, Google a développé et accumulé des centaines de millions de lignes de code C++ qui sont utilisées activement et font l'objet d'un développement actif et continu. Cette très grande base de code existante pose des problèmes importants pour la transition vers la sécurité de la mémoire.
Mais Google considère qu'il est important de compléter la transition vers des langages à mémoire sûre pour le nouveau code et les composants particulièrement à risque par des améliorations de la sécurité du code C++ existant, dans la mesure du possible. Ils pensent également que des améliorations substantielles peuvent être obtenues par une transition progressive vers un sous-ensemble de langage C++ partiellement sûr en mémoire, complété par des fonctions de sécurité matérielle lorsqu'elles sont disponibles.
Les investissements de Google dans les langages à mémoire sécurisée
Google reconnait que les langages à mémoire sécurisée ne résoudront pas tous les bogues de sécurité, mais tout comme ses efforts pour éliminer les attaques XSS par le biais d'outils l'ont montré, l'élimination de grandes catégories d'exploits profite directement aux consommateurs de logiciels et leur permet de se concentrer sur la résolution d'autres catégories de vulnérabilités de sécurité.
Source : Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google
Et vous ?
Pensez-vous que cet avis de Google est crédible ou pertinent ?
Quel est votre avis sur le sujet ?
Voir aussi :
La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust, jugés supérieurs pour sécuriser les espaces mémoire des logiciels
Les futurs logiciels devraient être sûrs pour la mémoire, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyber-attaques
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
Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire - défauts de sécurité causés par de subtiles erreurs de codage liées à la manière dont un programme accède à la mémoire - ont été "la norme pour attaquer les logiciels au cours des dernières décennies et c'est toujours la manière dont les attaquants réussissent". Leur analyse montre que deux tiers des exploits "0-day" détectés dans la nature utilisent des vulnérabilités liées à la corruption de la mémoire. Malgré des investissements substantiels pour améliorer les langages peu sûrs pour la mémoire, ces vulnérabilités continuent de figurer en tête des classes de vulnérabilités les plus couramment exploitées.
Dans ce document, Google examine les données, les défis liés à la sécurité de la mémoire, et discute des approches possibles pour atteindre la sécurité de la mémoire et leurs compromis. Elle y souligne également son engagement à mettre en œuvre plusieurs des solutions décrites dans le livre blanc, tout récemment avec une subvention de 1 000 000 dollars à la Rust Foundation, faisant ainsi progresser le développement d'un écosystème robuste de sécurité de la mémoire.
Pourquoi Google publie ce livre blanc maintenant ?
L'année 2022 a marqué le 50e anniversaire des vulnérabilités en matière de sécurité de la mémoire. Depuis lors, les risques liés à la sécurité de la mémoire sont devenus plus évidents. Comme d'autres, les données et recherches internes de Google sur les vulnérabilités montrent que les bogues liés à la sécurité de la mémoire sont très répandus et constituent l'une des principales causes de vulnérabilités dans les bases de code non sécurisées en termes de mémoire. Ces vulnérabilités mettent en danger les utilisateurs finaux, l'industrie et la société dans son ensemble. Google est encouragé par le fait que les gouvernements prennent également ce problème au sérieux, comme l'a montré la publication d'un document sur le sujet la semaine dernière par l'Office of the National Cyber Director (bureau du directeur national du cyberespace) des États-Unis.
Google :
En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
Le point de vue de Google
Chez Google, ils ont des dizaines d'années d'expérience dans la résolution, à grande échelle, de grandes catégories de vulnérabilités qui étaient autrefois aussi répandues que les problèmes de sécurité de la mémoire. Leur approche, qu'ils appellent "Safe Coding", traite les constructions de codage sujettes à la vulnérabilité comme des dangers (c'est-à-dire indépendamment et en plus de la vulnérabilité qu'elles peuvent causer), et est centrée sur l'assurance que les développeurs ne rencontrent pas de tels dangers lors de leurs pratiques de codage régulières.
Sur la base de cette expérience, ils pensent qu'une sécurité élevée de la mémoire ne peut être obtenue que par une approche de conception sécurisée centrée sur l'adoption complète de langages offrant des garanties rigoureuses en matière de sécurité de la mémoire. Par conséquent, ils envisagent une transition progressive vers des langages à sécurité mémoire tels que Java, Go et Rust.
Au cours des dernières décennies, outre les vastes bases de code à mémoire sécurisée de Java et Go, Google a développé et accumulé des centaines de millions de lignes de code C++ qui sont utilisées activement et font l'objet d'un développement actif et continu. Cette très grande base de code existante pose des problèmes importants pour la transition vers la sécurité de la mémoire.
Google :
Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
Les investissements de Google dans les langages à mémoire sécurisée
Google :
Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.
Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.
- Android a écrit plusieurs composants en Rust au cours des dernières années, ce qui a permis d'améliorer considérablement la sécurité. Dans le module UWB (Ultra-wideband) d'Android, cela a permis d'améliorer la sécurité du module tout en réduisant l'utilisation de la mémoire et les appels interprocéduraux.
- Chrome a commencé à livrer certaines fonctionnalités en Rust ; dans un cas, Chrome a pu sortir son générateur de code QR d'une sandbox en adoptant une nouvelle bibliothèque à mémoire sécurisée écrite en Rust, ce qui a permis d'améliorer à la fois la sécurité et les performances.
- Google a récemment annoncé l'octroi d'une subvention d'un million de dollars à la fondation Rust afin d'améliorer l'interopérabilité avec le code C++. Cela facilitera l'adoption progressive de Rust dans les bases de code existantes où la mémoire n'est pas sûre, ce qui sera essentiel pour permettre à un plus grand nombre de nouveaux développements de se produire dans un langage à mémoire sûre. Dans le même ordre d'idées, nous nous efforçons également de résoudre les attaques inter-langues qui peuvent se produire lorsque l'on mélange Rust et C++ dans le même binaire.
- Google investit dans la construction d'un écosystème open-source à mémoire sécurisée par l'intermédiaire du GISR Prossimo et du projet Alpha-Omega de l'OpenSSF. En 2021, nous avons financé les efforts visant à intégrer Rust au noyau Linux, ce qui nous permet désormais d'écrire des pilotes à mémoire sécurisée. Ce financement est également destiné à fournir des alternatives ou des mises à jour de bibliothèques open-source clés dans un langage à mémoire sécurisée, comme la fourniture d'une implémentation TLS à mémoire sécurisée.
Source : Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google
Et vous ?
Voir aussi :
-
FagusMembre expertTout ce qu'on sait, c'est si le teste passe ou pas, mais ça ne prouve pas l'absence de bug.
Si on écrit 1/x et que x peut être manipulé par l'utilisateur, c'est évident qu'il faut bloquer l'entrée x=0 ou prévoir le cas division par 0.
Mais si au lieu de x, on a une équation mathématique compliquée qui comporte une division, ça peut être oublié, et le programme passera tous les tests, sauf celui sur la valeur exacte qui provoque une division par zéro. C'est du vécu quand j'ai réimplémenté un algo déjà implémenté commercialement. À un moment j'ai entré la valeur spéciale dans les logiciels concurrents : bam comportement aberrant sur division par zéro oubliée.
Ou bien si on a un algo compliqué conditionnel avec plusieurs dizaines de branchements qui ne s'emboîtent pas, c'est facile dans un moment de fatigue ou sur une faute de frappe d'écrire dans un coin si x > n ... {code} ; si x<n {code} alors qu'on voulait écrire si x<=n. Le code produit une erreur de logique seulement si x=n.
Sur les atmel, esp, je ne connais très modestement que le compilateur d'arduino. On écrit souvent dans une sorte de c, mais c'est un compilateur c++. C'est pas très élégant, mais ça m'arrive d'écrire en mélange de c/c++ parfois, tant que ça consomme pas trop de ressources.le 06/03/2024 à 14:18 -
UtherExpert éminent séniorHeu non, chaque thread de chaque processus a sa propre pile qui est heureusement différente de celle du noyau du système d’exploitation. Sinon n'importe quel programme pourrait altérer le fonctionnement des autres, voire même de l'OS.
C'est transparent du point de vue du programme en cours d'exécution, mais le registre SP est sauvegardé/restaurée par l'OS lors des changements de contexte pour pointer sur la pile du thread en cours d’exécution.
C'est vrai que certains microcontrôleurs exotiques n'ont que des compilateur en C, mais pour le coup les exemples sont mauvais car une simple recherche rapide montre que Rust les supporte, et je serais surpris que ça ne soit pas le cas de C++ aussi, vu que Rust et Clang (qui supporte le C++) s'appuient tous les deux sur LLVM pour le backend. De nos jours la plupart des compilateurs reposent sur des briques communes (LLVM, GCC) ce fait qu'il est plus simple de supporter plusieurs langages, quand on a déjà un backend qui marche pour une architecture.
Non je vous assure qu'il a raison et 30 secondes de recherche sur internet vous auraient suffi pour le vérifier. Prenez au minimum la peine de faire ça avant d'accuser les gens merci.le 06/03/2024 à 7:26 -
KsassPeukMembre confirméAutant sur la difficulté à migrer quand on a toute son infrastructure écrite en C, j'y souscris, autant ceci :
me semble trompeur. Rust ne prétend pas régler tous les soucis. Le principe de Rust c'est conserver un maximum de contrôle et régler par typage une classe particulière de problèmes qui sont ceux liés à la mémoire (et ça ne règle pas tout un tas d'autres undefined behaviors par ailleurs genre tout ce qui est integer overflows). Malgré tout, entre 2013 et 2017, les CVEs liées à la mémoire, ça représentait autour de 20% des CVEs annuelles (d'après l'analyse dans la vidéo plus bas, 53% des CVEs sont dues à : Buffer Overflow (~6000 sur 5 ans) + SQL Injection (~6000 sur 5 ans) + Info leak (~3000 sur 5 ans)). 20% juste pour une classe d'erreur dont on comprend aujourd'hui comment s'en prémunir au niveau typage, c'est pas anodin. Je ne sais pas comment ça a évolué entre 2017 et 2022 ceci dit (enfin, pour les trucs non-critiques), mais je ne crois pas qu'il y ait eu un énorme changement dans les pratiques de ce côté.
La dite vidéo (navré, j'ai trouvé aucun moyen dans l'éditeur de ne pas mettre l'embedding, peu importe ce que je fais l'éditeur insiste pour mettre automatiquement l'embedding...) :le 06/03/2024 à 16:26 -
UtherExpert éminent séniorIl faut arrêter de laisser entendre que l'on va forcer les gens a réécrire en urgence en Rust toutes les applications existantes. Personne de sérieux ne l'a jamais demandé. Ça serait juste idiot et impossible en pratique. Bien sûr que le C restera encore longtemps le langage avec la plus grosse base de code en production.
On demande juste de préparer les gens pour permettre de faire une transition vers des langage sûr là ou ça a du sens. Rust sera utilisé surtout dans des nouveaux projets où des refontes déjà envisagées.
Ça tombe bien, Rust ne prétend pas résoudre tout les soucis du monde : il prétend surtout de résoudre les soucis de sureté mémoire dans les applications qui nécessitent de la performance et du contrôle bas niveau. Dans ce type d'application, la sureté mémoire est quand même la cause de la grande majorité des vulnérabilité graves.
Si on veut sécuriser le web, le problème à résoudre se situe plus au niveau des frameworks web que du langage.
C'est des problèmes assez orthogonaux. Le dev web pose des problématiques de sécurité spécifiques (Injection, XSS,...), plutôt rares voire inexistants pour un développement bas niveau. Et inversement, les problématiques de sureté mémoire ne se posent pas trop dans le développement Web, pour la simple raison que les langages qu'on utilise traditionnellement pour ça sont déjà memory safe.
Par contre, si on faisait du web en C, on cumulerait les deux sources de problème.
En effet, Cyclone est un langage que les créateurs Rust citent souvent dans leurs influences, ainsi que le ML. Le concept de lifetime explicite vient clairement de Cyclone. S'il n'a pas pris, c'est sans doute qu'il s'agissait avant tout d'un projet de recherche qui n'avait pas vraiment pour vocation d'être utilisé en l'état, développé à une époque où la sécurité des logiciels bas niveau n'était pas une préoccupation première.
Rust ne prétend pas avoir inventé quoique ce soit de foncièrement nouveau. Le titre de la première présentation officielle du projet Rust par son créateur original était même : "Technology from the past come to save the future from itself".
Même les concepts de ownership et lifetime, qui font la particularité de Rust, ne sont pas nouveaux en soi : c'était de règles de bonne pratique en C. Le problème étant qu'il peut y avoir des erreurs dans leur mise en pratique. Ce qu'apporte Rust à ce niveau, c'est que le compilateur garanti leur bon usage de manière à ce que l'on ne puisse pas causer d'accès mémoire invalide.
C'est en effet plus compliqué, surtout au début, mais au final on s'y habitue. Par contre, on à la garantie que ça sera toujours bien fait, alors que l'on peut très bien savoir comment bien gérer un malloc et quand même se planter.
Si on veut un analyseur statique qui traite tous les cas, on finit par réinventer Rust en moins bien.le 07/03/2024 à 7:41 -
PyramidevExpert éminentConcernant l'exemple avec "é", ce n'est pas vraiment ça. Un caractère dans le sens "groupe de graphèmes" peut se décomposer en un ou plusieurs points de codage Unicode. Il peut aussi y avoir plusieurs manières de représenter un caractère. Par exemple, "é" correspond soit à un seul point de codage, soit à deux dont le premier qui correspond à "e" et le deuxième, "◌́", qui ajoute un accent aigu.
En UTF-8, un point de codage fait 1, 2, 3 ou 4 octets.
En UTF-16, un point de codage fait 2 ou 4 octets. Quand il fait 4 octets, on l'appelle une "surrogate pair".
En UTF-32, un point de codage fait 4 octets.
L'article suivant résume bien certaines subtilités d'Unicode : The Absolute Minimum Every Software Developer Must Know About Unicode in 2023 (Still No Excuses!)le 07/03/2024 à 10:59 -
commandantFredMembre avertiObjective C était prometteur. Son modèle objet était élégant à l'oeil.
Pour la sécurité mémoire, le problème est centré sur les langages compilés ciblant un CPU précis. Les langages p-codés à GC comme java ou .net ne sont pas vraiment concernés. Les langages interprétés comme javascript ou python sont à priori immunisés à 100% pour autant que l'interpréteur soit bien débuggé.
La garbage collection, c'est à cause d'elle que Google parle de "sécurité temporelle", du moins, je l'interprète comme ça. La prose des géants reste un peu évasive...
Ce qui m'étonne le plus, c'est de savoir que Rust est déjà implémenté dans Chrome et Android. Ils ont visiblement déjà beaucoup investi dans la migration.
Je veux bien parier ma plus belle chemise qu'Amazon ne créera jamais de langage compilé. Pas son style, trop de problèmes, pas assez de revenu, responsabilité très lourde. Les langages, c'est surtout l'affaire des éditeurs d'OS qui ont toujours un avantage pour placer leur système si les API de leur OS sont bien implémentées. En outre, ils ont besoin d'outils pour leurs développements internes.
Amazon pourrait bien éditer un langage de script pour naviguer dans les offres AWS ou retail. Mais rien de plus qu'un genre de shell script.
C pourrait bien revenir dans les annonces d'emploi par le truchement de contrôleurs bien pourvus en mémoire qui viendraient grignoter le marché des machines d'enregistrement logistiques (type TPV ou caisse enregistreuse dans les boutiques).
Pour la demande de développeurs, la double compétence C++ et Rust pourrait être très recherchée dans un avenir très proche.le 05/03/2024 à 23:20 -
floyerMembre avertiOui, il est théoriquement possible de faire du code C/C++ sans bug… mais avec des milliers / millions de lignes de codes, sauf à utiliser des vérifications formelles (méthode B ou autre), statistiquement il y a de fort risques de bug qui pourraient être évités par des langages plus sûrs.
Alors c’est sûr, on peut toujours dire «*c’est la faute du programmeur, pas du langage », mais il paraît que l’erreur est humaine et le programmeur humain.
Il est utile de lire https://usenix15.nqsb.io/ qui parle de problèmes d’implémentation de SSL avec beaucoup de problèmes de gestion de mémoire dans les versions usuelles écrites en C.le 05/03/2024 à 23:52 -
KsassPeukMembre confirméLe papier d'origine c'était pour un langage impératif simple, depuis ça a été dérivé un peu pour tout et au passage, ça a été fortement amélioré par plein d'autres gens notamment Rustan Leino.
La POO au final, c'est pas si compliqué d'un point de vue logique pure: soit tu respectes le LSP et tu as déjà ta règle pour le calcul de plus faible précondition, soit c'est pas le cas, et ça devient une disjonction des différents cas d'appels.
Ce qui est plus dur, c'est la modélisation efficace de la mémoire, mais en fait c'est déjà dur en C, et les techniques dont on a besoin pour bien traiter le C sont aussi celles qui sont nécessaires pour des langages qui introduisent plus d'abstractions comme C++.
Pour la concurrence, il y a aussi plein de papiers sur le sujet. Dans les papiers fondateurs, on va avoir Owicki-Gries (https://en.wikipedia.org/wiki/Interference_freedom). Ensuite, il y a eu plein de nouvelles dérivations de ça, comme le rely-guarantee, la logique de séparation concurrente, et puis les versions relaxées pour pouvoir raisonner sur des modèles mémoire faibles comme ceux des processeurs "modernes" (je mets ça entre guillemets, parce que c'est quand même plus si jeune).
Par contre, il y a moins d'outils pour faire ça et surtout moins d'outils automatiques, il faut se palucher les preuves dans des assistants de preuve.
L'ANSSI (pour ne citer qu'elle) pousse de plus en plus à l'utilisation d'outils formels pour des questions de sûreté/sécurité. Par exemple, pour du CC EAL6, ils ont tendance à être beaucoup plus regardant dans les nouveaux schémas de certification : avant la demande de traçabilité modèle/code n'était pas aussi pressante de leur part. C'est plutôt vers ça actuellement que la demande en outillage pour la sûreté se dirige de leur côté et ça peut fortement améliorer la sûreté d'un code C (C++, c'est une autre histoire, le langage est super gros, et construire un outil formel pour lui, c'est une montagne de boulot). En gros, si tu veux ton tampon CC EAL7 de l'ANSSI, t'as pas le choix c'est méthodes formelles ou rien (donc actuellement en France, Atelier B, Coq ou Frama-C/WP). Mais clairement, quand on leur demande si un outil de vérification formelle pour Rust les intéresse, on a toute leur attention. Donc pour compléter, pour eux : si tu veux faire du C, soit, mais prouve moi l'absence d'undefined behaviors (et si tu veux un haut niveau de certification, prouve le reste aussi) et via des méthodes formelles, et par ailleurs "dites les chercheurs, vous pourriez pas nous faire un outil de vérification formelle industrial level pour Rust ?". Et même d'un point de vue performance des outils de preuve, c'est pas déconnant du tout. Un problème critique pour la capacité de preuve en C, c'est la séparation de la mémoire parce que les aliasing rendent l'espace de recherche dans les formules logiques exponentiel quand tu as des écritures et donc ça peut rendre certaines preuves atrocement dures, dans un langage comme Rust, la séparation des zones mémoires écrites, elle est vraie par typage dans la plus grande partie de ton programme, et ça c'est très bon pour faciliter les preuves.
(Ah et puis pour l'instant méthodes formelles sur des millions de ligne de C, c'est plutôt de l'ordre de la science fiction pour la raison invoquée précédemment : les aliasing)le 06/03/2024 à 8:43 -
OuftiBoyMembre actifAlors j'ai un peu cherché:
https://en.wikipedia.org/wiki/Cyclone_(programming_language)
Il s'agit d'une version plus Safe du C: Il y est mentionné que Rust y a puisé pas mal d'idées.
Pourquoi ça n' pas prit à l'époque, je ne sais pas.
Mais qd on fait de l'embarqué, c'est assez utile. (le temps pour l'allocation est déterministe).
De même, dans un passé lointain, c'était une bonne méthode de réutilisation de la RAM. Sans allocation dynamique et tous les soucis que ça peut engendrer si on ne fait pas attention. L'idée est très ancienne (apparemment, D. knuth on parlait déjà dans The Art Of Computer Programming).
Perso, j'avais entendu parlé de ça via µC/OS2https://www.silabs.com/developers/micrium)
Il y a plein de système de ce genre avec leurs avantages et désavantages. Je pense même qu'un dev de Qt a lui aussi redécouvert la chose:
https://www.qt.io/blog/a-fast-and-thread-safe-pool-allocator-for-qt-part-1
C'est dans les vieilles marmites qu'on fait les meilleurs soupes disait ma grand-mère.
C'est juste pour alimenter la discussion :-)
BàV. Peace and Love.le 06/03/2024 à 23:31 -
floyerMembre avertiCertes, certes, mais si une conception logicielle diminue la surface d’attaque par 2… même s’il reste un risque vis-à-vis des agences gouvernementales, c’est toujours cela de pris. L’article que je cite catégorise les défauts de plusieurs implémentations de TLS et on trouve des défauts au niveau de la mémoire qu’un langage d’assez haut niveau sait gérer et donc éviter.Ceux qui se plaignent des exploits de hackers ne sont pas souvent développeurs. D'ailleurs, personne ici n'a parlé d'attaque dont il aurait été victime. (ça m'est pourtant arrivé en 2001)Ce serait bien de tenir compte de ce point. La sécurité d'un code ne se lit pas dans les grimoires ni dans les normes. Elle s'écoute chez les victimes de cyber-attaques.A ce moment, il faudra surtout répondre aux problèmes posés par les victimes.EDIT : Pour illustration, je citerais l'énorme scandale de la conversation entre deux officiers allemands concernant les tactiques d'attaque au moyen de missiles air-sol. Je citerai le général Richou (France) qui dit que cette conversation n'est pas un évènement. Ce qui l'est en revanche, c'est qu'elle soit parvenue aux hackers qui l'ont publiée sur les réseaux sociaux. Je ne pense pas que le sysadmin qui a autorisé cette conversation sur un logiciel mal sécurisé dorme sur ses deux oreilles maintenant. Clairement, l'armée allemande va faire une chasse au logiciel mal sécurisé et quelques têtes vont forcément tomber.
D’une certaine manière le passage à Rust ou un langage plus sûr est comparable au passage de la NASA au système métrique suite à l’échec de Mars Climate Orbiter. On peut ergoter… le problème aurait pu être éviter si le concepteur avait bien fait ses calculs (ce qui aurait pu être possible). Mais d’un autre côté, des outils plus sûr limitent les risques.le 07/03/2024 à 0:56