1 pièce(s) jointe(s)
Microsoft travaille à réécrire le code du kernel de Windows responsable de la gestion des fenêtres en Rust
Microsoft travaille à réécrire le code du kernel de Windows responsable de la gestion des fenêtres en langage Rust
Considéré comme candidat idéal à l’abandon de C et C++
Microsoft est en réécriture du code du kernel de Windows responsable de la gestion des fenêtres en langage Rust. La manœuvre n’est pas sans rappeler l’adoption du même langage pour le développement du noyau Linux. En cela, Rust se distingue de plusieurs langages annoncés par le passé comme des remplaçants du C et du C++. Le tableau vient donc raviver les débats sur la possible mise au rebut de langages comme le C ou le C++ au profit du langage Rust et ses garanties de sécurisation de la mémoire annoncées supérieures à celles de C et C++.
Microsoft a effectué un portage de la bibliothèque Win32k GDI (responsable de la gestion des fenêtres) en langage Rust. Un responsable de l’entreprise a passé l’annonce lors de la dernière édition de la conférence BlueHat. L’objectif était de convertir certains des types C++ de ladite bibliothèque en leurs équivalents Rust dans le but de rendre les accès en mémoire moins perméables.
Le tableau n’est pas sans faire penser à l’adoption de Rust comme deuxième langage pour le développement du noyau Linux. Le motif : profiter des avantages que Rust introduit en comparaison au langage C. Plus précisément, comme Alex Gaynor et Geoffrey Thomas l'ont expliqué lors du Linux Security Summit 2019, près des deux tiers des failles de sécurité du noyau Linux proviennent de problèmes de sécurité de la mémoire. Et d'où viennent-ils ? Des faiblesses inhérentes au langage C et C++. Rust, en revanche, esquive ces problèmes en utilisant des interfaces de programmation d'applications (API) bien plus sûres. Rust est tout simplement plus sûr que C.
Récemment, l'Agence nationale de sécurité américaine (NSA) a suggéré que l'une des meilleures choses à faire pour la sécurité d’un programme est d'utiliser Rust plutôt que C. Bien sûr, il existe d'autres langages de ce type, tels que Swift, Go ou C#, mais ils ne se prêtent pas au type de programmation de bas niveau nécessaire à un système d'exploitation.
Dans la pratique, Google, par exemple, utilise désormais largement Rust dans Android. « L'objectif n'est pas de convertir le C/C++ existant en Rust, mais plutôt de transférer le développement de nouveaux codes vers des langages à mémoire sécurisée au fil du temps », indique le géant technologique.
Résultat : « la quantité de nouveau code non sécurisé par la mémoire entrant dans Android a diminué, le nombre de vulnérabilités de sécurité de la mémoire a également diminué. De 2019 à 2022, il est passé de 76 % à 35 % du total des vulnérabilités d'Android. 2022 est la première année où les vulnérabilités de sécurité de la mémoire ne représentent pas une majorité des vulnérabilités d'Android », ajoute-t-il.
Certains intervenants sont néanmoins d’avis que les initiatives de mise au rebut du langage C sont vouées à l’échec
Le créateur du langage C3 dresse néanmoins une longue liste de raisons pour lesquelles les initiatives de mise au rebut du langage C sont vouées à l’échec. Il s’exprime sur divers aspects dont :
La chaîne d'outils du langage C
Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.
Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.
Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.
Les incertitudes d'un nouveau langage
Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.
Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.
Le fait que le langage pourrait tout simplement ne pas être assez bon
Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.
Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.
L’absence de développeurs expérimentés pour un nouveau langage
Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.
De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.
L'ABI C
Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.
Source : Video conference BlueHat
Et vous ?
:fleche: Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
:fleche:Le C et le C++ a-t-il vraiment besoin de remplaçants surtout en matière de programmation système ?
:fleche:Votre entreprise a-t-elle adopté le langage Rust ? Si oui, pour quelles raisons ?
:fleche:Quel commentaire faites-vous de l’argumentaire du créateur du langage C3 ? Quels sont les aspects les plus pertinents ? Quels sont ceux qui le sont moins ?
:fleche: Pourquoi les langages C et C++ pourraient-ils encore avoir de longues années devant eux ?
Voir aussi :
:fleche: L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
:fleche: Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
:fleche: C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
