IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Après un conflit au sujet de Rust dans Linux, le mainteneur principal de la distribution Asahi Linux annonce sa démission du projet
Et dénonce le leadership de Linus Torvalds en matière de gestion du kernel

Le , par Patrick Ruiz
316 commentaires

26PARTAGES

11  1 
Linus Torvalds annonce que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau
Dans un contexte où le langage Rust apparaît comme candidat idéal à la mise au rebut du langage C

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux. Linus Torvalds annonce en effet que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau.

Linus Torvalds et Dirk Hohndel ont eu leur habituelle échange lors d’une session de l’édition 2022 de l’Open Source Summit. Linus Torvalds commentait alors sur les évolutions du projet Rust for Linux en soulignant qu’il est susceptible d’être prêt pour Linux 5.20. Les publications de Miguel Ojeda, chef du projet Rust for Linux, avait déjà permis de dresser une liste des progrès de l’initiative : support d’un compilateur Rust bêta, test du support des architectures ARM et RISC-V, nouvelles abstractions Rust, etc.


15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Et vous ?

La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
Vous avez lu gratuitement 2 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

316 commentaires
Commenter Signaler un problème
Pyramidev
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 16/02/2025 à 1:07
Citation Envoyé par d_d_v Voir le message
pourquoi ne pas inventer des extensions aux langages existants pour expliciter l'utilisation obligatoire d'un code securisé
Dans le cas du C++, c'est techniquement possible, mais le comité C++ a refusé.
Le 11 septembre 2024, Sean Baxter avait proposé Safe C++.
Le 15 octobre 2024, pour contrer Sean Baxter, Herb Sutter a proposé d'ajouter des principes qui empêchent C++ d'avoir un sous-ensemble à la fois performant et sécurisé : P3466R0 "(Re)affirm design principles for future C++ evolution".
Le 24 octobre 2024, Sean Baxter a argumenté contre ces nouveaux principes ainsi que contre la proposition des "Safety Profiles" de Bjarne Stroustrup : Why Safety Profiles Failed.
En novembre 2024, le comité C++ a voté pour ces nouveaux principes à 29 voix pour, 22 neutres et 2 contre : Trip report: November 2024 ISO C++ standards meeting (Wrocław, Poland).
Le destin du C++ a été scellé.
5  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/02/2025 à 10:11
Tu penses a quoi précisément? Pour le moment le C++ n'a pas intégré grand chose qui vienne de Rust, c'est plutôt l'inverse.

Il y a plusieurs projets qui visent à reprendre des choses du Rust (SafeCpp, Carbon, FrontCpp, ...), mais rien qui ne semble concerner le C++ officiel pour le moment. Les profiles sont ce qui s'en rapproche le plus mais ça reste très nébuleux et ça n'arrivera pas avant dans quelques années.
2  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 17/02/2025 à 16:20
Je suppose que tout les langages avec un mode unsafe (C#, Rust) proposent ce mode pour des bibliothèques bien supportées à des fins d’optimisation et pour des FFI (foreign function interface) où par principe les protection du language peuvent être incompatibles.

Pour tout programme normal, pas de unsafe, ou si vraiment, encapsulé dans des bibliothèques assez surveillées pour être sûre.

Et oui, l’idée n’est pas d’ouvrir une porte au débutant qui ne sait pas résoudre un problème lié aux règles d’emprunt.
2  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 17/02/2025 à 16:55
Certes, un a = vecteur[i] n'est pas vérifié. Mais en C++ est ajouté la possibilité d'écrire :

Code : Sélectionner tout 
for (int valeur : vecteur)  [...]
Ce qui évite des dépassements dès le codage. Je pense qu'il est préférable de proposer des idiomes qui incite à éviter lors du codage les dépassements que reposer sur la vérification run-time.

Mais il est vrai que STL ne vérifie pas toujours les bornes... cela y est presque (vecteur.at(i) vérifie mais pas vecteur[i] dommage).

Il aurait peut-être été préférable d'avoir un vecteur[i] qui vérifie et vecteur.unsafe_at(i) qui ne vérifie pas. De quoi préférer Boost ou Qt.
2  0 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 18/02/2025 à 13:25
Citation Envoyé par floyer Voir le message
Je pense qu'il est préférable de proposer des idiomes qui incite à éviter lors du codage les dépassements que reposer sur la vérification run-time.
C'est justement la philosophie de Rust. La quasi intégralité de la sécurisation apportée par Rust se fait via des contrôles à la compilation. L'indexation directe est une des rares exceptions vu qu'il n'est pas possible de faire autrement. Ceci dit c'est un cas encore plus rare qu'en C++ vu que la seule syntaxe de boucle for disponible est l'équivalente au for "par range" en C++.

Citation Envoyé par floyer Voir le message
Mais il est vrai que STL ne vérifie pas toujours les bornes... cela y est presque (vecteur.at(i) vérifie mais pas vecteur[i] dommage).
C'est vrai que en C++ les méthodes les plus intuitives sont généralement les plus dangereuses, mais c'est loin d'être le seul problème de la STL. On peut, entre autre, avoir des pointeurs directement sur le contenu d'un vecteur qui vont devenir invalides s'il est redimensionné.

Citation Envoyé par fdecode Voir le message
Oui, c'est un des cas d'usage, où l'utilisation de unsafe n'est pas très risquée, même pour un débutant.
Si la FFI ne transmet que des valeurs recopiées, en effet il n'y a pas de risque.
Par contre si elle transmet des pointeurs vers des données dont la durée de vie est gérée par le code C, au contraire c'est plutôt risqué. Ca va nécessiter une bonne connaissance de ce que fait le programme C avec sa mémoire et savoir réaliser l'abstraction correspondante en Rust safe. Si c'est mal fait ça peut introduire un problème mémoire.
2  0 
d_d_v
Avatar de d_d_v
Membre expérimenté https://www.developpez.com
Le 20/02/2025 à 10:09
Citation Envoyé par fdecode Voir le message
Et qui ferait ça? un débutant en programmation Rust?

En Rust, on évite de programmer en unsafe, quand on est un programmeur confirmé. D'une part, parce qu'on maitrise le paradigme de programmation safe par défaut, d'autre part parce qu'on a appris à minimiser l'usage d'unsafe.
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur. Je ne vois donc pas pourquoi il en serait autrement en rust. Ca fait plus de 20 ans que j'ai travaillé sur plusieurs projets, et à chaque fois, dès que des facilités non recommandées sont offertes dans le langage, il y a toujours des gens qui les utilisent. Ca peut être quelqu'un d'incompétent, ou alors pour corriger un problème en quatrième vitesse en mettant un TODO qui restera ad vitam æternam dans le code, par exemple, ou alors un développeur qui se barre du projet dans une semaine et qui bacle ou sabote le code avant de partir.
Tu peux être sûr et certain, que si une facilité existe, elle sera utilisée, quel que soit le langage.
3  1 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 20/02/2025 à 10:59
Citation Envoyé par d_d_v Voir le message
J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur.
Ce qui fait toute la différence entre Rust et C++ au niveau de la sécurisation, c'est qu'elle est opt-in en C++ et out-out en Rust.

En C++, même si l'on considérait que la STL et les smart pointers sont memory safe, ce qui n'est pas le cas, il faut toujours s'assurer de bien faire les choses, tout le temps. Si par erreur on sort des clous, rien ne nous l'indique le plus souvent. Il ne s'agit pas que d'un problème de débutant, même un développeur expérimenté finit par faire des erreurs, car il n'y a pas de démarcation précise entre ce qui est sûr et ce qui ne l'est pas.

En Rust, par défaut, tout est sécurisé d'un point de vue mémoire. il est peu probable d'écrire unsafe { x.get_unchecked(i) } en toute lettre, sans se rendre compte qu'on est en train de faire quelque chose de potentiellement dangereux, et c'est evident à identifier pour le relecteur. Si on travaille avec des gens auquel on ne fait pas assez confiance et qui n'ont généralement pas besoin de code unsafe, il y a moyen de verrouiller son usage dans le projet, ou forcer à document et justifier chaque utilisation.
2  0 
chrtophe
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 15/02/2025 à 18:47
Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ?
Pas forcément.
Un des paradigme du C est le programmeur sait ce qu'il fait. Si de la mémoire allouée n'a pas été libérée, ou qu'un accès à de la mémoire non allouée est effectué, c'est que le programmeur ne sait pas ce qu'il fait. (ou qu'il y a un oubli, au niveau des développeurs du noyau c'est bien évidemment ça).

Ajouter un langage permettant de mieux cadrer ces aspects est une bonne chose, sous réserve que les apports soient suffisamment intéressants pour s'y investir, et de bien maitriser ce langage , on parle ici du noyau Linux.

De mon point de vue extérieur, C++ pourrait être une alternative, sécurisant un peu plus et posant moins de difficultés d'adaptation que Rust.
Maintenant, avoir un noyau écrit en C, C++, Rust (sans parler des parties en assembleur) sera pour moi une très mauvaise idée.
1  0 
RenarddeFeu
Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 16/02/2025 à 16:47
Ces guéguerres semblent assez puériles vu de l'extérieur.
1  0 
fdecode
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 17/02/2025 à 16:12
Citation Envoyé par d_d_v Voir le message
un mode unsafe que tout le monde aura tendance à utiliser,
Et qui ferait ça? un débutant en programmation Rust?

En Rust, on évite de programmer en unsafe, quand on est un programmeur confirmé. D'une part, parce qu'on maitrise le paradigme de programmation safe par défaut, d'autre part parce qu'on a appris à minimiser l'usage d'unsafe.
Et quand on est un débutant, la programmation unsafe a quelque chose de... suicidaire...

Ce n'est pas par idéologie, c'est un peu par philosophie, mais c'est surtout parce qu'un mode unsafe mal maitrisé est dangereux.
Un exemple bien connu est que le compilateur Rust peut faire des optimisations du code à partir de la sémantique de prêt ('&', '&mut' ...).
La sémantique de prêt est très contraignante pour les débutants. C'est l'une des premières choses qu'un débutant voudra contourner. Mais si on contourne cette sémantique par un unsafe (l'unsafe le permet, mais cette transgression est un UB), il y a le risque que le code compilé soit imprédictible. Dans l'exemple ci-dessous [playground] de contournement de la sémantique de prêt (on utilise une référence mutable pour créer simultanément une référence mutable et une référence non mutable), on obtient un résultat différent en mode Debug ou en mode Release:
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
fn dup_ref_mut<T>(rx: &mut T) -> (& mut T, &T) {
    let px = rx as *mut T;
    unsafe { (px.as_mut().unwrap(),px.as_ref().unwrap()) }
}
 
#[no_mangle] 
fn adds(a: &mut i32, b: &i32) { *a += *b; *a += *b; }
 
fn main() {
    let mut a = 1; 
    let (ra, rb) = dup_ref_mut(&mut a);
    adds(ra, rb);
    println!("a = {}",a);
}
Donc, pour programmer unsafe, il faut au préalable s'assurer qu'on n'est pas dans un cas d'usage UB: c'est une connaissance de programmeur Rust confirmé.

Il me semble qu'il existe des outils pour tracer l'utilisation des unsafe. Donc, l'usage d'unsafe peut être régulé et être contrôlé par celui qui valide le code. Par exemple, des règles d'utilisation de l'unsafe sont édictées pour Redox, afin d'en limiter l'usage:
https://doc.redox-os.org/book/develo...safe-rust-code
1  0 
Commenter Signaler un problème