Kage : Google veut mettre les pilotes Linux en cage avant qu’un bug n’emporte tout le noyau

Le pilote qui plante possède actuellement les clés du royaume

L’un des vieux compromis du noyau Linux est assez simple : un pilote doit pouvoir travailler très vite avec le matériel, donc on l’installe directement dans le noyau avec de gros privilèges. C’est excellent pour les performances et extrêmement pratique jusqu’au jour où le code contient un dépassement de tampon, un use-after-free ou une autre joyeuseté mémoire. Lors de la présentation de Kage à la Linux Plumbers Conference 2026 , Zachary Yedidia de Stanford et Google rappelait l’ampleur du problème : le pilote Wi-Fi bcmdhd représente environ 300 000 lignes, iwlwifi autour de 240 000, tandis que les pilotes GPU Linux dépassent collectivement les deux millions de lignes. Sur Android, le Wi-Fi est particulièrement intéressant pour un attaquant puisqu’il est exposé au réseau, et le GPU peut se retrouver sollicité depuis des contenus contrôlés par un navigateur.

La solution idéale est évidemment d’écrire davantage de code système dans des langages à sûreté mémoire comme Rust, tendance déjà bien engagée dans Linux et Android. Mais réécrire plusieurs millions de lignes de pilotes existants, leurs dépendances et tous les comportements acquis au fil des années ne se fait pas entre deux releases du kernel. C’est justement le terrain de Kage : isoler du code existant sans devoir nécessairement le réinventer. Le projet est encore expérimental et n’est pas une fonctionnalité standard du noyau Linux aujourd’hui, mais Google le présente comme une piste pour réduire les conséquences d’une vulnérabilité présente dans un module.

LFI : une sandbox sans sortir du processus

La technologie qui rend l’idée possible s’appelle Lightweight Fault Isolation, ou LFI. Développée initialement dans le cadre de recherches de Zachary Yedidia à Stanford avec le soutien de Google, elle appartient à la famille des techniques de Software Fault Isolation : au lieu d’utiliser une machine virtuelle ou même un processus différent pour créer une barrière de sécurité, le compilateur transforme le code machine afin de limiter les endroits auxquels il peut accéder et vers lesquels il peut sauter. La documentation officielle de LFI dans LLVM explique que du code C, C++ et même assembleur existant peut généralement être recompilé pour être confiné dans une portion déterminée de l’espace virtuel.

Dans son fonctionnement actuel, une sandbox LFI utilise une région virtuelle de 4 Gio. Les accès mémoire et certains branchements sont réécrits afin que leur destination reste dans cette zone, et le programme est limité à un sous-ensemble d’instructions considéré comme sûr. Surtout, la sécurité ne repose pas uniquement sur le fait de faire confiance au compilateur : un vérificateur de code machine inspecte le binaire avant son exécution. Le travail de recherche originel présentait environ 65 000 sandboxes possibles dans le même espace d’adressage et un surcoût de l’ordre de 7 % sur un sous-ensemble de SPEC CPU 2017 en isolation complète.

Le support LFI pour AArch64 est désormais intégré en amont dans LLVM, tandis que la version x86-64 est encore en cours de finalisation pour le cycle LLVM 24. Les mesures présentées cette semaine à Prague situent le coût d’une isolation complète à environ 6,9–8,6 % sur AArch64 et 7,1–7,9 % sur x86-64 dans les benchmarks LFI généraux. En mode moins strict, protégeant par exemple uniquement les écritures ou les sauts, le coût baisse nettement. Ce sont des chiffres de LFI lui-même, pas encore des benchmarks de Kage avec de vrais gros pilotes Linux : Google indique justement que la mesure des performances de VKage reste l’une des prochaines étapes.

Kage garde le pilote dans le kernel… mais lui construit quatre murs

Kage applique ce mécanisme directement aux modules Linux. Le pilote est compilé avec une cible LFI ; son fichier .ko porte une note particulière détectée par le chargeur de modules. Le code machine est vérifié, puis texte, données, pile et mémoire de travail du module sont installés dans une sandbox de 4 Gio dans l’espace d’adressage du noyau. Le pilote reste au même niveau de privilège matériel que Linux — EL1 sur ARM — et dans le même espace d’adressage général, mais les instructions produites l’empêchent normalement de se promener librement dans la mémoire du kernel. Le vérificateur refuse notamment plusieurs instructions privilégiées susceptibles de modifier des registres système ou de contourner l’isolation.

Il reste évidemment à discuter avec le noyau, sinon un pilote isolé serait à peu près aussi utile qu’une carte Wi-Fi rangée dans un coffre-fort. Kage utilise alors les informations de types BTF, le BPF Type Format, pour contrôler automatiquement les signatures des fonctions traversant la frontière. Les pointeurs internes du kernel ne sont pas directement remis au pilote : ils peuvent être remplacés par des handles opaques, tandis que des trampolines assurent les transitions entre environnement hôte et sandbox. Les développeurs peuvent même compiler une variante native et une variante Kage du même module avec essentiellement le même code source, ce qui est précisément l’un des attraits de l’approche.

Pour les petits modules, ça fonctionne déjà

Google montre trois exemples actuellement fonctionnels. michael_mic, un algorithme de hachage, s’adapte très bien au modèle : le noyau lui donne des données et une clé, puis récupère un résultat. rtc-test, un petit pilote de périphérique, utilise des appels gardés vers les API devm et device_*. Un troisième prototype de périphérique caractère accepte même qu’un callback de tasklet entre dans la sandbox depuis un contexte softirq. Le point commun est important : l’interface entre le module et le reste de Linux reste étroite et facilement contrôlable.

Kage semble donc naturellement adapté aux parsers, décodeurs, algorithmes de compression ou petits pilotes dont les échanges consistent essentiellement à faire entrer des données et récupérer un résultat. C’est aussi pour ce type de code que le sandboxing fonctionne historiquement bien : beaucoup moins de structures partagées, de références croisées et de verrous distribués dans quinze sous-systèmes différents. LFI est d’ailleurs déjà employé dans Android pour isoler des codecs audio dans le sous-système média, selon la présentation LPC.

Puis quelqu’un a essayé avec un vrai pilote Wi-Fi

C’est à ce moment que l’élégante architecture commence à rencontrer Linux tel qu’il existe réellement. Un gros pilote NVMe importe environ 181 symboles du noyau dans l’exemple présenté par Google. iwlmvm, utilisé avec les cartes Wi-Fi Intel, en importe 354. Ces pilotes manipulent des pointeurs kernel bruts, partagent des locks et des compteurs de références et dépendent d’API internes qui changent régulièrement puisque Linux refuse volontairement de garantir une ABI stable pour ses modules internes.

Créer une frontière propre autour de tout cela devient vite extrêmement compliqué. Chaque fonction accessible doit être médiée, chaque objet partagé doit avoir une politique et certaines structures possèdent précisément une sémantique fondée sur le fait que noyau et pilote les manipulent ensemble. Google reconnaît donc très directement dans ses slides que les gros pilotes sont devenus difficiles à sandboxer avec Kage seul. Plutôt que d’ajouter progressivement 354 petits trous contrôlés dans le mur de la sandbox, l’équipe a cherché une autre frontière.

VKage retourne VirtIO à l’envers

Cette autre solution porte pour l’instant le nom de VKage. VirtIO sert habituellement à présenter à une machine virtuelle un périphérique simple et standardisé derrière lequel le système hôte cache le vrai matériel. VKage retourne le raisonnement : le Linux principal utilise un pilote VirtIO relativement simple, tandis que le véritable pilote matériel complexe est repoussé de l’autre côté de la frontière d’isolation.

Dans le prototype présenté, VFIO permet à un environnement isolé de contrôler le vrai périphérique, User-Mode Linux peut faire tourner un noyau Linux et donc son vrai pilote dans un processus utilisateur, tandis que VDUSE/vDPA expose ensuite au système hôte un périphérique VirtIO correspondant. Google possède déjà des prototypes opérationnels pour du stockage NVMe via virtio-blk , de l’Ethernet avec le pilote Intel igb via virtio-net, et du Wi-Fi Intel iwlwifi ou MediaTek mt7925 grâce à un nouveau virtio-wlan.

C’est un montage que seul l’écosystème Linux pouvait probablement produire avec un visage parfaitement sérieux : pour protéger un pilote Linux contre Linux, on met un autre Linux dans un processus, on lui donne le périphérique réel, puis on fait croire au premier Linux qu’il parle à un périphérique virtuel.

Et manifestement, ça marche.

La contrepartie s’appelle latence

VKage possède toutefois une faiblesse assez évidente : chaque opération doit franchir davantage de couches. VirtIO fournit une frontière beaucoup plus propre que les centaines d’appels internes utilisés par un pilote traditionnel, mais un aller-retour vers un processus utilisateur coûte plus cher qu’un appel de fonction au sein du kernel. Les slides indiquent explicitement cette latence supplémentaire comme l’une des limites actuelles, aux côtés de classes de périphériques absentes de VirtIO et de fonctions très spécifiques au matériel qui ne rentrent pas toujours proprement dans une interface générique.

Google envisage donc déjà un hybride : utiliser l’interface VirtIO comme frontière propre, mais éventuellement déplacer certaines parties sensibles à la latence dans une sandbox LFI directement à l’intérieur du noyau. L’idée serait de garder la sécurité architecturale d’une interface standardisée sans forcément payer tous les passages vers l’espace utilisateur. Pour le moment, cela reste une direction de recherche et non une fonctionnalité annoncée pour Linux 7.4, Android 18 ou votre routeur la semaine prochaine.

Et le pilote GPU dans tout ça ?

Le mot GPU apparaît naturellement assez vite. Les drivers graphiques modernes sont énormes, exposés à des entrées complexes et utilisés par des applications peu fiables comme les navigateurs. Ils constituent donc théoriquement d’excellents candidats à une isolation plus forte. Le problème est qu’ils comptent également parmi les morceaux de code les plus dépendants des performances, de la mémoire partagée, des interruptions, du DMA et d’interactions extrêmement fréquentes avec le noyau. Google indique que VKage pourrait en principe être essayé avec les GPU, mais qu’il reste beaucoup de travail pour déterminer si la technique est réellement pratique et quel serait son coût.

Les prochaines étapes citées sont plus immédiates : mesurer précisément les performances, optimiser les prototypes et tester le modèle sur de véritables pilotes Android. Phoronix souligne lui aussi cet angle Android dans sa couverture du projet publiée ce 7 octobre.

Pourquoi ne pas simplement tout refaire en Rust ?

Parce que les deux stratégies peuvent très bien être complémentaires. Rust réduit le nombre de nouvelles erreurs mémoire pouvant être introduites dans un pilote écrit avec ses abstractions sûres. Kage et LFI cherchent plutôt à répondre au problème beaucoup plus ingrat du code déjà là, parfois écrit depuis vingt ans, et du code tiers que l’on ne souhaite pas forcément considérer comme totalement fiable. Une sandbox peut également continuer à limiter les dégâts provoqués par un bug logique ou par du code volontairement hostile dans des endroits où la sûreté mémoire seule ne suffit pas.

Et surtout, Linux ne deviendra probablement jamais un système où tous les pilotes C disparaissent du jour au lendemain. LFI est justement conçu pour accepter des bibliothèques et pilotes C/C++ existants moyennant recompilation, y compris avec de l’assembleur. Le support officiel désormais intégré à LLVM transforme donc cette idée en une technologie que d’autres projets peuvent commencer à expérimenter sans maintenir leur propre fork complet du compilateur.

Kage est encore un labo, mais l’idée ressemble beaucoup à l’avenir du kernel

Il serait prématuré d’annoncer que Linux va soudainement devenir un microkernel où chaque pilote habite derrière une vitre blindée. Kage est un prototype, ses cas les plus simples fonctionnent, les gros pilotes ont obligé Google à expérimenter une architecture différente et les performances de VKage doivent encore être sérieusement mesurées. Même le support x86-64 complet de LFI est toujours en cours de finalisation côté LLVM.

Mais l’idée répond à un problème auquel Linux devra probablement continuer à s’attaquer : comment profiter de décennies de code natif extrêmement performant sans continuer à considérer chaque module chargé dans le noyau comme un colocataire auquel on remettrait le mot de passe du coffre-fort ? Rust apporte une partie de la réponse pour le nouveau code. Les VM et pilotes userspace peuvent en fournir une autre lorsque leur coût est acceptable. Kage cherche un troisième chemin : garder la proximité et les performances du noyau, tout en supprimant progressivement le principe selon lequel “chargé dans le kernel” signifie automatiquement “autorisé à toucher à tout”.

Un pilote Wi-Fi continuera peut-être à contenir 300 000 lignes de C.

La différence, si Kage fonctionne un jour à grande échelle, c’est que son prochain bug mémoire pourrait simplement casser le Wi-Fi.

Ce qui, comparé à casser tout le noyau, serait presque une fonctionnalité.