FortiBleed : le FBI signale des administrateurs de pare-feu Fortinet privés d’accès à leurs propres appareils

Technique · Atelier

Enfermer un pilote dans le noyau sans le sortir du noyau : Kage et l’isolation logicielle des fautes

Des ingénieurs de Google expérimentent Kage, un sous-système Linux qui fait tourner des pilotes dans des « bacs à sable » à l’intérieur même du noyau. La technique, l’isolation logicielle des fautes, est ancienne ; ce qui change, c’est qu’elle arrive dans le compilateur LLVM. Atelier pédagogique sur ce qu’elle garantit et ce qu’elle coûte.

Le problème. Sous Linux, un pilote de périphérique s’exécute avec tous les privilèges du noyau, dans le même espace d’adresses. Une simple écriture hors limites dans un pilote USB ou réseau peut donc corrompre n’importe quelle structure du noyau. La présentation de Kage à la Linux Plumbers Conference 2026 rappelle que les pilotes représentent une part importante des failles exploitables. Les réponses classiques ont chacune un prix. Sortir le pilote en espace utilisateur (comme le permettent VFIO ou UIO, ou comme le font les micronoyaux) oblige à changer de contexte à chaque appel, ce qui coûte cher pour un pilote réseau ou de stockage. Réécrire en Rust élimine les erreurs mémoire dans le code dit « sûr », mais ne contient pas un pilote dont le code non sûr, ou le code existant en C, déraille.

L’idée : borner chaque accès au moment de la compilation. L’isolation logicielle des fautes (SFI, décrite par Wahbe et ses collègues en 1993, et utilisée par Google dans Native Client) ne s’appuie pas sur la protection matérielle de la mémoire. Le compilateur réécrit le code de façon que chaque accès mémoire et chaque saut indirect soient ramenés dans une zone réservée de l’espace d’adresses. Le code isolé reste au même niveau de privilège que le reste du noyau, mais il ne peut plus lire, écrire ni sauter ailleurs. Comme il n’y a pas de changement de contexte, passer du noyau au pilote reste presque aussi bon marché qu’un appel de fonction. LFI (Lightweight Fault Isolation), développé à Stanford avec le soutien de Google, est une version moderne de cette approche. Elle est intégrée à LLVM pour AArch64, et le support x86-64 vise LLVM 24. Point essentiel : un vérificateur contrôle le code machine produit avant de le charger. On n’a donc pas besoin de faire confiance au compilateur, et l’isolation tient même face à du code délibérément malveillant. C’est le même principe que le vérificateur d’eBPF : on ne fait pas confiance à l’auteur, on prouve une propriété du code avant de l’exécuter.

Le vrai travail : la frontière. Borner la mémoire ne suffit pas, car un pilote appelle sans cesse des fonctions du noyau et reçoit des pointeurs. Kage utilise les informations de types BTF du noyau pour vérifier automatiquement la signature de chaque appel qui franchit la frontière, et remplace les pointeurs du noyau par des identifiants opaques : le pilote manipule un ticket, pas une adresse qu’il pourrait déréférencer. Le prototype sait aujourd’hui isoler des modules de calcul simples. Il reste à gérer les accès directs aux registres du matériel, le partage de tampons, le DMA (par lequel un périphérique écrit lui-même en mémoire, à cadrer avec l’IOMMU) et les interruptions. Une variante, « VKage », qui fait dialoguer le pilote isolé avec le noyau au travers d’interfaces VirtIO, a déjà permis de prototyper des pilotes NVMe, réseau et Wi-Fi isolés. Les performances restent à évaluer plus en détail. Leçon générale pour tout développeur : isoler un composant, c’est surtout concevoir une interface étroite et vérifiable entre lui et le reste, bien plus que choisir un mécanisme de cloisonnement.

Sources : Linux Plumbers Conference 2026 — présentation de Kage · ACM — article sur Kage · Phoronix, 07.10.2026 — atelier pédagogique