Google retire le pilote Binder en C du noyau Linux au profit de sa réécriture Rust
Le 18 septembre 2026, Google a soumis le patch qui supprime les 11 000 lignes du pilote Binder en C, remplacé par la version Rust amontée dans Linux 6.18 et prévue pour Linux 7.4. C’est la première fois qu’un pilote majeur du noyau bascule intégralement au Rust.
18 septembre 2026. L’ingénieur Google Carlos Llamas soumet le patch qui supprime les 11 000 lignes du pilote Binder écrit en C. Linux 6.18. La réécriture Rust du même pilote avait été amontée dans le noyau. Linux 7.4. Le retrait du code C est prévu pour cette fenêtre de fusion. Pourquoi c’est important : c’est la première fois qu’un pilote majeur du noyau Linux est remplacé intégralement par une version Rust — et l’argument avancé n’est pas seulement la sécurité, mais la maintenabilité.
Binder, la plomberie invisible d’Android
Binder est le mécanisme de communication inter-processus (IPC) qui fait tourner Android depuis ses débuts. Chaque application, chaque service système, chaque notification qui transite entre un processus et un autre passe par lui. Dans le noyau, c’est un pilote de caractères parmi les plus sollicités : des milliards d’appels par jour sur chaque téléphone en circulation.
Pendant plus de quinze ans, ce pilote a été écrit en C. Il a grandi au rythme des évolutions d’Android, accumulant des correctifs, des optimisations et des chemins d’exécution de plus en plus enchevêtrés. Le mot que choisit Carlos Llamas dans son message de patch n’est pas « dangereux » mais « douloureux » : le code C est devenu « incredibly painful to maintain », pénible à faire évoluer sans « trébucher sur des vulnérabilités ».
C’est le cœur de l’histoire. Binder n’est pas un pilote exotique abandonné : c’est un composant critique, ubiquitaire et ancien. Or ce sont précisément ces trois propriétés qui rendent un pilote C difficile à maintenir — chaque nouvelle fonctionnalité doit être ajoutée sans casser des invariants que personne ne maîtrise plus entièrement.
La bascule : yanker le C, couronner le Rust
La réécriture Rust n’est pas sortie de nulle part. Elle est le travail de plusieurs années de l’équipe Rust-for-Linux, porté en grande partie par Alice Ryhl. Le pilote Binder en Rust a été amonté dans Linux 6.18, marquant l’une des premières incursions d’un « vrai » pilote écrit dans ce langage dans le noyau principal.
Le message de patch de Carlos Llamas est sans détour : « The day has finally come. We are dropping the legacy C implementation of the Binder IPC driver in favor of its Rust version. » Il précise que Alice Ryhl a non seulement atteint la parité fonctionnelle complète, mais aussi démontré que la version Rust égale, et souvent bat, les performances de l’équivalent C. Le pilote tourne déjà sur des appareils Android réels depuis un certain temps — ce qui, écrit-il, permet de cesser de parler d’« expérience ».
Le patch de suppression des 11 000 lignes de C a été repris par Greg Kroah-Hartman dans la branche char-misc-next, ce qui le destine à la fenêtre de fusion de Linux 7.4. Autrement dit, le retrait n’est pas un vœu : il est déjà dans le pipeline officiel du noyau.
Rust-for-Linux, le long chemin jusqu’ici
La bascule de Binder ne sort pas du vide : elle est l’aboutissement d’un effort lancé il y a plusieurs années sous le nom de Rust-for-Linux. Les premières abstractions — des couches sûres qui enveloppent les API internes du noyau dans des types Rust — sont entrées dans le noyau principal à partir de Linux 6.1. Depuis, la progression est lente et prudente : chaque nouvelle abstraction doit être validée par les mainteneurs, soucieux que le langage ne devienne pas une seconde source de bugs.
Le pilote Binder en Rust est l’un des premiers cas d’usage « réels » de ces abstractions. Contrairement à un module expérimental, il devait couvrir un comportement complet — tous les chemins d’IPC d’Android — avec une exigence de performance comparable au C. C’est ce cahier des charges, et le fait qu’il tourne en production sur des téléphones, qui donne aujourd’hui à Google la confiance nécessaire pour retirer le code C.
Le vrai enjeu : la maintenabilité, pas seulement la mémoire
L’argument le plus souvent avancé pour Rust dans le noyau est la sécurité mémoire — l’élimination, à la compilation, de classes entières de bugs comme les use-after-free, les buffer overflows ou les courses de données. Binder a d’ailleurs un historique de vulnérabilités dans ce registre, comme CVE-2019-2215, un use-after-free exploité dans la nature.
Mais le message de Google met en avant un bénéfice moins spectaculaire et plus structurant : la maintenabilité. Un pilote Rust force les invariants de propriété et de durée de vie à être exprimés explicitement dans le type système. Ajouter une fonctionnalité ne revient plus à deviner quels invariants implicites du code C il ne faut pas violer : le compilateur les vérifie. C’est ce qui permet à l’équipe de « se concentrer sur les nouvelles fonctionnalités et optimisations » au lieu de passer son temps à éviter de casser l’existant.
La nuance compte. Rust ne supprime pas les bugs logiques — une mauvaise politique d’accès reste une mauvaise politique d’accès. Mais il retire du chemin la classe d’erreurs qui a historiquement fourni l’essentiel des vulnérabilités exploitables du noyau. Et il rend le coût de la maintenance prévisible, ce qui est exactement ce qu’un pilote de quinze ans avait cessé d’être.
Concrètement, Rust transforme les classes de bugs les plus coûteuses du C en erreurs de compilation. Un use-after-free devient une violation du modèle d’emprunt (le borrow checker) : le compilateur refuse le code avant même qu’il soit exécuté. Un buffer overflow est intercepté par les vérifications de bornes et les types de taille explicites. Une course de données sur une structure partagée est impossible sans passer par des primitives de synchronisation explicites. Aucune de ces garanties n’élimine les fautes de logique, mais elles retirent du code les failles qui dominent les bulletins de sécurité du noyau depuis des années.
Ce que ça change pour le noyau
Binder n’est pas le premier code Rust du noyau — d’autres pilotes et abstractions y sont entrés progressivement depuis Linux 6.1. Mais c’est le premier cas d’un remplacement complet d’un pilote C majeur par sa réécriture Rust, avec un argument public de parité et de performance. C’est un précédent : il fournit un modèle reproductible pour les autres pilotes critiques vieillissants.
Pour un administrateur, la traduction concrète est simple. Sur Android, rien ne change du point de vue utilisateur — le pilote est déjà en production. Sur les distributions qui compilent le noyau, la question qui se posera à partir de Linux 7.4 est celle de la disponibilité des bindings Rust dans la chaîne de compilation, car un noyau qui active Binder devra désormais compiler du Rust. La vérification locale se fait en une commande :
# Vérifier si le noyau courant embarque le pilote Binder et sa variante Rust
grep -E 'CONFIG_ANDROID_BINDER|CONFIG_RUST' /boot/config-$(uname -r) 2>/dev/null || \
grep -E 'CONFIG_ANDROID_BINDER|CONFIG_RUST' /proc/config.gz 2>/dev/null | zcatLa tendance de fond est plus large que Binder. Le noyau Linux absorbe du Rust pilote par pilote, à un rythme mesuré, mais désormais irréversible. Binder en est la première grande démonstration à l’échelle d’un composant critique.
Verdict
Le retrait du Binder en C pour Linux 7.4 n’est pas une anecdote d’ingénierie : c’est la première preuve, dans le noyau principal, que Rust peut remplacer un pilote C de production à parité de fonctionnalités et de performances, avec un gain de maintenabilité assumé comme argument central. Si vous maintenez des noyaux pour des appareils Android ou des systèmes embarqués, préparez votre chaîne de compilation aux bindings Rust avant la fenêtre 7.4. Si vous suivez l’évolution du noyau, retenez la date : Binder est le premier grand pilote à passer intégralement au Rust — et ce ne sera pas le dernier.