Discussion :

[Uther]

N'y aurait-il pas Ada en 1983 qui était fort novateur à l'époque (généricité bien avant les templates C++, exceptions, multitasking, rendez-vous, etc...), avec des FFI normalisées avec C, Fortran et COBOL, tout en permettant des accès bas niveaux pour ne pas dire très bas niveaux.

En effet Ada avait plein de particularités très intéressantes pour l'époque, mais il est sorti à une époque ou la sécurité n'était pas une priorité, avec un coût élevé et des outils de développement pas terribles. Il apportait certaines fonctionnalités très intéressantes, comme les sous-types qui manquent encore à Rust aujourd'hui. A ce propos il y a justement une conférence du FOSDEM qui vient d'être publié sur le sujet. Elle présente rapidement comment Rust est en train d'implémenter des fonctionnalités d'Ada qui lui manquent encore.

Cependant Ada n'avait pas vraiment d'équivalent au système de Borrow Checker qui a fait la particularité de Rust en permettant de garantir l'absence de faille mémoire malgré l’utilisation de références.

[floyer]

Interessant la vidéo.

Je me pose la question. Est-ce que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let a : u32 is 1..5 = 5; a=a+1

provoquera une exception ?

On note ici le code Ada d’Ariane 5 : https://www.sarahandrobin.com/ingo/swr/ariane5.html

On voit que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 horizontal_veloc_bias := integer(horizontal_veloc_sensor);

Converti un flottant en un entier et est susceptible de provoquer une exception plutôt que de laisser un résultat incohérent… mais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 pragma suppress(numeric_error, horizontal_veloc_bias);

Désactive la vérification… et 600 millions d’euros sont partis en fumée.

[RenarddeFeu]

L'argument en faveur du Rust est qu'il est plus sécurisé que le C avec des performances comparables. Or le fait de mixer les deux langages au sein du noyau Linux n'offre ni l'un ni l'autre.

Les afficionados du Rust devraient concentrer leurs efforts sur RedoxOS.

[Uther]

Ça serait bien d'expliciter un minimum parce que il n'y a pas de raison que ça n'apporte plus de sécurité mémoire sur les partie écrites en Rust, pas plus qu'il n'y a de raison que ça ait un impact sur les performances.

[fdecode]

Allouer la mémoire ? Pas vraiment. Dans la programmation système, il peut y avoir des registres de cartes entrée/sortie mappés en mémoire (un peu moins vrai sur Intel avec les instructions IN et OUT qui tapent ailleurs, sur des ports).

Ok, je comprends.

Ceci-dit, c'est plus efficace d'avoir une variable mappée à une adresse que de passer par un pointeur. Compare : [...]

La différence ne me parait pas flagrante, actuellement.
Il est vraisemblable que l'optimisation du compilateur ne laisse pas un adressage indirect comme ça. Ce code rust [playground]:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
const RA: *mut u64 = 8000 as *mut u64;
 
#[no_mangle]
fn assign() {
    unsafe { *RA = 123; }
}

donne en mode release:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
assign:
	movq	$123, 8000
	retq

mais on retrouvera l'adressage indirect en mode debug (non optimisé):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
assign:
	movl	$8000, %eax
	movq	$123, (%rax)
	retq

Je ne le teste pas, mais ce sera pareil en C.

[Christophe]

unsafe lève les sécurités qu'apporte Rust sur la gestion mémoire si j'ai bien compris. Si c'est pour faire ça, autant rester en C.

[NotABread]

unsafe lève les sécurités qu'apporte Rust sur la gestion mémoire si j'ai bien compris. Si c'est pour faire ça, autant rester en C.

Non, je vais citer la doc officielle

To switch to unsafe Rust, use the unsafe keyword and then start a new block that holds the unsafe code. You can take five actions in unsafe Rust that you can’t in safe Rust, which we call unsafe superpowers. Those superpowers include the ability to:

• Dereference a raw pointer
• Call an unsafe function or method
• Access or modify a mutable static variable
• Implement an unsafe trait
• Access fields of a union

It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.

Il y a beaucoup de unsafe dans le code Rust lui même, pour autant, les garanties de sécurité mémoire sont là.

L'argument en faveur du Rust est qu'il est plus sécurisé que le C avec des performances comparables. Or le fait de mixer les deux langages au sein du noyau Linux n'offre ni l'un ni l'autre.

Les afficionados du Rust devraient concentrer leurs efforts sur RedoxOS.

Le fait de mixer les deux complexifie la maintenabilité du code, surtout à la jonction entre le C et le Rust (il faut comprendre l'API C et connaitre Rust, être quelqu'un de confiance, avoir ces personnes qualifiées disponible pour maintenir les abstractions sur plusieurs années, etc ...).
Le code Rust aura toutes ses garanties de sécurité et performance, le code C gardera toutes ces performances sans être impacté par la présence du code Rust. Il n'y a que les abstraction Rust qui auront un petit surcoût.
D'ailleurs, RedoxOS mixte aussi du Rust et du C, notamment en implémentant la libc pour bénéficier des programmes/bibliothèques déjà existante, ou encore avoir une ABI stable sur laquelle se reposer.


PS: petit éclaircissement
Le promoteur de Rust (Hector Martin) est aller se plaindre sur les réseaux sociaux pour faire pression et faire passer son commit, d'où la réaction virulente de Linus. Si les abstractions Rust du DMA sont de l'API DMA, Hellwig se retrouvera mainteneur de ce code s'il n'y a personne d'autre pour le faire. Le bonhomme ne veut clairement pas toucher au Rust, et le projet Rust For Linux à deux ans, donc pas vraiment beaucoup de raison pour lui de penser qu'il y aura une personne sur le long terme qui comprenne l'API C et le Rust pour faire le boulot. Il veut pas se retrouver à faire un boulot qui n'est pas le sein donc il s'est opposé farouchement (et est allé trop loin à mon goût dans ses propos)

[Christophe]

Il y a beaucoup de unsafe dans le code Rust lui même, pour autant, les garanties de sécurité mémoire sont là.

En déréférançant un raw pointer ?

Comme ça je doute mais je ne suis pas dev.

Je pense que Rust permet de désactiver des trucs pouvant poser des probs. donc unsafe comme l'indique le nom, permettant donc de faire les mêmes bugs qu'en C.

[air-dex]

Cet aspect ecosystème est assez important et justifie les gestionnaire de package de bibliothèques (Cargo pour Rust, Vcpkg pour C++/Windows, Opam pour OCaml, Alire pour Ada, PIP pour Python, etc.)

+1 pour l'écosystème. L'outillage est un élément clé : linter, générateur de documentation, outil de formatage de code, extensions pour EDIs populaires (VS Code, IntelliJ, Sublime Text, Neovim) et un serveur LSP, en plus bien sûr de l'outil de CLI pour gérer les projets ainsi que le gestionnaire de package. Fournir un compilateur ne suffit clairement plus. Il faut du "prêt à coder".

Rust l'a compris en venant déjà avec tout ça. Java l'avait déjà compris à l'époque avec un JDK fourni. Les frameworks le font aussi souvent ne serait-ce qu'avec un outil de CLI à tout faire.

Inversement, JavaScript tient une grande partie de son succès parce qu'il est nativement supporté par les navigateurs, ce qui ne laisse côté client que le choix entre JavaScript et des langages qui se transpilent en JavaScript (TypeScript, ReScript, OCaml...). WASM ouvre des possibilités cependant.

La chance de JavaScript est d'avoir été au bon endroit au bon moment, d'avoir été le seul langage disponible pour du web client après que la chasse aux plugins ait éliminé Java et ActionScript ("Flash"). JS a aussi eu un beau relais de croissance avec l'interpréteur Node.js qui a sorti JS du navigateur.

Mais sa chance est peut-être en train de tourner pour JavaScript avec Deno :

• Né en se posant les bonnes questions. Deno est né de la prise de recul du créateur de Node.js sur son oeuvre majeure, et corrige ce que ce dernier regrette dans Node.
• Deno promeut TypeScript au titre de "first class citizen", au même niveau que JavaScript (via un transpiler TS intégré), ce qui rend ce bon vieux JS plus que jamais facilement contournable.
• Deno vient lui aussi avec tout son outillage directement intégré : linter, formateur de code, générateur de documentation, outil de gestion de projet, extensions pour IDE, compilateur aussi (faire de son script/projet Deno un exécutable standalone).
• Compatibilité avec l'écosystème NPM, ce qui compense les manques de son écosystème naissant.

[fdecode]

En déréférançant un raw pointer ?

Comme ça je doute mais je ne suis pas dev.

Je pense que Rust permet de désactiver des trucs pouvant poser des probs. donc unsafe comme l'indique le nom, permettant donc de faire les mêmes bugs qu'en C.

C'est un point de vue un peu théorique. Dans la pratique, c'est différent.

unsafe permet de circonscrire les zones à problème, et donc de faciliter le fait qu'une attention particulière des développeurs soit mise sur ces points à problèmes.

Dans la pratique, les parties sûres (l'essentiel du code) ne génèrent effectivement pas de problème de mémoire. Les parties en unsafe sont des exceptions,* mais ne nécessitent donc qu'un effort localisé. C'est très agréable à l'usage.

En d'autres mots, la syntaxe du langage fait que si le développeur produit du code non sûr, il ne peut le faire que délibérément, cela peut être contrôlé, et on sait où retrouver ces codes (qui sont dans des blocs unsafe).

Pour ce qui est des sécurités sous unsafe, il en existe effectivement, qui empêchent ou tout au moins compliquent certaines programmations dangereuses.
Par exemple, la transformation d'une référence non mutable en référence mutable est proscrite ainsi que la duplication d'une référence mutable, même en unsafe; les pointeurs constants ne permettent pas la mutabilité.
En revanche, les pointeurs sont duplicables, et les casting permettent de passer de pointeurs constant à pointeur mutables (ou à entier), ce qui permet des contournements très transgressifs en unsafe (comme des Undefined Behavior détectables par l'outil miri).
Toutefois, ces contournements ne peuvent être faits que sciemment et pas par accident.

* Même dans la programmation système, les blocs unsafe sont évités s'ils ne sont pas nécessaires: https://doc.redox-os.org/book/develo...safe-rust-code

[Christophe]

C'est un point de vue un peu théorique.

Ben oui, je suis pas du domaine dev.

Dans la pratique, c'est différent.

Là seul quelqu'un ayant un minimum de maitrise du C et de Rust peut donner un avis éclairé.

Dans l’écosystème des devs du noyau, Rust ne semble pas faire consensus, mais au moins ils savent de quoi ils parlent. Espérons que lea compétence technique dépasse la guerre d'égo.

[floyer]

Je pense que la plupart des développeurs Rust n’utilisent pas ou ne devraient pas utiliser «*unsafe*». Les exceptions pourraient être : ceux qui font du code en interface avec d’autres langages (C principalement), et ceux qui font des optimisations très spécifiques. L’idée n’est pas de commencer l’ensemble des définitions de fonctions avec un unsafe avec l’idée que cela donne plus de liberté. Il semble que C# a aussi un unsafe… le retour d’expérience pourrait être utile.

[NotABread]

typiquement, tu prends un tableau que tu divises en deux sous tableau mutable et sans copie: tu ne peux pas le faire avec du Rust safe car tu aurais besoin deux emprunt d'une même ressource. Un tableau Rust, c'est un pointeur brute et une taille, tu peux donc faire un bloc unsafe pour faire un nouveau tableau avec le pointeur brute du tableau initial et d'une longueur égale à l'index auquel tu veux couper et un deuxième tableau avec pour pointeur le pointeur du tableau initial + l'index de découpe et de longueur ce qu'il reste du tableau.
Cela restera sûre d'un point de vue mémoire car les deux sous tableaux seront parfaitement distincts et n'introduira pas de comportement indéfinie.
Rien empêche de se saboter dans cet exemple et de faire se chevaucher les deux sous tableaux, mais le but ici est de montrer que du code unsafe n'efface pas la sécurité mémoire de tout le reste tant que l'on sait ce que l'on fait

[Pyramidev]

typiquement, tu prends un tableau que tu divises en deux sous tableau mutable et sans copie: tu ne peux pas le faire avec du Rust safe car tu aurais besoin deux emprunt d'une même ressource.

En safe Rust, on peut appeler split_at_mut ou split_at_mut_checked.

[fdecode]

En safe Rust, on peut appeler split_at_mut ou split_at_mut_checked.

Oui, autant utiliser les méthodes existantes en safe. Je ne ferais pas de manipulation unsafe sur un type de la librairie standard sans lire le rustonomicon et me renseigner sur des risques possibles d'UB.

[NotABread]

En safe Rust, on peut appeler split_at_mut ou split_at_mut_checked.

C'est exactement ce que font ces méthodes, il y a un unsafe derrière tout ça (de même qu'il y a fatalement un unsafe derière tous les smart pointer de Rust, l'allocation sur le tas est unsafe)

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
    pub const fn split_at_checked(&self, mid: usize) -> Option<(&[T], &[T])> {
        if mid <= self.len() {
            // SAFETY: `[ptr; mid]` and `[mid; len]` are inside `self`, which
            // fulfills the requirements of `split_at_unchecked`.
            Some(unsafe { self.split_at_unchecked(mid) })
        } else {
            None
        }
    }
 
    pub const fn split_at_mut(&mut self, mid: usize) -> (&mut [T], &mut [T]) {
        match self.split_at_mut_checked(mid) {
            Some(pair) => pair,
            None => panic!("mid > len"),
        }
    }
 
    pub const unsafe fn split_at_unchecked(&self, mid: usize) -> (&[T], &[T]) {
        // FIXME(const-hack): the const function `from_raw_parts` is used to make this
        // function const; previously the implementation used
        // `(self.get_unchecked(..mid), self.get_unchecked(mid..))`
 
        let len = self.len();
        let ptr = self.as_ptr();
 
        assert_unsafe_precondition!(
            check_library_ub,
            "slice::split_at_unchecked requires the index to be within the slice",
            (mid: usize = mid, len: usize = len) => mid <= len,
        );
 
        // SAFETY: Caller has to check that `0 <= mid <= self.len()`
        unsafe { (from_raw_parts(ptr, mid), from_raw_parts(ptr.add(mid), unchecked_sub(len, mid))) }
    }

Et je plussoie, c'est toujours mieux d'utiliser l'existant (encore plus s'il est éprouvé) que de tout refaire soit-même

[fdecode]

typiquement, tu prends un tableau que tu divises en deux sous tableau mutable et sans copie: tu ne peux pas le faire avec du Rust safe car tu aurais besoin deux emprunt d'une même ressource. Un tableau Rust, c'est un pointeur brute et une taille, tu peux donc faire un bloc unsafe pour faire un nouveau tableau avec le pointeur brute du tableau initial et d'une longueur égale à l'index auquel tu veux couper et un deuxième tableau avec pour pointeur le pointeur du tableau initial + l'index de découpe et de longueur ce qu'il reste du tableau.

En simplifiant. Mais faire des manipulations sur des types de la librairie std ne s'improvise pas, à mon avis.
-> Lire le Rustonomicon a minima.
-> Examiner les sources.
Dans les sources de la librarie std,
https://github.com/rust-lang/rust/bl...src/vec/mod.rs
https://github.com/rust-lang/rust/bl...src/raw_vec.rs
on trouve les définitions suivantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
pub struct Vec<T, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global> {
    buf: RawVec<T, A>,
    len: usize,
}

puis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
pub(crate) struct RawVec<T, A: Allocator = Global> {
    inner: RawVecInner<A>,
    _marker: PhantomData<T>,
}

et:

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
 
type Cap = core::num::niche_types::UsizeNoHighBit;
 
[...]
 
struct RawVecInner<A: Allocator = Global> {
    ptr: Unique<u8>,
    /// Never used for ZSTs; it's `capacity()`'s responsibility to return usize::MAX in that case.
    ///
    /// # Safety
    ///
    /// `cap` must be in the `0..=isize::MAX` range.
    cap: Cap,
    alloc: A,
}

Il faut donc prévoir aussi de renseigner la capacité des sous tableaux. Et ce serait bien de comprendre le fonctionnement de 'Allocator'... (moi, je ne connais pas bien)

[fdecode]

C'est exactement ce que font ces méthodes, il y a un unsafe derrière tout ça (de même qu'il y a fatalement un unsafe derière tous les smart pointer de Rust, l'allocation sur le tas est unsafe)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
    pub const fn split_at_checked(&self, mid: usize) -> Option<(&[T], &[T])> {

Et je plussoie, c'est toujours mieux d'utiliser l'existant (encore plus s'il est éprouvé) que de tout refaire soit-même

Ok, vous parliez de slice, pas de tableaux dynamiques.

c'est un pointeur brute et une taille

Et plus précisément, c'est un exemple de pointeur gras en Rust.

[Patrick Ruiz]

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

Hector Martin, chef de projet d'Asahi Linux, a annoncé sa démission du projet. Il blâme entre autres le manque de soutien de Linus Torvalds en matière d’intégration du code Rust dans le noyau open source. La situation part de l'opposition de Christoph Hellwig (mainteneur principal du noyau) à un correctif proposé le mois dernier par Hector Martin et qui devait permettre aux pilotes de périphériques écrits en Rust d'appeler l'API DMA du noyau, principalement basé sur le langage C, qui alloue et mappe des régions de mémoire pour l'accès direct à la mémoire. Des observateurs sont d’avis que ces oppositions entre mainteneurs C et Rust n’auraient pas lieu si les décideurs du noyau Linux avaient opté pour la conversion du code C du kernel vers du C++ moderne.

« Je démissionne de mon poste de chef du projet Asahi Linux, avec effet immédiat. Le projet continuera sans moi et je travaille avec le reste de l'équipe pour gérer le transfert des responsabilités et des références administratives. Mon Patreon personnel sera mis en pause, et ceux qui m'ont soutenu personnellement sont encouragés à transférer leur soutien à l'Asahi Linux OpenCollective (GitHub Sponsors ne me permet pas de mettre unilatéralement en pause les paiements, mais mes sponsors seront notifiés de ce changement afin qu'ils puissent annuler manuellement leur parrainage).

Je tiens à remercier toute l'équipe d'Asahi Linux, sans qui je ne serais jamais arrivé à rien tout seul. Vous savez tous qui vous êtes. J'exprime également ma plus grande gratitude à tous mes sponsors Patreon et GitHub, qui ont fait de ce projet une réalité viable au départ », annonce-t-il.

Hector Martin's resignation from the Asahi Linux project ignites fierce debate on Rust's integration into the Linux kernel. Key takeaways: - Indecision from leaders like Linus Torvalds has fueled division and toxicity in discussions. - Clear governance is critical to avoid… pic.twitter.com/3iaUYkCjvC

— TechRandomizer (@TechRandomizer) February 8, 2025

Linus Torvalds est d’avis que Rust est une solution d’avenir pour le noyau Linux

Il considère la prise en charge de Rust pour le développement du noyau Linux 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é.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les 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. 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 mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Certains intervenants pensent que le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir », souligne le développeur Linux – Peter anvin.

Jiri Slaby de SUSE Lans s'est prononcé en faveur de cette initiative C++ pour le noyau Linux. David Howells de Red Hat s'est également prononcé en faveur de cette approche.

Source : Annonce

Et vous ?

Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

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

[Christophe]

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.