La prise en charge de Rust pour le développement du noyau Linux commence à prendre forme
Le langage fait un premier pas vers la branche "Linux-Next"
Le 2021-03-22 15:01:01, par Bill Fassinou, Chroniqueur Actualités
Rust fait enfin son entrée dans le développement du noyau Linux, après plusieurs années d'analyses et de dialogue sur les avantages. Discuté à nouveau lors de la conférence Linux Plumbers l'année dernière, le tout premier support de Rust est apparu la semaine passée dans la branche Linux-Next. Même si les auteurs de ce travail jugent qu'il ne s'agit pas d'un ajout significatif, cela jette les bases de la construction des fonctionnalités du noyau Rust pour l'avenir. Ce support est conditionné par la présence d'un compilateur Rust (rustc) sur le système. De ce fait, les architectures actuellement visées sont ARM64 et x86_64.
Les développeurs de Linux discutent depuis un moment de la perspective de permettre l'utilisation du langage développé par Mozilla Research pour écrire de nouveaux pilotes de périphériques pour le noyau. L'année dernière, les développeurs du noyau Linux semblent s'être mis d'accord sur le sujet. Pour mémoire, Rust est plébiscité, car il offre plusieurs avantages, notamment en ce qui concerne la mémoire. Les partisans de Rust ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE sur Android et Ubuntu sont tous liés à des problèmes de sécurité de la mémoire.
Par exemple, d’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de la mémoire tampon. C’est un défi à relever pour le futur en matière de programmation système. En outre, les géants de l'industrie, d'Apple à Amazon en passant par Facebook et Microsoft, se sont lancés ces dernières années dans le recrutement de développeurs Rust. D'ailleurs, selon la firme de Redmond, Rust est la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées.
Selon les partisans de Rust, il peut permettre d'éviter complètement cette classe d'erreurs à l'avenir grâce à des API plus sûres activées par son type de système et son vérificateur d'emprunt. D'autres avantages ont aussi été cités par ces derniers pour justifier la proposition de continuer le développement du noyau avec Rust. Comme premier pas vers ce rêve, le support initial de Rust a été annoncé jeudi sur rust-for-linux dans Linux-Next. « Cela ne signifie pas que nous allons le faire dans la version principale, bien sûr, mais c'est une bonne étape pour rendre les choses aussi faciles que possible », a prévenu Miguel Ojeda, qui est impliqué dans cet effort.
« C'est, malgré tout, une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr », a-t-il ajouté. Notons que la branche Linux-Next est la zone d'attente pour les correctifs destinés à la prochaine fenêtre de fusion du noyau. Ainsi, si vous faites du développement de noyau de pointe, vous voudrez peut-être travailler à partir de cet arbre plutôt que de la branche principale de Linus Torvalds. Selon les explications d'Ojeda, ce support nécessite la présence d'un compilateur Rust (rustc) sur le système. Ainsi, les architectures actuellement visées sont ARM64 et x86_64.
Actuellement, le support du noyau a besoin d'une chaîne d'outils Rust nightly récente pour la construction. En outre, bien qu'aucun pilote de noyau Rust ne soit encore prêt, la fusion initiale vers Linux-Next inclut un exemple de module de noyau écrit en Rust. Par ailleurs, alors que Rust est maintenant dans Linux-Next, il n'est pas encore clair si/quand il sera intégré à la branche principale. En général, le travail dans Linux-Next est peaufiné jusqu'au prochain cycle, mais il peut parfois rester dans Linux-Next plus longtemps s'il s'agit d'un travail en cours. Le code doit encore passer par toutes les formalités de demande d'extraction de la fenêtre de fusion.
Quoi qu'il en soit, l'effort progresse et il pourrait être intéressant de voir si cette infrastructure Rust initiale pour le noyau Linux parvient à être intégrée à la version 5.13 ou à une autre version du noyau cette année. Enfin, comme souligné plus haut, une partie de l'attrait pour Rust vient des caractéristiques de sécurité de la mémoire de Rust, en particulier par rapport au C, dans lequel le noyau Linux est actuellement codé. Une partie du problème, cependant, est que Rust est compilé sur la base de LLVM, par opposition à GCC, et supporte donc moins d'architectures.
C'est un problème auquel la communauté a assisté récemment lorsque la bibliothèque de chiffrement Python a remplacé une partie de l'ancien code C par Rust. En effet, cela a conduit à une situation où certaines architectures ne seront pas prises en charge. Actuellement, la proposition d'inclure Rust dans le noyau Linux limite ce problème en disant que Rust serait utilisé, au moins initialement, pour écrire des pilotes qui « ne seraient de toute façon jamais utilisés sur les architectures les plus obscures ».
Certaines entreprises n'ont toutefois pas attendu que l'équipe de développement du noyau Linux donne son aval pour la prise en charge de Rust, avant de commencer leurs propres efforts. Si vous cherchez un exemple de l'utilisation et de l'utilité de Rust dans le développement du noyau Linux, vous pouvez consulter les travaux d'Amazon Web Services avec Bottlerocket, une distribution Linux pour les conteneurs qui est largement écrite en Rust.
Sources : rust-for-linux, AWS Bottlerocket
Et vous ?
Quel est votre avis sur le sujet ?
Voir aussi
Les développeurs semblent d'accord à l'unanimité pour la prise en charge de Rust pour le développement du noyau Linux lors de la conférence Linux Plumbers
L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds, qui donne des instructions sur l'introduction de son support au système de build
« Il est vraiment difficile de trouver des mainteneurs » : Linus Torvalds parle de la prochaine génération de responsables du développement de Linux à l'occasion de la conférence Open Source Summit
Rust : les développeurs révèlent pourquoi ils ne sont pas plus nombreux à utiliser le langage de programmation, en pointant du doigt un manque d'adoption en entreprise, d'après un sondage
Les développeurs de Linux discutent depuis un moment de la perspective de permettre l'utilisation du langage développé par Mozilla Research pour écrire de nouveaux pilotes de périphériques pour le noyau. L'année dernière, les développeurs du noyau Linux semblent s'être mis d'accord sur le sujet. Pour mémoire, Rust est plébiscité, car il offre plusieurs avantages, notamment en ce qui concerne la mémoire. Les partisans de Rust ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE sur Android et Ubuntu sont tous liés à des problèmes de sécurité de la mémoire.
Par exemple, d’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de la mémoire tampon. C’est un défi à relever pour le futur en matière de programmation système. En outre, les géants de l'industrie, d'Apple à Amazon en passant par Facebook et Microsoft, se sont lancés ces dernières années dans le recrutement de développeurs Rust. D'ailleurs, selon la firme de Redmond, Rust est la meilleure chance de l’industrie informatique pour la mise sur pied d’applications système sécurisées.
Selon les partisans de Rust, il peut permettre d'éviter complètement cette classe d'erreurs à l'avenir grâce à des API plus sûres activées par son type de système et son vérificateur d'emprunt. D'autres avantages ont aussi été cités par ces derniers pour justifier la proposition de continuer le développement du noyau avec Rust. Comme premier pas vers ce rêve, le support initial de Rust a été annoncé jeudi sur rust-for-linux dans Linux-Next. « Cela ne signifie pas que nous allons le faire dans la version principale, bien sûr, mais c'est une bonne étape pour rendre les choses aussi faciles que possible », a prévenu Miguel Ojeda, qui est impliqué dans cet effort.
« C'est, malgré tout, une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr », a-t-il ajouté. Notons que la branche Linux-Next est la zone d'attente pour les correctifs destinés à la prochaine fenêtre de fusion du noyau. Ainsi, si vous faites du développement de noyau de pointe, vous voudrez peut-être travailler à partir de cet arbre plutôt que de la branche principale de Linus Torvalds. Selon les explications d'Ojeda, ce support nécessite la présence d'un compilateur Rust (rustc) sur le système. Ainsi, les architectures actuellement visées sont ARM64 et x86_64.
Actuellement, le support du noyau a besoin d'une chaîne d'outils Rust nightly récente pour la construction. En outre, bien qu'aucun pilote de noyau Rust ne soit encore prêt, la fusion initiale vers Linux-Next inclut un exemple de module de noyau écrit en Rust. Par ailleurs, alors que Rust est maintenant dans Linux-Next, il n'est pas encore clair si/quand il sera intégré à la branche principale. En général, le travail dans Linux-Next est peaufiné jusqu'au prochain cycle, mais il peut parfois rester dans Linux-Next plus longtemps s'il s'agit d'un travail en cours. Le code doit encore passer par toutes les formalités de demande d'extraction de la fenêtre de fusion.
Quoi qu'il en soit, l'effort progresse et il pourrait être intéressant de voir si cette infrastructure Rust initiale pour le noyau Linux parvient à être intégrée à la version 5.13 ou à une autre version du noyau cette année. Enfin, comme souligné plus haut, une partie de l'attrait pour Rust vient des caractéristiques de sécurité de la mémoire de Rust, en particulier par rapport au C, dans lequel le noyau Linux est actuellement codé. Une partie du problème, cependant, est que Rust est compilé sur la base de LLVM, par opposition à GCC, et supporte donc moins d'architectures.
C'est un problème auquel la communauté a assisté récemment lorsque la bibliothèque de chiffrement Python a remplacé une partie de l'ancien code C par Rust. En effet, cela a conduit à une situation où certaines architectures ne seront pas prises en charge. Actuellement, la proposition d'inclure Rust dans le noyau Linux limite ce problème en disant que Rust serait utilisé, au moins initialement, pour écrire des pilotes qui « ne seraient de toute façon jamais utilisés sur les architectures les plus obscures ».
Certaines entreprises n'ont toutefois pas attendu que l'équipe de développement du noyau Linux donne son aval pour la prise en charge de Rust, avant de commencer leurs propres efforts. Si vous cherchez un exemple de l'utilisation et de l'utilité de Rust dans le développement du noyau Linux, vous pouvez consulter les travaux d'Amazon Web Services avec Bottlerocket, une distribution Linux pour les conteneurs qui est largement écrite en Rust.
Sources : rust-for-linux, AWS Bottlerocket
Et vous ?
Voir aussi
-
UtherExpert éminent séniorElle manque de nuance, mais en même temps c'est une réponse à une déclaration qui en manquait tout autant, et Linus Torvalds n'est pas connu pour être un fin diplomate.
Le C++ a son intérêt, mais le but premier de l'intégration de Rust étant de fournir une meilleure sécurité, le C++ est clairement en dessous sur le sujet.le 19/04/2021 à 7:12 -
UtherExpert éminent séniorPersonne n'a dit que Rust était de la poudre magique qui résout tous les problèmes possibles et imaginables. Rust est juste un langage moderne qui permet le genre de chose permises par le C++ avec de bien meilleures garanties de sécurité, ni plus ni moins.le 22/03/2021 à 15:57
-
KsassPeukMembre confirméNon, c'est une réponse de menteur.
La vérification de programmes et la quête du programme sans bug, c'est un sujet dans le monde de la recherche et du transfert technologique depuis des décennies. Chaque année des thèses et des papiers sur le sujet, on en publie des camions. C'est des milliers de personnes à travers le monde qui bossent dessus avec des succès et des échecs, et le domaine est assez fier des progrès qui ont été faits ces dernières années sur le sujet. Bizarrement, aucun de ces succès n'avance du "on a de la garantie de correction pour plusieurs millions de lignes de code C++". Alors quand type débarque du fond d'un forum en balançant du "non mais moi je suis trop fort, d'ailleurs j'ai réglé le problème sur lequel des milliers de personnes se sont cassés les dents pendant 40 ans, par contre je ne vous fournirai aucune preuve". Oui, on est en droit de dire que cette personne ment, purement et simplement.
A titre personnel, ça me gonfle d'autant plus que je bosse précisément sur ce type de sujet depuis 10 ans. Ce genre de discours, par son absence totale de sérieux, est prompt à créer une réaction chez les développeurs du genre "Haha ! C'est n'importe quoi, on ne pourra jamais ne serait-ce qu'approcher la possibilité d'un logiciel sans bug". Le genre de trucs qui peuvent flinguer le travail de sensibilisation qu'on fait auprès d'eux. et qui efface toutes les subtilités réelles du problème (notamment les liens entre la spécification du logiciel, du langage utilisé, et de l'implémentation du système, et ce qu'on inclut ou non dans la confiance d'un logiciel). Ces développeurs auront d'autant moins de facilité à prendre au sérieux les gens qui bossent réellement sur le sujet, autant pour produire de nouvelles solutions que pour amener ces connaissances dans le monde académique et industriel, et pousser ces solutions vers des usages de moins en moins critiques. Aujourd'hui l'ANSSI a durcis les critères nécessaires pour obtenir certaines certifications (par exemple CC EAL6/7), c'est en grande partie grâce à l'effort important qui a été fournis pendant la dernière décennie pour faciliter la mise en place d'outil de vérification formelle et qui fait qu'aujourd'hui il devient possible de sortir des garanties formelles de correction à code-level pour des softs de l'ordre de quelques dizaines de milliers de lignes. Sans parler du fait que sans aller jusqu'à de tels niveau de fiabilité, on a aujourd'hui un large panel d'outils capable de détecter des problèmes ou garantir leur absence et ce en fonction du type de problème ou de système visé.le 01/11/2022 à 13:43 -
le 22/03/2021 à 17:21
-
walfratMembre émériteDisons que si on lit a travers les insultes, moi je comprend ça :
- Ca critique concerne le C++ dans le cas de problème pointu de très bas niveau.
- Cette critique affirme que ce langage ne résout pas des problèmes qui existent déjà en C DANS le cadre de ce besoin mais en rajoutent même.
- L'usage des librairies STL/Boost dans le cadre de ce que fait Linus n'est pas nécessairement approprié quand tu vises un très haut niveau de performance sur des problématiques de bas niveau. Hors il y a beaucoup de développeurs qui se contentent d'utiliser les fonctions des librairies sans vraiment en comprendre les limites, ce qui est gênant quand tu veux faire quelque chose de vraiment pointu. En soi ce n'est pas la faute du C++ mais pour Linus c'était une façon de filtrer plus facilement des développeurs.
C'est ce qu'il affirme, les aficionados savent mieux que moi ce qu'il en est.le 20/04/2021 à 10:02 -
UtherExpert éminent séniorÉcoutez je me base sur le fait que je n'ai entendu aucun expert en sécurité préconiser ça comme première action fondamentale pour sécuriser un code C++. Alors soit vous êtes quelqu'un de très novateur et dans ce cas je m'excuse et j'aimerais beaucoup que vous détaillez comment vous faites, soit il vous manque effectivement des connaissances sur le sujet. Sachez que ça n'a rien d'une insulte : tout le monde à des sujets qu'il connait mieux que d'autres, moi le premier.
Si c'est vraiment le cas, je serais très curieux de lire votre thèse et d'avoir plus de renseignements sur le sujet. A ma connaissance, les systèmes de vérification s'appuient soit sur des preuves formelles, soit de l'analyse statique du code, soit sur de la détection des comportements dangereux à l’exécution, mais qui ne requièrent pas pour autant le fonctionnement en mode débogage.
Si votre système est si efficace grâce aux informations de débogage, je serais très curieux d'en apprendre plus.
Pour le coup, ça m'inquiète plus que ça me rassure. Un logiciel avec zéro failles de sécurité signalées, c'est plus souvent signe d'une mauvaise surveillance des problèmes de sécurité ou d'une rétention des informations de vulnérabilité que d'une grande fiabilité.
Je ne prétend pas être un expert, juste connaitre assez le problème de la sécurité en C++ pour savoir que les assertions et surtout le débogage ne sont clairement pas les éléments considérés comme prioritaires pour sa sécurisation.
Je préjuge pas des gens, par contre je juge vos préconisations en matière de sécurisation du code qui sont ... peu orthodoxes pour rester poli. Si vous pouvez m'expliquer réellement comment vous pouvez éviter les failles de sécurité grâce mode débogage, je serais on ne peu plus ravi de revoir mon jugement, mais comme je n'ai jamais entendu parler de rien de tel pour le moment dans le domaine de la sécurité du code, vous me permettrez de rester on ne peu plus sceptique en attendant.
Il me semble que sauf cas particulier, un travail de thèse est censé être public non ?
En effet c'est une réponse de normand, mais c'est quand même une réponse qui contredit le propos de base. Vous affirmiez que le C++ est sécurisé, mais comme c'est grâce a une méthode qui ne semble pas vraiment connue des gens du métier, et dont vous ne souhaitez pas nous parler. Même à considérer que vous êtes de bonne foi, il n'en reste pas moins qu'elle n'est à l'heure actuelle pas une solution utilisable par le commun des mortels pour sécuriser ses application C++.
Le peu que vous dites sur votre méthode est basé sur de vielles techniques, très superficielles, qui ont montré leurs limites et dont on est revenu depuis longtemps. C'est très loin de ce qui se fait actuellement dans la sécurité. Si le but était de convaincre de la qualité de vos connaissances en matière de sécurité du code C++, c'est vraiment raté.le 01/11/2022 à 14:21 -
UtherExpert éminent sénior
J'ai bien précisé que mes commentaires ne s'appliquaient qu'au peu que vous avez dit, à savoir : les assertions, le débogage, puis la notation hongroise. Car ces méthodes ne visent pas particulièrement la sécurité de l'application mais plutôt à gérer les bugs en général.
D'ailleurs, je pense que le gros du malentendu vient du fait que l'on parle de faille de sécurité alors que vous parlez de bugs généralistes. Les assertions et le débogage sont en effet de très bons outils pour traiter les bugs classiques, mais les failles de sécurité sont des problèmes qui restent généralement cachés, ce qui fait qu'ils nécessitent plutôt des outils pour être détectés (sanitizers, fuzzer, ...) ou les éviter (preuve formelle, analyse statique, restriction du langage,...).
Je ne demande qu'a avoir tort. Si le débogage permettait d'améliorer la sécurité de mes programme je serais le premier heureux. C'est pour ça que je vous ai invité a partager votre thèse, tout aussi poliment que LittleWhite, car si votre approche est valide elle serait particulièrement novatrice. Mais tant que ça reste une méthode que vous seul savez utiliser, le débogage ne peut clairement pas être considéré comme un moyen d'assurer la sécurité d'un programme.
A aucun moment je n'ai voulu être agressif, si c'est l'impression que j'ai donné, je m'en excuse, mais je pense que cette critique peut aussi vous être retournée. Le seul moment ou j'estime être critiquable c'est sur mon message qui disait que vous ne "maitrisiez" pas C++. Il visait uniquement à faire écho à votre "Il est aussi sécurisé si on le connait bien" or votre explication de la sécurité posait problème. Je pense que j'aurais pu le formuler mieux ou même m'éviter cette figure de style.
Sachez que pour moi "ne pas maitriser" n'est pas une attaque. Je ne prétends pas moi même maitriser le C++. Je ne doute pas que, sur la globalité du langage, vous le connaissiez bien mieux que moi. Par contre, je maintiens que les préconisations que vous donniez en matière de sécurité n'étaient clairement pas adaptées.
Je ne vous ai à aucun moment, contrairement à d'autres, accusé de mentir, mais je ne peux pas non plus prendre ce que vous dites sur la détection de faille par débogage pour argent comptant. Le fait que vous refusiez de partager un travail de thèse dans un domaine ou la communication est la norme, n'aide pas à votre crédibilité.
C'est dommage que vous voyez ça comme une agression alors que je vois ça, au contraire, comme une façon d'avoir un débat sain. Si le but était de gagner un débat d'opinion je ferais au contraire une grande tirade majestueuse, pleine de procès d'intention, dont au final la véracité du contenu importerait peu.
En prenant les points précisément, on peut essayer de voir plus clairement sur lesquels on peut être d'accord et pour ceux sur lesquels on n'est pas d'accord, essayer de comprendre pourquoi.le 09/11/2022 à 11:55 -
PogzyMembre à l'essaiFaut reconnaître que C++ est vraiment casse gueule pour des systèmes critiques.le 19/04/2021 à 10:39
-
KannagiExpert éminent séniorJe serais curieux de lire votre thèse , parce que une thèse est normalement accessible au public non ?
Si votre méthode révolutionnaire c'est de faire du debogage et de la notation hongroise...
ça me semble un peu mytho , sans parler que dire que tu n'as jamais constater de bug , ne veut pas dire qu'il y'en a pas.
C'est là que je me dis que c'est "n'importe quoi" , non faire de prefixage de variable ne réduit pas les bugs , d'ailleurs je doute qu'il y'a beaucoup de bug qui sont vraiment lié au type de variable et à leur conversion (il y'en a , mais la plupart des bugs sont pas lié à celà).
Sans parler que ce n'est pas révolutionnaire, vu que ça existe déjà...le 01/11/2022 à 15:04 -
mintho carmoMembre éclairéUn dev pro (C++ ou non) n'aurait pas pensé a ce type d'exemple (qui est de niveau débutant) quand on parle de qualité logicielle et de sécurité. Le choix de ces exemples montrent que tu n'es pas dev pro et encore moins en C++. Et les chiffres que tu donnes (80 Go de cours, 10M de lignes de code) sont complètement risibles.
Donc je comprend qu'on te qualifie de troll.le 01/11/2022 à 16:44