Asterinas - un nouveau projet de noyau compatible Linux

 (lwn.net)
8 points par GN⁺ 2025-06-23 | 2 commentaires | Partager sur WhatsApp
  • Nouveau noyau compatible avec l’ABI Linux écrit en Rust, qui applique une architecture de « framekernel » afin de combiner les avantages du noyau monolithique et du microkernel
  • Conçu pour encapsuler tout le code unsafe dans des bibliothèques limitées, afin que le reste des services du noyau puisse être développé avec des abstractions Rust sûres, ce qui permet d’atteindre à la fois la sûreté mémoire et une structure simple de mémoire partagée
  • Ce qui le différencie des OS Rust existants comme RedLeaf, Tock ou Rust for Linux, c’est la prise en charge de l’isolation matérielle, une vocation généraliste, une ABI compatible Linux et l’exécution d’un espace utilisateur dans divers langages
  • Vise une réduction du TCB (base de confiance informatique) et la vérification formelle (avec Verus), avec prise en charge de matériels d’exécution de confiance comme Intel TDX, et fournit séparément des frameworks de développement OS comme OSTD/OSDK
  • Encore à un stade de développement précoce : prise en charge de x86/RISC-V et implémentation de 206 appels système, avec un focus sur Docker / conteneurs / cloud, tout en expérimentant aussi des extensions desktop comme X11/Xfce

Qu’est-ce qu’Asterinas ?

  • Asterinas est un nouveau projet de noyau compatible avec l’ABI Linux, développé en Rust
  • L’architecture « framekernel » consiste à limiter le code Rust unsafe (zones non sûres en mémoire) à des bibliothèques du framework, encapsulées derrière des API sûres, tandis que le reste des services du noyau est conçu entièrement en Rust sûr
  • Le projet cherche à poursuivre simultanément la simplicité et les hautes performances d’un noyau monolithique, ainsi que la réduction du TCB (base de confiance informatique) et la sûreté d’un microkernel
  • À l’intérieur du noyau, les services fonctionnent de manière isolée dans le même espace d’adressage, et chaque service ne peut utiliser que les ressources accordées par la bibliothèque core

Explication de l’architecture framekernel

  • Le concept de framekernel a été proposé pour la première fois dans l’article « Framekernel: A Safe and Efficient Kernel Architecture via Rust-based Intra-kernel Privilege Separation »
  • Un noyau monolithique place tout le code dans un unique espace d’adressage en mode noyau, tandis qu’un microkernel n’alloue l’espace noyau qu’à un TCB minimal et délègue la plupart des fonctions à des services en mode utilisateur
  • Le framekernel encapsule sous forme de bibliothèques le code nécessitant l’usage de unsafe en Rust, tandis que les autres services du noyau sont développés avec des abstractions Rust sûres pour la mémoire
  • Chaque service s’exécute dans l’espace d’adressage du noyau, mais son accès est limité aux seules ressources explicitement fournies par les bibliothèques
  • En gardant un TCB réduit, la vérification formelle (preuve mathématique) devient plus facile, ce qui peut améliorer la fiabilité et la stabilité de l’ensemble du système
  • Il s’agit d’une approche qui combine une base de mémoire partagée (hautes performances, comme un noyau monolithique) avec une séparation interne des privilèges et la sécurité (avantages d’un microkernel)

Comparaison avec les OS Rust existants et les framekernels

  • RedLeaf : microkernel basé sur Rust, sans utilisation de l’isolation matérielle
  • Asterinas : OS généraliste, utilisant l’isolation matérielle, compatible avec l’ABI Linux, et prenant en charge l’exécution d’un espace utilisateur dans divers langages
  • Tock : cible les SoC embarqués, avec une séparation entre le cœur (unsafe autorisé) et des capsules (code sûr), sans prise en charge de l’isolation matérielle
  • Le projet Rust for Linux vise lui aussi à envelopper les interfaces du noyau dans des abstractions sûres afin de permettre l’écriture sécurisée de drivers kernel en Rust

Vérification formelle et sécurité

  • L’objectif principal de la réduction du TCB est de rendre la vérification formelle réaliste en pratique
  • Asterinas est un cas unique visant simultanément un TCB réduit et vérifiable comme seL4, la compatibilité avec l’ABI Linux et une architecture en mémoire partagée
  • En collaboration avec la société d’audit de sécurité CertiK, le projet mène des travaux de vérification formelle basés sur Verus
    • Le rapport d’évaluation de sécurité de CertiK publie les points audités du projet ainsi que les problèmes détectés

Bibliothèques et outils de développement

  • En plus du noyau lui-même, le projet fournit OSTD (framework OS Rust) et OSDK (outil de développement basé sur Cargo)
  • Principaux objectifs d’OSTD :
    • Réduire la barrière d’entrée du développement OS et poser les bases de l’innovation
    • Renforcer la sûreté mémoire des systèmes d’exploitation Rust et abstraire les API bas niveau
    • Favoriser la réutilisation de code entre projets d’OS Rust
    • Permettre de tester du nouveau code en mode utilisateur (gain de productivité)
  • Les noyaux basés sur OSD et OSTD n’ont pas besoin d’être compatibles Linux, et fournissent des API sûres de haut niveau pour le contrôle matériel x86, la mémoire virtuelle, le multiprocessing (SMP), les timers, etc.
  • Intel fait partie des sponsors, en particulier parce que cela correspond aux technologies liées à Trust Domain Extensions (TDX) et à l’isolation des machines virtuelles

État du développement et principaux sponsors

  • Première publication open source (licence MPL) au début de 2024, avec actuellement 45 contributeurs ; les principaux contributeurs viennent de SUSTech, de l’université de Pékin, de l’université Fudan et d’Ant Group
  • Prise en charge de x86 et RISC-V, 206 appels système Linux implémentés (sur 368 au total)
  • Impossible encore d’exécuter des applications, mais l’objectif est de développer une distribution initiale et la prise en charge des conteneurs (Docker), avec aussi des tentatives autour d’une distribution basée sur Nix
  • Le chargement de modules du noyau Linux n’est pas pris en charge et il n’est pas prévu de l’introduire durablement

Feuille de route

  • Les priorités à court terme sont l’élargissement à davantage d’architectures CPU et de matériels, ainsi que l’usage réel dans des environnements cloud
  • La prise en charge des périphériques Linux virtio est achevée, et le principal marché visé est le marché cloud chinois (Alibaba Cloud, Aliyun)
  • L’objectif central est de développer un host OS pour conteneurs, avec un TCB sûr et réduit, et la prise en charge des fonctions de trusted computing d’Intel
  • Même si l’objectif ressemble à celui de Rust for Linux, Rust for Linux se limite à la rustification des drivers dans un noyau existant, alors qu’Asterinas vise une refonte complète du noyau et la minimisation du TCB
  • Le projet expérimente aussi actuellement diverses directions, comme la prise en charge de X11 et Xfce, et OSTD lui-même pourrait attirer l’attention des développeurs d’OS généralistes

Différences avec Rust for Linux

  • Rust for Linux : n’introduit dans le noyau Linux existant que des drivers sûrs en Rust ; l’ensemble du noyau reste basé sur C
  • Asterinas : implémente un nouveau noyau entièrement en Rust dès le départ, limite strictement l’usage de unsafe, pousse la vérification formelle et se concentre sur les environnements cloud / conteneurs

Synthèse et perspectives

  • Asterinas tente une approche innovante en matière de sûreté mémoire, de vérification formelle et d’utilité pratique dans les environnements cloud
  • Il n’existe pas encore d’exemples d’usage réel ni de validation large par la communauté, mais le projet attire l’attention dans les domaines de la recherche OS, du cloud et de la sécurité
  • Le framework OSTD, entre autres, pourrait trouver des usages dans l’écosystème futur du développement d’OS en Rust

Résumé des principaux points des commentaires LWN sur Asterinas

  • Singularity OS et débat sur les frontières de sécurité fondées sur le langage
    • Le framekernel d’Asterinas ressemble à Singularity OS de Microsoft, mais utilise le borrow checker de Rust pour renforcer la sûreté mémoire
    • Sur l’approche consistant à protéger un système via les frontières de sécurité du langage lui-même (par ex. Rust, Java, WASM/JS), certains critiquent en disant qu’« une confiance totale est impossible et qu’en pratique on l’utilise avec des sandboxes matérielles / OS », tandis que d’autres estiment qu’« il y a des avantages pour la prévention des défauts et la vérification formelle »
    • WASM, JS ou Java font aussi l’objet de débats sur la sécurité, mais dans les services réels, les sandboxes du langage seul ne sont pas jugées suffisantes ; il est courant de les combiner avec des sandboxes matérielles ou OS
  • Tendances du développement des systèmes d’exploitation et contexte géopolitique
    • Ces dernières années, divers nouveaux projets d’OS sont apparus, signe d’un climat d’innovation dans le domaine
    • La Chine accélère le développement d’OS alternatifs à Linux en réponse aux sanctions technologiques américaines et aux risques sur la chaîne d’approvisionnement
    • Les sanctions américaines, la GPL et les débats sur la gouvernance mondiale de l’open source alimentent une discussion politique intense sur la nécessité, pour la Chine, l’Europe et d’autres régions, de bâtir des écosystèmes technologiques indépendants
    • La difficulté de maintenir un fork de Linux ou de développer un noyau entièrement nouveau, ainsi que la dépendance au savoir-faire communautaire et les barrières linguistiques, font aussi partie des sujets débattus
  • Débat sur la compatibilité Linux et le nombre d’appels système
    • Beaucoup estiment qu’« évaluer la compatibilité au nombre d’appels système Linux est inadapté »
    • Un seul appel système (ioctl, par exemple) peut couvrir une multitude d’API détaillées ; pour mesurer la compatibilité réelle, l’exécution d’applications concrètes ou des suites de tests du noyau sont plus importantes
    • Certains citent l’histoire de Linux, qui avait au départ obtenu sa compatibilité POSIX en implémentant les appels système un par un, pour dire que la prise en charge de 99 % des appels système majeurs peut déjà permettre à beaucoup de logiciels de fonctionner
  • Licence et écosystème Rust
    • Discussion autour du choix de la MPL par Asterinas : certains y voient une bonne adéquation avec l’écosystème des crates Rust et les licences modulaires
    • Une autre opinion est que la GPL n’est pas toujours optimale, et qu’en présence de sponsoring d’entreprise, une licence plus favorable aux entreprises (comme la MPL) peut se justifier
  • Dépendances du projet / sécurité
    • Des questions sont soulevées sur la sécurité d’un OS Rust qui utilise de nombreuses crates externes, ainsi que sur la nécessité d’automatiser la sécurité de la supply chain et les audits via cargo deny / vet
    • Il est aussi mentionné qu’un simple lockfile ne suffit pas à comprendre la surface réelle des dépendances, en raison notamment des dépendances transitives propres à l’écosystème Rust et des dépendances spécifiques à chaque OS
  • Inspiration technique / architectures similaires
    • Certains soulignent que le concept de framekernel ressemble à l’architecture SPIN OS développée dans les années 1990 à l’université de Washington
    • SPIN mettait lui aussi l’accent sur une forte modularité et sur le contrôle des interfaces / accès par le compilateur
  • Débat sur la composition des committers
    • Il est relevé que, parmi les 45 contributeurs, une grande partie des commits provient d’un petit nombre de doctorants
    • D’autres soulignent qu’il est erroné de considérer les contributions menées par des doctorants comme ayant peu de valeur en tant que travail de committers, et qu’un projet innovant centré sur la recherche a aussi sa légitimité
  • Débats politiques / historiques et remarques sur le hors-sujet
    • La discussion sur les OS a parfois dérivé vers des débats géopolitiques, politiques et historiques sur les États-Unis, l’Europe et la Chine, au point que des avertissements « hors-sujet » ont été émis à plusieurs reprises par l’éditeur
    • Certains utilisateurs soulignent aussi que l’écosystème open source / FOSS peut être affecté par l’évolution du contexte géopolitique
  • Divers
    • Partage d’articles académiques sur la sécurité de WASM
    • Mélange de regards positifs et critiques sur l’état actuel du développement du noyau

À lire aussi

2 commentaires

 
eususu 2025-06-24

Ce genre d’initiative me paraît vraiment très prometteur.
Je me dis qu’on finira peut-être bientôt par voir un kernel qui ne meurt pas.
 
GN⁺ 2025-06-23
Avis Hacker News

  • Je trouve l’approche intéressante et j’espère qu’elle réussira. Mais j’ai encore des doutes. Je me souviens toujours de ce que Linus avait dit à propos de ses concurrents dans une interview télé à la fin des années 90 ou au début des années 2000. Linus avait dit en substance : « Personne n’aime écrire des pilotes ; tant qu’un jeune affamé ne surgira pas comme excellent ingénieur de pilotes, on est tranquilles. » Il était donc déjà conscient à l’époque que garder l’interface des pilotes instable constituait une forme de défense. Vingt-cinq ans plus tard, les noyaux qui tournent sur du matériel virtualisé sont devenus très courants, mais les systèmes d’exploitation réellement pratiques et utilisables qui ont réussi à s’abstraire du vrai matériel restent encore très peu nombreux

    • Sur l’idée que « garder l’interface des pilotes instable est une mesure défensive », je pense qu’à l’avenir on pourrait voir émerger de jeunes chercheurs en systèmes, ou de l’IA, et que des agents IA pourraient traduire des pilotes Linux en C en pilotes Asterinas sûrs écrits en Rust. Une autre approche réaliste consiste à réutiliser directement le noyau Linux dans un environnement isolé. Par exemple, le noyau HongMeng réutilise les pilotes grâce à User-Mode Linux. Asterinas pourrait aussi adopter une stratégie similaire. Référence : https://www.usenix.org/conference/osdi24/presentation/chen-haibo

    • Je doute que Linus ait réellement voulu ou intentionnellement construit une « barrière défensive ». Ce n’est pas un fondateur de startup technologique ; à l’origine, c’était simplement un hacker noyau, et il a déjà largement de quoi vivre à vie. Interpréter l’instabilité des interfaces de pilotes internes au noyau comme une stratégie délibérée pour empêcher la concurrence me paraît être une projection excessive

    • Il y a déjà eu des précédents comme SPIN OS (Modula 3), JX OS (Java), House OS (Haskell) ou Verve. Tous implémentaient des fonctionnalités du noyau avec des langages type-safe et memory-safe. En général, l’idée consistait à cacher les opérations dangereuses derrière des appels de fonctions vérifiés, certains utilisant aussi une VM. En dehors des questions de performances ou d’adoption, les principales faiblesses sont les failles dans les abstractions, les contournements via du code unsafe, l’effondrement du modèle de sûreté à cause du compilateur/JIT, ou les défauts matériels ordinaires (par exemple les rayons cosmiques dans l’espace). Malgré cela, c’est bien plus sûr que des noyaux ou applications en langages unsafe. Pour aller plus loin, on peut recourir à l’analyse statique du code unsafe, garantir que chaque fonction unsafe respecte une interface type-safe et memory-safe, utiliser à l’intégration un compilateur qui préserve la sûreté des abstractions, voire des compilateurs certifiés par composant. La plupart des outils de productivité existent déjà ; le seul élément manquant est la « compilation entièrement sûre du point de vue des abstractions », qui fait encore l’objet de recherches, même si une vérification manuelle reste possible

    • S’il n’existe qu’une poignée de systèmes d’exploitation réellement utilisables, c’est pour une raison. Le monde du matériel regorge de « standards » d’interface, mais dans les faits le matériel réel se comporte rarement comme le standard le prévoit. Si personne ne prend le temps d’écrire du code dans les pilotes pour gérer toutes sortes de particularités et de défauts irréparables (errata), il est vraiment difficile d’obtenir de bonnes performances et un bon support sur du vrai matériel physique

    • D’un autre côté, 98 % du Linux que j’utilise tourne en environnement virtualisé. Sur desktop/laptop, je fais tourner VirtualBox en plein écran, et je n’utilise les pilotes Windows que lorsque c’est vraiment nécessaire ; sur Mac, c’est une VM headless gérée par Docker.app. Toutes les charges de production de l’entreprise tournent sur des VM AWS. Le seul matériel Linux que j’utilise chez moi est un home server, et je compte bientôt le remplacer par une VM sur un Mac mini acheté sur eBay. Donc si un noyau compatible Linux, plus sûr et aux performances comparables apparaît, le manque de pilotes ne serait pas forcément rédhibitoire aujourd’hui, car il est désormais facile de choisir une alternative

  • J’ai entendu dire que les microkernels récents avaient beaucoup amélioré leurs problèmes de performances IPC. Je ne me souviens plus exactement de l’ampleur des progrès, mais je pense que le traumatisme de l’industrie lié à Mach a été important. En regardant le site du projet, la structure semble plutôt être que seul le Framework (mode privilégié) peut utiliser du unsafe Rust, tandis que les Services (non privilégiés) n’utilisent que du Rust sûr. Il y a quelque chose qui me paraît étrange là-dedans : si du code non privilégié est unsafe, n’est-ce pas dangereux malgré tout, même s’il est non privilégié ? À l’inverse, le code unsafe qui nécessiterait vraiment une vérification pourrait être utilisé sans limite du côté privilégié ? Et côté licence, il est indiqué qu’Asterinas utilise principalement la Mozilla Public License (MPL) 2.0, avec certains composants sous des licences plus permissives. Ce n’est ni du GPL ni du BSD, ça donne l’impression d’un entre-deux

    • À propos de la question « même non privilégié, de l’unsafe reste dangereux, et il est étrange de concentrer tout le code réellement critique côté privilégié », il faut interpréter cette structure dans le contexte du framekernel. L’ensemble du framekernel en Rust s’exécute dans l’espace noyau, mais il est logiquement séparé en deux parties : un framework OS privilégié et des services OS non privilégiés. La partie privilégiée comprend du code noyau Rust sûr et unsafe ; la partie non privilégiée ne comprend que du code noyau Rust sûr. Cette politique ne concerne que du code noyau. Dans les framekernels, il n’y a pas de contrainte sur le langage des programmes utilisateur

    • Sauf erreur de ma part, les microkernels récents ont pour la plupart drastiquement amélioré les performances IPC. SeL4, par exemple, optimise l’IPC de manière très agressive, au point qu’il est bien plus rapide qu’un syscall Linux typique. Beaucoup de programmes pourraient probablement tourner plus vite sur SeL4. J’aimerais voir des données de comparaison réelles

    • Oui, les microkernels modernes ont bien amélioré le problème de l’IPC. En réalité, le problème plus fondamental est que, sur le matériel moderne, même les syscalls d’un noyau monolithique sont très lents. C’est pourquoi des interfaces comme io_uring ou virtio offrent de bonnes performances : elles traitent les requêtes et réponses via des files entre le système et l’application (ou entre l’hyperviseur et l’invité), ce qui évite les changements d’espace d’adressage. Quel que soit leur design, les systèmes d’exploitation de demain auront besoin d’un mécanisme de syscall basé sur des files. Et une fois ce choix fait, il n’y a plus vraiment de différence de performance majeure selon qu’on utilise une architecture monolithique, microkernel ou autre

    • Dans un framekernel, la séparation privileged/unprivileged ne correspond pas à une distinction noyau/espace utilisateur. L’OS entier s’exécute au niveau de privilège du noyau. En revanche, sur le plan logique, il est séparé entre le code de bibliothèque cœur (usage de unsafe autorisé, privileged) et le reste des composants du noyau (qui utilisent ces bibliothèques, mais ne peuvent pas employer directement unsafe, unprivileged). C’est probablement imposé par des vérifications statiques comme un linter. L’emploi redondant de la terminologie rend la structure facile à mal comprendre

    • Les tâches non privilégiées s’exécutent elles aussi dans le même espace mémoire que le cœur du noyau, donc il n’existe aucun moyen d’empêcher un comportement dangereux à l’exécution. Pour séparer réellement les privilèges à l’exécution, il faut une architecture microkernel. Ici, les privilèges ne sont pas implémentés au runtime mais statiquement, en interdisant le code unsafe

  • Je me demande si le concept de séparer le noyau entre un petit cœur unsafe et de gros modules sûrs est vraiment une tentative nouvelle. Je trouve le projet intéressant et prometteur, car il n’a pas la surcharge matérielle des microkernels, évite les problèmes de sûreté des noyaux monolithiques, et exploite bien la distinction safe/unsafe propre aux langages système

  • Ça me rappelle l’article Rust in Linux de Drew DeVault. On peut aussi relier la discussion HN : https://news.ycombinator.com/item?id=41404733

  • Je trouve que c’est une tentative vraiment remarquable, et le fait que l’auteur soit présent dans ce fil est encore plus impressionnant. Je me demande jusqu’à quel point c’est utilisable ; j’aimerais essayer de construire une image serveur, même dans un environnement limité

    • Asterinas est encore un noyau relativement nouveau, donc il reste beaucoup de travail avant un usage généraliste. Mais si l’objectif est de faire tourner de vrais services de production de manière efficace et fiable, l’écart n’est pas si grand, et il est possible d’atteindre cet objectif d’ici un an. Des fonctionnalités clés comme les namespaces Linux et les cgroups sont en cours d’implémentation, ainsi que la première distribution basée sur Asterinas. L’objectif initial est d’utiliser Asterinas comme OS invité pour les Confidential VMs, où sa memory safety et son petit TCB lui donnent un avantage de sécurité clair par rapport à Linux

  • En voyant l’explication selon laquelle les microkernels sont peu populaires parce que l’IPC serait lent, je suis rassuré de constater que même des gens techniquement brillants se trompent sur les raisons réelles de l’adoption et sur le processus qui y mène

    • Dans ce cas, il faudrait expliquer précisément ce qui est mal interprété ; cela serait utile à tout le monde

  • La licence est en MPL ; personnellement, je pense qu’il existe de meilleures licences (GPLv3, etc.)

    • La documentation explique directement pourquoi MPL a été choisie. Ce n’est pas mon choix préféré, mais la justification me semble compréhensible

  • Je trouve que c’est une très bonne idée. Beaucoup de logiciels existent déjà, et disposer d’une base alternative peut apporter de grands avantages ou des options, y compris pour des raisons non techniques. Ça me fait penser à kFreeBSD et GNU/Hurd

  • Je me demande comment il faudrait appeler ce type de noyaux. *nux ?