Asterinas : un noyau Linux-compatible écrit en Rust

Asterinas : un noyau Linux-compatible écrit en Rust

Article extrait de ma veille et rédigé par une IA. Je vous le partage brut.

Introduction

Asterinas est un noyau d’exploitation (OS) récent, conçu pour être compatible avec Linux au niveau binaire tout en étant écrit entièrement en Rust. Concrètement, il vise à remplacer le noyau Linux sous les applications existantes sans nécessiter aucune modification de celles-ci. Son ambition est d’offrir à la fois de hautes performances et une sécurité renforcée, en particulier contre les erreurs mémoire, grâce aux garanties du langage Rust (les auteurs le décrivent comme « secure, fast and general-purpose », c’est-à-dire sécurisé, rapide et polyvalent).

Pour atteindre cet objectif, Asterinas adopte une approche architecturale innovante appelée framekernel : tout le noyau est codé en Rust, et le recours aux parties non sécurisées de Rust (unsafe) est strictement limité à un noyau minimal de confiance (le TCB, Trusted Computing Base). Le reste du système (gestion des processus, pilotes, système de fichiers, réseau, etc.) est implémenté en Rust sûr, ce qui confère au noyau une sécurité mémoire nettement supérieure aux noyaux classiques en C. En parallèle, Asterinas cherche à rester généraliste et performant, afin de servir d’OS universel pour différents scénarios.

Le projet met aussi l’accent sur l’expérience développeur : les concepteurs d’Asterinas profitent du langage Rust (plus moderne et productif que le C), d’un outil de développement dédié (OSDK) et d’une licence de type MPL qui leur laisse la liberté de publier ou non le code source de leurs modules noyau. En somme, Asterinas se positionne comme un noyau « nouvelle génération » à destination des passionnés et experts en systèmes qui souhaitent explorer des bases plus sûres pour les OS.

Dans cet article, nous allons passer en revue l’architecture interne d’Asterinas, les choix de conception dictés par Rust, l’écosystème et les usages envisagés autour de ce noyau, puis comparer Asterinas à Linux tout en faisant le point sur son état d’avancement actuel.

Architecture interne d’Asterinas

Un compromis entre monolithe et micro-noyau

Architecture monolithique, micro-noyau et framekernel. En rose, le TCB (noyau minimal de confiance) et en vert le code non critique ; dans l’architecture framekernel, les services non privilégiés communiquent avec le framework central via des appels directs (chemin « fast path ») au lieu de passer par des appels système plus coûteux (chemin « slow path »), ce qui préserve les performances d’un noyau monolithique tout en réduisant la taille du TCB.

Les systèmes monolithiques traditionnels (comme Linux) exécutent tout le code du noyau dans un même espace mémoire privilégié, ce qui rend la base de confiance (TCB) très large. À l’inverse, les micro-noyaux n’ont en kernel space qu’un TCB minimal et délèguent le reste à des services en espace utilisateur, au prix de communications inter-processus (IPC, Inter-Process Communication) coûteuses entre le noyau et ces services. Asterinas propose une troisième voie : toute l’OS reste dans l’espace noyau (comme un monolithe), mais est divisé en deux parties. D’un côté, un framework privilégié très minimal (le TCB, comparable à un micro-noyau) regroupe tout le code bas niveau nécessitant du unsafe. De l’autre, les services du système (pilotes de périphériques, gestion des fichiers, réseau, etc.) s’exécutent avec des privilèges réduits et sont écrits exclusivement en Rust sûr. Ces services n’accèdent aux ressources matérielles qu’à travers les API contrôlées du framework. Ainsi, toute opération risquée est confinée dans le petit framework, et la sûreté mémoire de l’ensemble du noyau dépend uniquement de la fiabilité de cette portion réduite de code.

Ce design permet de minimiser la taille du TCB (environ 14 % seulement du code d’Asterinas appartient à la base de confiance critique) et d’en faciliter la sécurisation, tout en évitant le surcoût des micro-noyaux. En effet, résidant dans le même espace mémoire, les services peuvent communiquer avec le framework par de simples appels de fonction et mémoire partagée, sans basculer en mode utilisateur/kernel : on préserve donc une rapidité de type monolithique (les premières mesures montrent des performances comparables à Linux sur les appels gérés). Asterinas cherche ainsi à offrir « la vitesse d’un noyau monolithique et la sécurité d’un micro-noyau ».

Gestion des processus et threads

Asterinas fournit des abstractions de haut niveau pour gérer les processus (et threads) utilisateurs en Rust sûr. La bibliothèque de base OSTD définit notamment plusieurs types représentant les éléments fondamentaux d’un système multitâche :

  • Task – gère les bascules de contexte (context switches) et la pile noyau associée à chaque tâche (processus ou thread).
  • UserMode – permet de basculer le processeur en mode utilisateur pour exécuter une tâche jusqu’à la survenue d’un événement (piège d’appel système, interruption, exception…).
  • UserContext – encapsule l’état du processeur associé à une tâche utilisateur (registres, pointeur d’instruction, etc.), ce qui permet au noyau de sauvegarder ou modifier ce contexte de façon sûre lors des changements de tâche.
  • VmSpace – représente l’espace mémoire virtuel d’un processus utilisateur et fournit des méthodes pour le gérer en toute sécurité (allocation de pages, manipulation des tables de pages, etc.).

La planification (scheduler) d’Asterinas s’appuie sur ces abstractions : le noyau peut alterner l’exécution entre plusieurs tâches en rétablissant leur contexte via Task et UserContext. La prise en charge des systèmes multi-cœurs (SMP, Symmetric Multi-Processing) est assurée dès le départ, ce qui permet d’exploiter plusieurs CPU en parallèle dans le noyau. En pratique, Asterinas peut donc créer et gérer des processus et threads isolés en mémoire, comme un Linux classique, tout en bénéficiant de la sûreté offerte par les types Rust décrits ci-dessus.

Gestion de la mémoire

Comme Linux, Asterinas s’appuie sur une MMU (Memory Management Unit, unité de gestion mémoire) pour fournir à chaque processus son propre espace d’adressage virtuel isolé. L’abstraction VmSpace mentionnée plus haut offre une interface sûre pour créer et manipuler ces espaces d’adressage sans exposer directement de pointeurs bruts ni altérer les pages mémoire de façon non contrôlée. Toute modification des tables de pages ou allocation de mémoire passe par le code du TCB, qui applique les vérifications nécessaires afin d’éviter toute corruption. En conséquence, un processus utilisateur d’Asterinas ne peut ni lire ni écrire en dehors de son adresse virtuelle allouée : s’il tente un accès illégal, la MMU déclenche une exception que le framework du noyau interceptera (typiquement, en terminant le processus fautif) sans compromettre la stabilité de l’ensemble.

Rust et l’architecture framekernel éliminent donc d’emblée les bogues classiques de gestion mémoire (segfaults, dépassements de tampon, use-after-free, etc.) dans le code du noyau non privilégié. De plus, pour parer aux failles propres aux contextes noyau, l’équipe Asterinas s’appuie aussi sur le matériel. Par exemple, les accès mémoire effectués par des périphériques en DMA (Direct Memory Access, accès direct à la mémoire) sont contrôlés via l’IOMMU (une MMU dédiée aux entrées/sorties) afin qu’un périphérique défaillant ou malveillant ne puisse pas écrire n’importe où en RAM. Le TCB d’Asterinas définit des invariants de sécurité stricts sur la gestion mémoire, et utilise ces protections matérielles (MMU/IOMMU) pour garantir l’absence de comportements indéfinis liés à la mémoire dans tout le système. En résumé, la mémoire de chaque processus est strictement isolée et protégée, ce qui contribue grandement à la robustesse du noyau.

Gestion des périphériques et systèmes de fichiers

Les périphériques matériels (stockage, réseau, etc.) sont gérés par Asterinas via des drivers écrits en Rust sûr, exécutés en tant que services non privilégiés du framekernel. Le code privilégié du TCB se charge d’interagir avec les interruptions matérielles et les registres bas niveau, puis expose des interfaces sûres que les drivers Rust peuvent utiliser. Par exemple, le composant noyau gérant la carte réseau utilise les API sûres d’OSTD pour effectuer des transferts DMA (accès direct à la mémoire) vers la carte, gérer la synchronisation par verrous et allouer de la mémoire tampon – au lieu de manipuler directement des pointeurs non vérifiés comme dans un driver Linux classique. Cette approche prévient les erreurs mémoire dans les pilotes et confine les éventuels problèmes au composant concerné sans affecter tout le système.

Asterinas supporte déjà les périphériques de virtualisation standard Virtio (pour le disque, le réseau, etc.), ce qui lui permet de fonctionner dans des hyperviseurs courants avec des E/S virtualisées. Le support d’autres contrôleurs et matériels s’étoffe graduellement au fil du développement (contrôleurs de stockage, USB, affichage, etc.), en suivant le même principe de pilotes Rust isolés.

Le support des systèmes de fichiers est également en cours d’implémentation sous forme de services Rust. Actuellement, Asterinas démarre avec un initramfs minimal (une image de système de fichiers en mémoire) contenant quelques utilitaires de base, faute de pilote de stockage complet. L’ajout de systèmes de fichiers traditionnels (ext4, etc.) et d’un véritable VFS (Virtual File System) est planifié pour accompagner l’arrivée de pilotes de stockage avancés. Notamment, l’équipe prévoit de pouvoir lancer à terme un démon Docker sur Asterinas, ce qui nécessite de prendre en charge la création de cgroups, de namespaces et un système de fichiers pour les images de conteneurs.

Il convient de souligner qu’Asterinas ne supporte pas le chargement de modules noyau Linux pré-compilés (fichiers .ko), et n’a pas vocation à le faire. Chaque pilote de périphérique doit être réécrit en Rust et intégré au noyau Asterinas. Ce choix garantit que tout le code s’exécutant en kernel space respecte les mêmes contraintes de sûreté, au prix d’un effort de portage important : là où Linux bénéficie d’une multitude de pilotes existants, Asterinas doit construire les siens progressivement. En contrepartie, cela évite d’introduire dans Asterinas du code non maîtrisé pouvant compromettre sa sécurité.

Influence du langage Rust sur le design du noyau

Le langage Rust a fortement orienté la conception d’Asterinas. Tout d’abord, Rust offre des garanties de sécurité mémoire dès la compilation : pas de déréférencement de pointeur null, pas de double libération de mémoire, pas de débordement de buffer non détecté – du moins tant que le code s’en tient au Rust “safe”. Ces propriétés facilitent grandement l’écriture d’un code noyau robuste, en supprimant des classes entières de bogues qui affectent historiquement les OS écrits en C. Rust impose une stricte discipline d’ownership (possession des ressources) et de vies (lifetimes) des données, évitant qu’une zone mémoire soit libérée tant qu’elle est encore référencée ou qu’une référence devienne pendante. En ce sens, Rust réalise à la compilation ce qui nécessitait autrefois un ramasse-miettes (GC) ou une extrême vigilance du programmeur système. De plus, son modèle de concurrence empêche les conditions de course (data races) au niveau mémoire en s’assurant qu’une donnée mutable n’est pas partagée simultanément entre plusieurs threads sans protection appropriée – un atout crucial pour un noyau multiprocesseur.

Asterinas exploite à fond ces atouts du langage. L’architecture framekernel est directement bâtie autour de la séparation du code Rust safe/unsafe : toute portion critique nécessitant des accès bas niveau est isolée dans le petit TCB, écrit en Rust avec des sections unsafe auditées, tandis que la majeure partie du code du noyau est écrite en Rust sûr et bénéficie donc automatiquement des protections du compilateur. Concrètement, tout le code des pilotes, du système de fichiers, du réseau, etc., est en Rust safe dans Asterinas. Un tel driver ne peut pas déréférencer un pointeur invalide ou écrire hors des limites d’un tableau par inadvertance – le compilateur l’en empêcherait. Cela tranche avec Linux, où une simple erreur dans un pilote en C peut conduire à un kernel panic. En encapsulant chaque composant dans des API sûres, Asterinas rend le développement du noyau aussi sécurisé et productif que celui d’une application Rust classique.

Bien entendu, restreindre le unsafe à un petit noyau de confiance ne suffit pas à garantir la fiabilité absolue : il faut encore que ce TCB soit correct. L’équipe d’Asterinas a porté une attention particulière à la notion de soundness (solidité) du noyau, c’est-à-dire l’absence de comportements indéfinis (UB) même en présence de code utilisateur ou de périphériques malveillants. Pour atteindre cet objectif, plusieurs mesures ont été prises au niveau du design et de l’implémentation du TCB :

  • Invariants de sécurité stricts – définir précisément les conditions de sûreté que chaque fonction du TCB doit respecter (par ex. validité des pointeurs, des états CPU, cohérence des tables de pages, etc.) et s’y conformer rigoureusement.
  • Protection matérielle – exploiter les mécanismes du MMU et de l’IOMMU pour faire respecter l’isolement mémoire au niveau matériel (une application ne peut accéder qu’à sa mémoire, un contrôleur DMA ne peut écrire que dans les zones qui lui sont allouées).
  • Revue du code unsafe – réduire drastiquement le volume de code marqué unsafe et le passer en revue de manière approfondie pour éliminer toute erreur de logique potentielle.
  • Outils de vérification – utiliser des outils comme Miri (interpréteur Rust détectant les UB) adaptés au contexte noyau pour tester et valider l’absence d’anomalies dans le code système.

Grâce à ces précautions, les concepteurs d’Asterinas estiment avoir éliminé les bogues mémoire du noyau sans compromis sur les fonctionnalités. Après environ trois ans de développement et plus de 100 000 lignes de Rust, Asterinas est passé d’un prototype de recherche à un système de plus en plus complet, au point de pouvoir affirmer que « la sécurité mémoire du noyau est accomplie – sans compromis ». Un audit de sécurité externe a été réalisé (par la société CertiK) et n’a pas révélé de faille majeure, confirmant la validité de l’approche. Mieux, la petite taille du TCB ouvre la voie à une vérification formelle de ce dernier (preuve mathématique de l’absence d’erreurs), à l’image du micro-noyau seL4 qui a été prouvé sûr par le passé. L’équipe Asterinas collabore d’ailleurs avec des chercheurs pour essayer d’appliquer l’outil Verus à la validation formelle de modules critiques du TCB. En résumé, Rust n’est pas seulement un langage utilisé dans Asterinas : c’en est le pilier fondateur, qui a modelé une architecture logicielle radicalement différente de celle d’un Linux, en apportant un nouveau paradigme de sûreté dans le développement du noyau.

Écosystème et cas d’utilisation

Asterinas s’inscrit dans un effort plus large pour bâtir une communauté autour des OS en Rust. Outre le noyau lui-même, le projet fournit un kit de développement complet nommé OSDK (Operating System Development Kit). Cet outil prolonge Cargo (le gestionnaire de build de Rust) afin de faciliter la création, la compilation et le test de noyaux basés sur Asterinas. En quelques commandes, on peut générer un squelette de noyau Rust, le compiler en une image bootable et le lancer dans une VM, ou même exécuter des tests unitaires du code noyau comme on le ferait pour un programme utilisateur. Par exemple, la commande cargo osdk new my-first-os --kernel initialise un projet de « Hello World » kernel, et cargo osdk run permet de le démarrer aussitôt dans QEMU ; de même, un simple cargo osdk test lancera les tests marqués #[ktest] à l’intérieur du noyau. L’objectif est de démocratiser le développement d’OS en le rendant aussi accessible que possible aux développeurs Rust.

Sous le capot, OSDK s’appuie sur une bibliothèque de runtime système nommée OSTD (Operating System Development). OSTD constitue un socle minimal, expressif et stable pour implémenter les fonctionnalités de base d’un OS en Rust. Elle offre par exemple des abstractions génériques et sûres pour gérer le matériel x86 (interruptions, ports E/S, etc.), le démarrage, la mémoire virtuelle, les processeurs multiples, les tâches et utilisateurs, les minuteries, etc.. Toutes les crates Rust développées dans cet écosystème partagent cette fondation commune (le crate ostd), ce qui favorise la réutilisation du code entre projets de noyau différents. Notamment, les APIs d’OSTD sont volontairement agnostiques par rapport à Linux : on peut très bien créer un noyau non Unix en s’appuyant sur OSTD. Asterinas n’est donc qu’une application particulière d’OSTD (une implémentation de l’ABI Linux) – d’autres pourraient voir le jour avec des objectifs différents, tout en bénéficiant du même cadre de travail. Les créateurs d’OSTD visent ainsi à faire évoluer plus rapidement le domaine des OS en permettant à la communauté d’expérimenter de nouvelles idées de noyaux Rust sans repartir de zéro à chaque fois.

En termes de cas d’usage, Asterinas cible en priorité les environnements de virtualisation et cloud. Sa compatibilité Linux en fait un excellent candidat pour servir de noyau minimal dans un hôte de conteneurs (par exemple, pour un serveur Docker allégé). Grâce à sa petite base de confiance, il s’intègre bien aux initiatives de sécurité matérielle comme Intel TDX (Trust Domain Extensions) : TDX permet d’exécuter des machines virtuelles dont la mémoire est entièrement chiffrée et isolée du reste du système. Combiné à Asterinas (qui réduit les risques de vulnérabilités dans le noyau invité), on obtient des VM “zero-trust” où même l’hébergeur cloud ne pourrait compromettre le système invité. D’ailleurs, Intel figure parmi les sponsors du projet Asterinas, tout comme Ant Group, ce qui illustre l’intérêt industriel porté à ces usages cloud sécurisés. Le marché chinois du cloud (Aliyun/Alibaba Cloud, notamment) est spécifiquement visé comme terrain d’application, avec l’idée de proposer un OS d’hébergement de conteneurs offrant un TCB minimal et potentiellement vérifié formellement pour des garanties de sécurité maximales. Asterinas supportant déjà les principaux périphériques virtuels (Virtio) utilisés dans les VMs, une grande partie des obstacles techniques à son déploiement dans ce contexte a été levée.

Qu’en est-il des systèmes embarqués ? Asterinas n’est pas conçu pour les microcontrôleurs très contraints (sans MMU) – contrairement à un OS comme Tock qui vise explicitement les microcontrôleurs sans protection mémoire – car il repose sur l’isolation matérielle et un environnement plus proche des ordinateurs classiques. En revanche, il pourrait s’avérer intéressant sur des plateformes embarquées plus puissantes qui utilisent aujourd’hui Linux (routeurs, équipements réseau, appareils IoT sous architecture ARM ou RISC-V, etc.) afin d’améliorer leur fiabilité. Son portage sur diverses architectures est en cours : il fonctionne déjà sur x86-64 et RISC-V, et le support d’ARM 64-bit figure sur la feuille de route proche. À terme, Asterinas se veut adaptable à un large éventail de matériels et d’usages (du cloud aux dispositifs embarqués), partout où l’on a besoin d’un noyau compatible Linux mais plus sûr par construction.

Enfin, bien que l’accent initial soit mis sur les serveurs, Asterinas n’exclut pas les scénarios poste de travail. Le développement d’un sous-système graphique est amorcé (par exemple, on trouve des branches visant à supporter le serveur d’affichage X11 et l’environnement de bureau Xfce). Cela pourrait à terme permettre d’exécuter un environnement utilisateur complet (bureau, applications graphiques) sur un noyau intégralement en Rust. On imagine par exemple un live CD expérimental ou une distribution minimaliste à base d’Asterinas, une fois que les pilotes graphiques et d’entrée seront fonctionnels. En somme, l’écosystème Asterinas s’adresse aussi bien aux hacker·s et chercheurs en systèmes qui veulent construire leur propre OS Rust, qu’à des cas d’usage concrets allant du cloud aux objets connectés – partout où l’on cherche la compatibilité Linux alliée à une sûreté accrue.

Comparaison avec Linux

Du point de vue de l’extérieur (applications et environnement utilisateur), Asterinas s’efforce d’imiter Linux le plus fidèlement possible. Il implémente une ABI Linux (Application Binary Interface, interface binaire applicative) compatible, c’est-à-dire les mêmes appels système et conventions d’appel qu’un noyau Linux. En théorie, un programme compilé pour Linux peut donc tourner sur Asterinas sans avoir été modifié ni recompilé. Par exemple, les appels système standard (fichier, processus, réseau…) sont présents avec le même numéro et le même comportement attendu, de sorte que les bibliothèques C (glibc, etc.) fonctionnent et que les exécutables ELF Linux peuvent être chargés normalement. En pratique, la compatibilité est encore partielle à ce stade : sur les 368 appels système que compte Linux 6.7, Asterinas en supporte un peu plus de 200 (environ 206 recensés). Cela couvre les appels de base (gestion de fichiers, processus, mémoire…), mais il manque encore de nombreuses fonctionnalités avancées du noyau Linux. Par exemple, la gestion complète des namespaces et des cgroups (indispensables pour isoler des conteneurs) n’était pas encore implémentée en milieu 2025, bien que ce soit en cours. De même, tous les pilotes de périphériques ne sont pas disponibles, ce qui limite pour l’instant le type d’applications Linux pouvant fonctionner sous Asterinas (essentiellement des programmes en mode texte dans un contexte très contrôlé).

Sur le plan interne, Asterinas diffère radicalement de Linux. Linux est un noyau monolithique écrit majoritairement en C, où tout le code noyau (planificateur, gestion mémoire, pilotes, etc.) s’exécute au même niveau de privilège. Asterinas, lui, adopte l’architecture framekernel décrite plus haut : il se divise en un cadre minimal privilégié et des services noyau en Rust sûr. Cette conception apporte une sécurité renforcée – par exemple, un pilote de périphérique qui plante sur Asterinas a peu de chances d’affecter autre chose que lui-même, alors que sous Linux, un bug dans un module kernel peut corrompre n’importe quelle structure du noyau et mettre le système à terre. En contrepartie, Asterinas doit reconstruire tout un écosystème de pilotes et de composants que Linux a accumulé depuis des décennies. Il ne peut pas réutiliser directement le code de Linux (pour des raisons à la fois techniques et de philosophie de sûreté). Cela inclut les pilotes matériels : comme mentionné, les modules Linux existants ne sont pas compatibles. À court terme, Asterinas souffre donc d’un retard fonctionnel par rapport à Linux – tant en couverture de matériel qu’en services noyau disponibles – qu’il faudra combler pour espérer rivaliser dans des usages généraux.

En matière de performances, les concepteurs d’Asterinas ont affiché des résultats encourageants. Malgré ses abstractions de haut niveau et sa couche d’isolation interne, Asterinas obtient des performances comparables à Linux sur les appels système implémentés jusqu’à présent. Le fait de rester en monolithique (une seule adresse spatiale) lui évite l’essentiel des surcoûts habituels des micro-noyaux. De plus, le code Rust compilé en mode release s’approche en efficacité du C natif, et l’absence de ramasse-miettes signifie qu’il n’y a pas de pause imprévisible due au langage. Bien sûr, il faudra confirmer ces performances sur des scénarios plus complexes (réseau intensif, concurrence de nombreuses tâches, etc.) quand Asterinas sera plus mature, mais aucun goulot d’étranglement fondamental n’a été mis en évidence à ce stade.

Un autre point de comparaison concerne la philosophie d’évolution. Asterinas est souvent mentionné aux côtés du projet Rust for Linux, mais leur approche diverge. Rust-for-Linux consiste à introduire Rust progressivement dans le noyau Linux existant (par exemple pour y écrire de nouveaux pilotes plus sûrs), en conservant l’architecture et le code historique en C. Asterinas choisit au contraire de repartir d’une feuille blanche, avec un noyau 100% Rust et un design repensé pour minimiser le TCB. En quelque sorte, Rust-for-Linux améliore un Linux déjà très riche en fonctionnalités, alors qu’Asterinas explore ce que pourrait être un OS de type Linux conçu nativement autour des principes de Rust. Les deux approches ne sont pas en compétition directe : Rust-for-Linux apporte des bénéfices immédiats à l’écosystème Linux, tandis qu’Asterinas trace une voie plus expérimentale qui pourrait inspirer le futur des noyaux.

Statut actuel du projet et feuille de route

Asterinas est pour l’instant au stade de prototype avancé en cours de développement actif. Le code source a été publié début 2024 sous licence MPL 2.0, et le projet rassemble des contributeurs issus pour la plupart du milieu académique (doctorants de SUSTech, PKU, Fudan University…) avec le soutien d’industriels (Ant Group, Intel, etc.). À ce jour, aucune version “stable” n’a été annoncée : il n’y a pas encore de publication packagée ni de distribution utilisable. Le développement se fait au fil des commits sur le dépôt GitHub, avec des étiquettes de version mais pas de release officielle ni de journal de modifications détaillé pour l’instant. Concrètement, Asterinas ne peut pas encore faire tourner d’applications complexes – seulement des programmes de test. Il démarre dans une machine virtuelle (QEMU ou sous KVM) avec un initramfs minimal et un simple programme d’initialisation. Un ticket de suivi détaillé décrit les étapes vers une première distribution exécutable : d’abord inclure un système de base (shell, quelques commandes) dans l’initramfs, puis permettre l’exécution de conteneurs Docker, etc.. Ce plan envisage même de s’appuyer sur Nix (distribution Linux innovante) pour assembler l’espace utilisateur, mais cela reste à concrétiser dans le code.

En 2025, l’équipe concentre ses efforts sur l’implémentation des fonctionnalités manquantes pour sortir Asterinas du strict périmètre expérimental. L’ajout du support complet des namespaces et cgroups Linux est une priorité pour pouvoir gérer correctement l’isolation de processus et les conteneurs sur l’OS. En parallèle, un travail est en cours sur un sous-système graphique (console framebuffer, puis serveurs d’affichage) afin de pouvoir envisager des usages desktop/hors cloud. D’ici fin 2025, l’équipe vise également à compléter le modèle de pilotes du noyau – c’est-à-dire intégrer un ensemble plus large de drivers pour que le noyau puisse tourner sur du vrai matériel x86 (et pas seulement en VM) dans des conditions proches de la production. Enfin, le portage sur l’architecture ARM (arm64) est planifié et devrait élargir encore le champ des plateformes supportées, ouvrant la voie à des expérimentations sur smartphones, Raspberry Pi, etc.

En l’état, Asterinas n’est pas prêt pour une utilisation en production. Il lui manque des composants majeurs et il n’a pas subi le baptême du feu d’une exécution prolongée sous des charges de travail réelles. Néanmoins, le concept qu’il porte a été validé par les résultats obtenus (sécurité mémoire totale, compatibilité partielle mais fonctionnelle, performances équivalentes à Linux sur les cas simples). Comme le résume un article de LWN, Asterinas est « à un stade exploratoire précoce, piloté par de jeunes chercheurs enthousiastes et sans usage pratique sérieux à ce jour, mais il mérite qu’on le suive de près ». Les prochains mois/années verront si le projet réussit à gagner en maturité et à attirer d’autres contributeurs pour enrichir son écosystème.

Conclusion

Asterinas démontre qu’il est possible de repenser un noyau d’OS moderne autour de la sécurité mémoire sans sacrifier la compatibilité ni (semble-t-il) les performances. Bien que jeune et encore en plein développement, ce projet ouvre la voie à une nouvelle génération de systèmes d’exploitation sûrs par construction. Si ses ambitions se concrétisent – notamment la vérification formelle du cœur et le support élargi du matériel – Asterinas pourrait trouver sa place dans des domaines de niche (cloud de confiance, systèmes embarqués critiques, environnements isolés) et, à minima, influencer l’évolution du noyau Linux lui-même en prouvant les bénéfices d’un design orienté Rust. Quoi qu’il en soit, Asterinas constitue d’ores et déjà un banc d’essai passionnant pour les développeurs systèmes et les chercheurs en sécurité. Le mot de la fin revient à ses créateurs : ce projet est une invitation à faire de la sûreté mémoire « le nouveau standard » des systèmes d’exploitation de demain.

Sources: