Exo-noyau — Wikipédia

Un exo-noyau ou exokernel est un type de système d’exploitation dont l'architecture logicielle est dite modulaire. En informatique, un noyau ou kernel est le premier élément codé venant exploiter les ressources matérielles de l'ordinateur. Il existe différents types de noyaux qui supportent des systèmes d’exploitations et qui fournissent des mécanismes d’abstraction du matériel tel que la mémoire, le (ou les) processeur(s), le réseau informatique ou les différents périphériques matériels. Le noyau facilite également la communication entre les processus grâce à diverses abstractions logicielles.

Contrairement aux noyaux dit monolithiques, l'exo-noyau et son architecture ont une approche plus radicale. ἔξω (éxo) signifie en grec ancien « hors de » : un exo-noyau est donc un système fonctionnant dans l’espace utilisateur et non dans l’espace noyau. La philosophie de l'exo-noyau est : l’élimination de toute abstraction d'un système d'exploitation pour que l'utilisateur soit au plus près du matériel. C'est en 1995 qu'une équipe du MIT (Massachusetts Institute of Technology) commence son étude et le développement de ce type de noyau ; initiant en même temps de vifs débats avec les tenants des noyaux monolithiques. La philosophie et les principes définis pour ce projet ont modifié la vision de la performance, la gestion des ressources matérielles et la sécurité au sein d'un système d’exploitation. Les instanciations et l'utilisation de l'exo-noyau ainsi que des outils et applications spécifiques n'ont cessé de se multiplier et d'évoluer depuis sa genèse.

Les problèmes qu’apportent l'abstraction des ressources matérielles d'un système monolithique sont les suivants^[1],[2] :

Manque de fiabilité

À cause d'un code lourd et des mécanismes complexes, la performance d'un système dit monolithique est dégradée.

Manque d’adaptabilité

Le code dense empêche une évolution simplifiée. D'autre part, les applications dépendant fortement d'un système d'exploitation, celles-ci sont difficilement adaptables au détriment des autres.

Performance en retrait

À cause des abstractions matérielles excessives, les programmes se trouvent loin des ressources et les applications n'utilisant pas ces abstractions en pâtissent. L'OS unique cherche à faire un compromis pénalisant une application au détriment d'une autre.

Manque de flexibilité

Si les applications pouvaient passer outre au système d'exploitation et implémenter leurs propres abstractions, leur flexibilité serait acceptable. Il n'en est rien car cette méthode serait trop coûteuse, compliquée et mal à propos selon la philosophie d'un système monolithique.

De ce fait, les applications ne pouvant pas faire abstraction de la couche OS, l'ensemble est lent, inflexible et instable.

Les buts de l'exo-noyau sont clairement établis^[3],[4],[5] :

• Donner aux utilisateurs un système au code léger et simple pour que les performances soient au rendez-vous;
• Permettre aux développeurs de disposer d'un environnement propice aux évolutions;
• Rapprocher les applications au maximum de la couche matérielle pour optimiser les performances;
• Permettre aux programmes de définir eux-mêmes leurs abstractions matérielles.

La philosophie et les principes de l'exo-noyau sont établis par l'équipe du MIT^{[note 1]} (Massachusetts Institute of Technology) travaillant sur son étude et son développement. Ceux-ci sont repris et mis en œuvre au sein de son architecture modulaire^[6] :

Séparation de la sécurité (protection) et de la gestion des ressources

L'exo-noyau limite la gestion des ressources à des fonctions nécessaires à la sécurité : allocation, révocation, partage et droits. Les applications ayant accès à l’ensemble des mécanismes du système, sauf la sécurité, l'évolutivité du noyau est optimisé^{[7],[8],[9],[6],[10],[11]}.

Exposition du matériel

Les applications ont accès à l'ensemble des ressources matérielles en empruntant des liens sécurisés. Elles ont une vue complète des paramètres du matériel. Le niveau d'accès est le plus bas qu'on puisse donner de manière sécurisée^[11],[10].

Exposition de l'allocation

L'exo-noyau permet aux applications de solliciter le matériel durant la phase d'allocation en leur donnant le contrôle du niveau d'abstraction et de performance^[11],[4].

Exposition de l’acquittement

L'exo-noyau donne aux applications l'accès aux règles et politiques d'acquittement. Le contrôle de la libération des ressources est total^{[11],[4],[12],[13]}.

Une protection au niveau le plus bas

Pour alléger efficacement la gestion et le partage des ressources, l'exo-noyau place son niveau d'action le plus bas possible. Exemple d'un disque-dur : l'accès est donné au niveau des blocs (gestion en mode bloc) du disque au lieu des partitions car celles-ci constituent déjà une abstraction de haut-niveau^[11].

Exposition des noms

L'exo-noyau utilise au maximum le nom physique des ressources. L'utilisation d'alias ou d'éléments virtuels alourdit les processus et coûte du temps^[11],[14].

Exposition de l'information

L'exo-noyau expose toutes les informations du niveau matériel aux applications. Les programmes ont donc une vue parfaite des ressources utilisées ou libres. Les noyaux monolithiques ne montrent qu'une partie de l'information ou de manière déguisée, ce qui nuit à la souplesse et la performance^{[11],[15],[5]}.

Dans les années 1990, certains chercheurs du MIT^{[note 1]} (Massachusetts Institute of Technology) se sont penchés sur les systèmes d'exploitations monolithiques actuels qui, selon eux, soulèvent plusieurs problèmes de conception dus à la volonté d'abstraction des ressources physiques d'un ordinateur. Le résultat de cette approche : une performance, une adaptabilité et une flexibilité qui sont en retraits^[1].

La solution : l’élimination complète des abstractions engendrées par un système d'exploitation^[16]!

C'est ainsi que Dawson Engler^{[note 2]} et Frans Kaashoek^{[note 3]} ont entrepris d'étudier et de développer un nouveau type de noyau informatique exposant la partie matérielle d'un système (non sans sécurités...) afin d’obtenir le but recherché : un système fonctionnant en espace utilisateur ayant une adaptabilité accrue, une meilleure efficacité et une flexibilité d'utilisation des applications pour tendre à plus de performance^[3].

L'exo-noyau ou exokernel a vu le jour à la suite du concept établi par ses pères fondateurs cités précédemment^[17],[7].

De la simple étude au développement de leurs exo-noyaux, l'équipe du MIT a défini un nouveau standard qui va être suivi et repris par de nombreux autres chercheurs, développeurs et projets afin de s'adapter aux nouveaux besoins et aux technologies récentes^{[18],[19],[20],[21],[22]}.

Dès le début, le challenge de l'exo-noyau était de prouver que ses qualités lui permettait de tenir tête aux autres systèmes dits monolithiques, aussi performants soient-ils^[1]. En effet, d'après des tests effectués en laboratoire (MIT), un des premiers prototypes d'exo-noyau donnait des résultats remarquables : face à Ultrix qui est un système monolithique mature UNIX, l'exo-noyau était 100 fois plus rapide que son concurrent en exécutant la plupart des primitives du noyau^[7]. Il a alors été prouvé que de par son architecture, le système monolithique était inapproprié pour plusieurs raisons : l’inefficacité de la gestion des ressources matérielles et l'inflexibilité de modification du code qui amène au découragement. Grâce à son architecture différente et sa façon de multiplexer de manière sécurisée les ressources mises à sa disposition, l'exo-noyau définit une nouvelle vision architecturale : il utilise plusieurs mécanismes qui permettent de s'abroger d'un système d'exploitation^[8],[9].

De nombreux tests de performances ou benchmark ont été effectués pour prouver le gain de performances^{[23],[24],[25],[26],[27],[28],[29],[30],[31],[32]}.

1995

Le concept de l'exo-noyau était clair : abolir le problème des systèmes monolithiques en terme d'abstractions des ressources physiques et permettre aux développeurs d'être au plus près du matériel. Flexibilité et adaptabilité sont les maîtres mots^[33]. Le premier exo-noyau développé par l'équipe du MIT^{[note 1]} était dédié au processeur x86 en version 32 bits : « Xok » reste le noyau modulaire développé par l'équipe de Dawson Engler^{[note 2]} et Frans Kaashoek^{[note 3]} le plus connu et le plus utilisé. La distribution communément employée est « Xok/ExOS »^{[note 4],[8],[9],[6],[34],[35],[36]}. En parallèle de « Xok », l'équipe du MIT a développé « Aegis » qui est un noyau dédié à l'architecture MIPS^{[37],[9],[35]}.

1996

Le MIT développe « Glaze » : exo-noyau expérimental dédié à l'architecture « FUGU » multiprocesseur^[9].

2000

« Xok » a été utilisé par une autre équipe américaine pour développer des bibliothèques et des applications en environnement multithreading pour des besoins plus évolués^[38],[39]. « SMP-Xok » a alors vu le jour dans la même période : exo-noyau dédié à l'architecture x86 32 bits multiprocesseur^[20]. De par sa simplicité et sa légèreté de code, l'exo-noyau intéresse le domaine universitaire : « Nemesis »^{[note 5]}, noyau d'étude, a vu le jour à l'université de Cambridge^{[note 6]}. Ce noyau a pour avantage d'être implémenté pour de nombreuses plateformes : x86, RISC 64 bits et StrongARM^[40].

2003

Un groupe de chercheurs de l'université des sciences et technologies de Lille^{[note 7]}, se penchent sur le sujet de l'exo-noyau embarqué (encarté) temps réel : « Camille »^[18] puis « Camille RT »^[19] (version temps réel) est destiné aux systèmes RISC et CISC.

2010

Un groupe de chercheurs américains a développé l'exo-noyau « XomB »^{[note 8]} dédié à l'architecture x86 64 bits multiprocesseur^[21].

Depuis 2013

Le projet Xen développe l'exo-noyau « Mirage »^{[note 9]} (x86) dédié au cloud computing^[22],[40].

L'exo-noyau est spécifique au type de processeur (se reporter à Inventaire des exo-noyaux pour plus d'informations). Quel que soit le type du système, le noyau protège, multiplexe et partage équitablement les ressources physiques de manière dédiée^[42]. Son code est léger et se veut ouvert, modifiable et adaptable^{[43],[44],[45]}. Au sein d'un système exo-noyau, la notion importante de la séparation de la protection et de la gestion des ressources s'applique comme suit : le noyau protège les ressources matérielles mais délègue le rôle de la gestion de celles-ci aux bibliothèques et applications^[44],[46].

Chargement de code

Une des propriétés importantes de l'exo-noyau et qui est utilisée par un système monolithique est le chargement de code (downloading code).

Ce mécanisme permet une souplesse d’adaptation et autorise le noyau à être flexible en fonction de son environnement^{[47],[1],[48]}. Le noyau peut demander du chargement direct de code pour un contrôle ou lorsqu'il a un doute sur une application : intégrité, sécurité, etc^[49]...

Une application de cette technologie : Dynamic Packet Filter (DPF), le filtre dynamique de paquets programmable (pare-feu) implémenté par l'exo-noyau^{[50],[51],[52],[53],[54]}. « DPF » utilise de la génération dynamique de code et filtre + démultiplexe les paquets reçus avant de les faire parvenir à la couche supérieure^[55]. Le mécanisme « ASH » (Application-Specific Safe Handlers) est associé au « DPF » pour la partie notification aux applications. Il utilise également du code chargé lors de l'arrivée d'un flux réseau^[56],[57].

Multiplexage des ressources

Le multiplexage des ressources permet à l'exo-noyau d'être souple et performant. En multiplexant les ressources du processeur, de la mémoire, du stockage et du réseau, plusieurs applications ont accès à celles-ci parallèlement et de manière équitable^[58],[47]. Le détail de ce mécanisme est développé dans Les ressources et leur gestion.

Les liens sécurisés (Secure Bindings)

Pour que les bibliothèques du système puissent dialoguer avec la couche matérielle de manière sûre, l'exo-noyau utilise des liens sécurisés (Secure Bindings)^[59],[5]. La mise en place de ce système introduit la notion de sécurité développée dans Sécurité.

L'exo-noyau n'utilise pas de système d'exploitation ou operating system (OS) pour dialoguer avec les applications. Un système d'exploitation unique n'est pas assez souple pour faire fonctionner de manière optimale tous les programmes qui forment la couche de plus haut niveau : il introduit trop de mécanismes et de notions d'abstraction pour atteindre les ressources physiques mises à disposition. Les bibliothèques OS ou « LibOS » (LibOSes au pluriel) éliminent les services d'un OS standard. Une LibOS est l'interface entre un programme et le noyau : elle intègre un code léger modifiable à souhait^[60],[47]. Une LibOS n'a pas de notion de privilège(s) comme l'aurait un OS standard. Cette propriété allège son code de manière considérable. Les sollicitations des ressources matérielles sont effectuées par la LibOS ou directement par les applications et non l'exo-noyau qui ne fait que relayer et enregistrer l'information pour la gestion de la mémoire, CPU, réseau, etc.^[61],[62] En utilisant autant de LibOSes différentes que d'applications, le développeur peut modifier son application et/ou la LibOS de manière indépendante et n'intervient pas sur le fonctionnement d'une autre application. Cette manière de procéder est un élément de sécurité remarquable^[8],[63]. Chaque LibOS peut utiliser la couche matérielle sans se préoccuper d'une autre bibliothèque pour un accès disque, réseau ou CPU grâce au multiplexage des ressources^[5],[41].

Il existe des LibOSes spécifiques :

• Pour la gestion du stockage : une « LibFS » (LibFSes au pluriel)^{[64],[65],[28]};
• Pour la gestion du réseau : une LibOS dédiée à la ressource réseau^[4],[41].

Une LibFS ou une bibliothèque réseau peut être indépendante ou être intégrée à une LibOS. Lorsqu'une de ces bibliothèques est intégrée à une LibOS, celles-ci peuvent être uniques ou multiples au sein de la même LibOS^{[28],[66],[67]}. L'exo-noyau fournit aux LibOSes un certain nombre de mécanismes pour garantir son utilisation et celle du matériel au plus bas niveau incluant un niveau d'abstraction minimal^[23]. Comme vu, les LibOSes n'intègrent pas de notion de privilège(s) mais sont aussi puissantes qu'un système d'exploitation standard grâce au travail de l'exo-noyau^[68].

Exemples de LibOS :

ExOS

LibOS dédiée à l'exo-kernel « Xok » (architecture x86) et spécialisée dans l’exécution d'applications UNIX non modifiées (POSIX)^[34],[36].

Xok-CThreads

LibOS dédiée à l'exo-kernel « Xok » et spécialisée dans l'exécution d'applications en environnement multithreading^[38],[39].

libAMP

LibOS dédiée à l'exo-kernel « Xok » et faisant fonctionner l'interface d'un routeur actif^[69],[70].

VOS

LibOS dédiée à l'exo-kernel « SMP-Xok » (architecture x86 - multiprocesseurs) pour faire fonctionner des applications en environnement multiprocesseur^[71].

La plupart des applications tournant sur un système exo-noyau ne dialoguent pas avec le noyau mais seulement avec leur LibOS. En général, ces programmes offrent une meilleure performance que sur un système monolithique grâce aux propriétés spécifiques du noyau^[72]. Les applications ont le rôle de gestion des ressources matérielles. De ce fait, les programmes ont accès à leurs ressources à un niveau d'abstraction extrêmement bas (voir nul) et l'exo-noyau surveille cette utilisation : les développeurs peuvent donc écrire du code applicatif sans se soucier des abstractions matérielles, ce qui implique que les applications doivent importer ou construire elles-mêmes les abstractions dont elles ont besoin^[73]. Pour garder les propriétés des LibOSes au niveau de la légèreté et l'adaptabilité du code, la couche applicative n'intègre pas de notion de privilège(s) car la gestion de la sécurité n'est pas leur rôle^[44].

Sur un système d'exploitation standard, seules les applications ayant les privilèges ou le noyau ont le droit de gérer les ressources. Au sein d'un système exo-noyau, seules les applications ou les LibOSes gèrent les ressources sans notion de privilège en séparant la gestion de ces dernières de leur protection et de leur multiplexage, qui est laissé à la charge du noyau. En conséquence, dans un système exo-noyau, les applications gèrent leurs propres abstractions de la mémoire virtuelle, la gestion d'un système de fichiers et la gestion du réseau^[74]. L'exo-noyau exporte les ressources matérielles au lieu de les émuler, ce qui apporte un gain indéniable en performance et en adaptabilité du code^{[4],[75],[40]}. L'exo-noyau utilise trois techniques pour exporter les ressources^[5] :

• En utilisant des liens sécurisés gérés par le noyau (Secure Bindings) entre le matériel et les LibOSes;
• En acquittant l'utilisation des ressources de manière ouverte et visible : ainsi, toute application est au courant de l'action et peut profiter de la ressource de manière optimisée;
• En donnant la possibilité au noyau de briser tout lien sécurisé vers une ressource lorsqu'une application devient un point individuel de défaillance ou SPOF (Single point of failure)^[49].

Le partage des ressources, géré au niveau LibOS et applicatif, fonctionne grâce à la communication inter-processus (IPC ou Inter Process Call ). Ce mécanisme basé sur l'utilisation de pointeurs sur les ressources, permet de vérifier si celles-ci sont disponibles. Un processus de sécurité gère les demandes et utilisations frauduleuses de la couche matérielle^[76].

L'exo-noyau informe les applications des événements processeur : les interruptions, les exceptions, le début et la fin d'un quantum de temps^[49],[77]. La ressource CPU utilise une pile à accès multiples, de telle manière qu'un programme peut accéder à la liste circulaire en parallèle d'un autre^{[78],[79],[80]}. Cette pile des processus est ouverte et accessible en lecture / écriture par toute LibOS. Grâce à cela, tout programme a la vision de la file en cours et peut utiliser la ressource CPU de manière équitable^[79]. Un mécanisme permet également à un programme de donner de la ressource processeur à un autre^[19]. L'acquittement de la ressource CPU est explicite. Les processus ont donc l’opportunité de modifier leur contexte à la fin d'un quantum de temps^[13]. La particularité de la ressource CPU par rapport à un système classique est la gestion des processus : ceux-ci sont informés de leur niveau d'accès au processeur et peuvent donc réagir en conséquence; demander plus de ressource CPU ou non. De même, lorsqu'un processus prend trop de temps d’exécution, celui-ci se voit pénalisé par un plus faible niveau d'accès. Dans le cas extrême, il est tué^[5].

Au sein du processeur, l'ordonnanceur ne tient pas compte des exceptions sur les périphériques d'entrée / sortie. Seule exception à la règle : la demande explicite d'une application^[81].

En environnement temps réel, pour chaque quantum de temps CPU, le noyau utilise une politique de round-robin pour élire une application^[82]. En environnement temps réel et multiprocesseur, la communication inter-processus est essentielle à la performance des composants du système tel que les systèmes de fichiers et la gestion des processus. De ce fait, l'IPC (Inter-process communication) doit avoir le niveau de priorité le plus élevé du point de vue programmation, ce qui permet d’alléger les tâches de l'exo-noyau^[83]. Enfin, l'exo-noyau est responsable de la cohérence des TLB ou Translation Lookaside Buffers des processeurs entre eux lorsqu'ils sont plusieurs^[84].

La mémoire physique est la ressource la plus simple à multiplexer^[43]. Quand une LibOS demande l'allocation d'une page mémoire physique, l'exo-noyau crée un lien sécurisé vers une page en enregistrant l'identifiant du client et les droits de lecture / écriture dans le cache de la mémoire vive puis alloue l'espace physique à l'application. Les priorités de ces liens sécurisés sont l'auto-authentification et la translation d'adresse. En parallèle, le noyau gère un large espace TLB (Translation Lookaside Buffer) logiciel pour permettre cette translation d'adresse. Le client de l'espace mémoire a la possibilité de modifier ses droits et de libérer la ressource^[49],[43]. Les LibOSes ont un accès réservé à leur mémoire grâce à l'exo-noyau qui garantit la ressource. Dès que le noyau décèle une anomalie, il fait remonter l'information à la LibOS affectée^[28].

Une LibOS fournit un système rudimentaire de mémoire virtuelle : il fournit un support flexible pour l'aliasing, le partage, l'allocation et la libération de la ressource mémoire ainsi que l'accès direct à la mémoire^[56],[85]. L'accès direct de cette mémoire virtuelle à la mémoire physique se fait sous contrôle du MMU (unité de gestion mémoire)^[86]. Chaque processus tournant sur un système exo-noyau gère son propre identifiant en mémoire virtuelle qui pointe vers une ressource mémoire physique^[76].

L'exo-noyau possède trois mécanismes pour multiplexer la mémoire principale^[87] :

• Chaque processus possède sa propre table en mémoire virtuelle qui contient ses droits et sa plage d'accès à la mémoire physique;
• Les droits d'accès à la ressource mémoire sont donnés quand un processus veut allouer un espace physique libre;
• Les droits d'accès à la ressource mémoire sont donnés à un processus lorsqu'un autre processus lui donne ses droits ou une partie.

Les applications et les LibOSes ont un accès direct au disque dur et au niveau des blocs de celui-ci. Elles gèrent entièrement l'accès à la ressource stockage sous le contrôle de l'exo-noyau pour la sécurité et la gestion des conflits^[48]. En termes de pilote disque intégré à une LibOS, le MIT^{[note 1]} a tout d'abord repris l'existant de la distribution FreeBSD et l'a adapté à l'exo-noyau : le support UltraDMA IDE de cet OS reprend la philosophie et les attentes de l'exo-noyau en termes d'accès direct à la ressource^[88]. Pour garantir le multiplexage de la ressource disque en toute sécurité et permettre aux applications d'utiliser plusieurs systèmes de fichiers, le modèle exo-noyau possède des LibOSes dédiées : les LibFSes (LibFS au singulier). Chaque LibFS traduit un système de fichiers. Les LibFSes peuvent être multiples au sein d'une LibOS ou d'un système modulaire exo-noyau^[67]. Le rôle de l'exo-noyau est de donner le maximum de contrôle à la LibFS pour la gestion du système de fichiers tout en protégeant l'accès aux données^[28]. Pour fournir la protection nécessaire, le noyau doit faire en sorte que chaque LibFS n'accède qu'aux blocs qui lui sont alloués. Pour être flexible et rapide, l'exo-noyau applique sa protection au niveau du bloc de disque plutôt que de la partition^[64]. Pour permettre aux LibFSes d’exécuter leur propre gestion de système de fichiers et fournir la stabilité nécessaire, quatre points sont à satisfaire^[66] :

• L'utilisation des systèmes de fichiers doit être simple et légère. Aucune notion de privilège n'est autorisée pour ne pas alourdir le code et interférer avec le rôle du noyau au niveau de la sécurité;
• Plusieurs LibFSes doivent pouvoir partager en toute sécurité les données au niveau des blocs du disque et des métadonnées;
• Le(s) disque(s) utilisé(s) doit être aussi performant que l'exige le système de fichiers;
• Le système de stockage doit faciliter le partage de sa mémoire cache entre les LibFSes et le traitement simple des problèmes de cohérence et de sécurité.

Le système de fichier natif utilisé par le noyau « Xok » est « XN » qui est défini pour un accès en mode bloc^{[89],[90],[91]}.

Un exemple de LibFS pour les applications UNIX : « C-FFS » permet l'accès aux systèmes de fichiers du monde POSIX et étend les fonctionnalités de « XN » en matière de rapidité grâce à l'utilisation de chargement de code dans le noyau^[65],[28].

La couche applicative du modèle exo-noyau a un accès direct à l'interface réseau : elle a la gestion de la ressource réseau sans interaction avec une autre couche ce qui induit une meilleure performance. Le noyau intervient seulement au niveau de la sécurité et dispose d'une pile FIFO (First in, first out) pour la redirection des paquets en entrée / sortie. Lors de la réception de paquets, l'exo-noyau copie ceux-ci dans un espace mémoire dédié pour que l'application puisse les récupérer à l'adresse indiquée : c'est ainsi que le noyau démultiplexe les données entrantes^[48],[92]. Lors de la récupération des données en provenance du réseau et avant la mise à disposition aux LibOSes, le noyau utilise un filtre dynamique de paquets « DPF » (Dynamique Packet Filter - pare-feu) programmable pour sécuriser son système^{[49],[50],[51],[52],[53],[54]}. Celui-ci participe donc activement au processus de démultiplexage des paquets entrants^[55]. Associée au « DPF », l'utilisation du « ASH » (Application-specific Safe Handlers) participe à la sécurité du système à l'arrivée d'un flux réseau : ce mécanisme notifie les LibOSes et/ou les applications par message(s) lors d'un problème détecté par le pare-feu « DPF »^[56],[57]. Pour une gestion plus efficace de la ressource réseau, le système exo-noyau peut utiliser une (ou des) « LibOS(es) » dédiée(s) au(x) réseau(x). Celle-ci peut être intégrée à la « LibOS » ou non^[41],[4].

Conformément à la philosophie de l'exo-noyau en termes d'exposition des ressources et de l'information, la solution « Xok/ExOS » implémente un accès direct au cache ARP (table ARP) du système pour les applications sous le contrôle d'un pare-feu « DPF »^[93].

En 2002, une équipe du MIT^{[note 1]} s'est intéressée à un pilote réseau utilisé par le framework « OSKit »^{[note 10]}. Celui-ci permet l'utilisation d'un certain nombre de cartes réseaux comme les modèles de 3Com ou Intel et a donc été repris et adapté pour les besoins de l'exo-noyau « Xok »^[88]. À la même période, cette équipe a également étudié le problème des multiples protocoles réseaux existants et la manière d'en implémenter. Grâce à leur langage de programmation « Prolac » inventé spécialement à cet effet, le MIT a développé son propre prototype du protocole TCP (Transmission Control Protocol) reprenant la philosophie de l'exo-noyau en termes d'architecture modulaire^[94]. En parallèle de son projet de serveur World Wide Web « Cheetah », le MIT a développé une application orientée réseau : un TCP Forwarder pour la distribution « Xok/ExOS » qui permet de faire du TCP Tunneling^[95].

Grâce à son étude sur les mécanismes réseaux implémentés au sein du modèle exo-noyau, le MIT espère faire avancer la recherche en termes de multiplexage des cartes réseaux sur un système informatique^[96].

Dans le domaine des cartes à puce, l'étude de l'utilisation de l'exo-noyau embarqué (encarté) a été menée par une équipe de chercheurs de l'université des sciences et technologies de Lille^{[note 7],[97]}. Le but de cette étude était de concevoir un système modulaire adapté à une carte à puce en reprenant le concept du MIT^{[note 1]} en termes d'absence d'abstraction matérielle et en apportant un accès sécurisé et (dé)multiplexé aux ressources physiques^[98]. La première étude fut menée sur l'exo-noyau « Camille »^[18]. Le but est de supporter les différentes ressources matérielles utilisées dans les cartes. Les caractéristiques de cet exo-noyau : la portabilité, la sécurité et l'extensibilité^[73].

La seconde étude portait sur l'exo-noyau « Camille RT » qui reprend le principe du premier mais qui introduit la notion du temps réel. « Camille RT » est conçu pour faire cohabiter les applications standards avec les applications temps réel. L'architecture première de l'exo-noyau du MIT n'apporte pas de primitives temps réel et « Camille RT » pallie ce problème avec l'utilisation d'un ordonnanceur temps réel conçu pour cette architecture modulaire^[19]. Afin d'arriver au résultat attendu, l'étude du temps d’exécution de chaque primitive de l'exo-noyau et l'analyse du noyau temps réel RTEMS ont été nécessaires^[99]. Le but de cette étude était également de se pencher sur le calcul du temps d’exécution au pire cas (WCET) et de faire avancer les recherches dans ce domaine^[100].

Les implémentations de l'exo-noyau en environnement serveur sont multiples. En partant du simple noyau x86 32 bits comme « Xok »^{[8],[9],[6],[34],[35],[36]} pour arriver à « XomB » dédié à l'architecture x86 64 bits multiprocesseur^[21], chacun d'entre eux est capable de faire fonctionner des applications non modifiées grâce à une LibOS dédiée^[8],[63].

L'exo-noyau le plus étudié et le plus utilisé en environnement serveur reste « Xok » développé par le MIT^{[note 1]} (Massachusetts Institute of Technology). La LibOS ExOS^[34],[36] dédiée à « Xok » et faisant fonctionner des programmes UNIX non modifiés a mené à la distribution « EXOPC » (« Xok/ExOS »)^{[note 4]}. Cette solution utilise communément UDP/IP, TCP/IP et les sockets POSIX et est la plateforme standard pour faire fonctionner des applications serveurs de type HTTP en parallèle d'autres applications^[101]. De nombreux tests d'applications standards UNIX ont alors été effectués en environnement modulaire exo-noyau^[8]. À la vue des propriétés de ce système en matière de rapidité, d'accès aux ressources et d'adaptabilité, le MIT a développé un serveur web rapide et léger : « Cheetah »^{[9],[102],[103]}. L'avantage indéniable concernant « Xok/ExOS » faisant fonctionner « Cheetah » est la rapidité de chargement et d’exécution. Des tests prouvent que cette plateforme est plus rapide que ses concurrents lors de benchmarks : temps de chargement (en secondes) en fonction de la taille de la page HTTP^[104]. En parallèle du développement de leur serveur World Wide Web, le MIT s'est penché sur l'implémentation d'une bibliothèque d'entrées / sorties extensible qu'utilise « Cheetah » : « XIO ». Cette bibliothèque doit simplifier le développement de serveurs HTTP à hautes performances^[105].

L'équipement réseau utilise l'exo-noyau dans le monde des routeurs actifs. C'est en 2001 que le projet 'AMP' utilise l'exo-noyau du MIT^{[note 1]} « Xok »^{[8],[9],[6],[34],[35],[36]} puis la distribution 'EXOPC' « Xok/ExOS »^{[note 4],[106]} pour faire fonctionner leur interface pour routeur actif : « NodeOS »^[107]. En utilisant le framework « OSKit »^{[note 10]} pour la création de leur applicatif, l'équipe du projet a développé une LibOS destinée à l'exo-noyau du MIT : « libAMP »^[70]. Profitant de l'architecture propice à l'utilisation du matériel à bas niveau, du multiplexage des ressources, de l'adaptabilité du code et des mécanismes de protections, « Xok/libAMP » apparait comme une solution performante, sûre et efficace^{[108],[69],[106]}. Le routeur actif utilisant ce système profite d'une gestion des paquets réseaux à très bas niveau grâce à l'absence d'abstraction matérielle qu'offre l'exo-noyau. L'utilisation du framework « THINK »^{[note 11]} et ses fonctionnalités ont complété la solution « OSKit » en 2002 pour le développement du système supportant l'interface « NodeOS »^[109].

Le projet Xen a débuté en 2013 le développement d'un exo-noyau orienté vers le cloud computing^[22]. Mirage^{[note 9]} est un exo-noyau basé sur l'architecture x86 et est destiné à faire fonctionner des applications orientées réseau qui sont sécurisées et de haute performance dans le cloud^[22]. La distribution appelée « Mirage OS » est basée sur l'étude de l'exo-noyau « Nemesis »^{[note 5]} et utilise les hyperviseurs Xen avec la philosophie et les principes de l'exo-noyau : la création d'applications rapides, flexibles et adaptables en étant au plus près du matériel sans avoir à gérer les milliers de pilotes de périphériques que l'on trouve dans un système d'exploitation standard. Une des utilisations les plus connues de « Mirage OS » est la solution « Amazon EC2 »^{[note 12],[22]}.

Dès le début de l’histoire de l’exo-noyau avec la conception de leur premier prototype, le MIT^{[note 1]} (Massachusetts Institute of Technology) a prouvé que l’architecture de son modèle modulaire était bien plus rapide que n’importe quel système monolithique . Les premiers tests ont révélé des résultats remarquables : l’exécution de la plupart des primitives de leur noyau était 100 fois plus rapide comparé à Ultrix qui est un système monolithique UNIX mature^[7],[77]. L’exemple de « Aegis », une des premières études exo-noyau basé sur l’architecture MIPS a montré qu’une simple commande UNIX « getpid » coutait beaucoup plus de temps à un système monolithique de par ses abstractions matérielles^[77]. Grâce à différentes études et tests, la preuve était faite que l’exo-noyau était plus performant, plus flexible et offrait plus de possibilités en rapport avec son architecture^[72]. En exposant ses données et en laissant la couche applicative gérer les ressources matérielles pour un maximum de contrôle, l’exo-noyau peut se concentrer sur la protection de son système : ce mécanisme est un des points favorisant la performance globale^[110],[111]. L’exo-noyau est un système flexible et adaptable et ne pâtit pas de ces fonctionnalités pour être rapide. Les applications légères et dynamiques tel que le serveur HTTP « Cheetah » du MIT donnent les résultats les plus significatifs^[31]. Le chargement de code au sein de l'exo-noyau est orienté performance sur deux points^[49],[48] :

• Cela permet aux applications de ne pas constamment faire appel au noyau qui exécute du code chargé lors d'actions spécifiques;
• Cela permet au noyau de faire abstraction des programmes en exécutant du code chargé sans attendre une demande applicative.

Le pare-feu qu'utilise l'exo-noyau emploie un système de notifications pour les applications : le ASH (Application-Specific Safe Handlers). Ce mécanisme permet au système d'être plus performant grâce à une couche applicative informée des événements réseaux^[112].

L'exo-noyau du MIT « Xok »^{[8],[9],[6],[34],[35],[36]} et plus particulièrement la distribution « EXOPC » (« Xok/ExOS »)^{[note 4]} ont fait l’œuvre de nombreux tests et comparatifs :

Performance globale de « Xok/ExOS » face à FreeBSD

Face à FreeBSD, système monolithique connu pour une très bonne performance globale, « Xok/ExOS » arrive en tête. Quel que soit le nombre de processus fonctionnant et/ou lancés simultanément, la solution exo-noyau offre le meilleur résultat global^[23],[111].

« Xok » et la performance des applications UNIX non modifiées grâce à la LibOS « ExOS »

Face à ses concurrents open source les plus rapides qui sont OpenBSD et FreeBSD, « Xok/ExOS » arrive en tête lors de l’exécution de nombreux programmes UNIX non modifiés. OpenBSD n'utilisant pas la LibFS « C-FFS » est même moins rapide qu'en l'utilisant^{[25],[26],[24],[27],[28]}.

La performance de « Cheetah » fonctionnant avec le noyau « Xok »

« Cheetah » est le serveur HTTP rapide et léger du MIT. Ce serveur passe directement par le noyau sans opération du processeur grâce à un mécanisme de stockage des données en mémoire cache^[32]. Les résultats de « Cheetah/Xok » en nombre de requêtes par seconde en fonction de la taille d'une page HTTP sont remarquables par rapport à ses concurrents les plus rapides^[29],[30]. Plusieurs solutions sont mises en œuvre pour démontrer cette performance :

• Cheetah/Xok = Serveur HTTP « Cheetah » + exo-noyau « Xok » + bibliothèque entrée/sortie « XIO » optimisée + TCP optimisé.
• Socket/Xok = Serveur HTTP « Cheetah » + exo-noyau « Xok ».
• Socket/BSD = Serveur HTTP « Cheetah » + OpenBSD 2.0.
• Harvest/BSD = Proxy-cache « Harvest » + OpenBSD 2.0.
• NSCA/BSD = Serveur HTTP « NSCA 1.4.2 » + OpenBSD 2.0.

« XCP » est un programme de copie de données orienté exo-noyau

« XCP » travaille au niveau des blocs du disque dur en évitant d'affecter le processeur sur les données qu'il traite. Son mode de fonctionnement est asynchrone et il ne passe par aucun fichier temporaire. Grâce à « Xok/ExOS », il est trois fois plus rapide que la commande « CP » pour la copie du même fichier. Ce résultat démontre la performance des applications qui passent outre un système d'exploitation standard et qui accèdent directement aux ressources^[31],[32].

En parallèle du développement de leur serveur web « Cheetah », le MIT a développé « Webswamp », un programme fonctionnant avec la distribution « Xok/ExOS » et qui permet de faire du benchmark d'applications HTTP. Grâce à cet outil performant, les chercheurs du Massachusetts Institute of Technology peuvent analyser le positionnement de leur systèmes face aux concurrents et donc les améliorer le cas échéant^[114].

Un système d'exploitation standard implémente des processus, des adresses en mémoire et des exceptions pour assurer sa sécurité : ce mécanisme induit l'action des applications dans la sécurité du système^[17]. Les processus lancés sur un système monolithique ont souvent trop de privilèges qui ne sont pas gérés par celui-ci ce qui rend l'ensemble vulnérable^[115]. L'exo-noyau va à l'encontre de cette approche : il est le seul à gérer la protection de son environnement^[58]. La méthode employée est la suivante : la séparation de la gestion des ressources donnée aux applications et de la sécurité gérée par le noyau^{[7],[8],[9],[6]}. Le principal inconvénient de l'architecture exo-noyau est sa vulnérabilité face aux attaques contre la sécurité du système. En effet, en fournissant un accès direct aux ressources matérielles et aux applications on favorise les accès illégaux aux données^{[116],[10],[117]}. Une application ne doit pas avoir accès à des données sans permission(s). De même, tout applicatif ne doit pas accaparer toutes les ressources du système au risque de compromettre la qualité de service. Le grand avantage de l'exo-noyau au niveau de la politique de sécurité, c'est que celle-ci n'empiète pas sur la gestion des ressources ce qui est souvent le cas d'un système monolithique. Le programmeur peut donc implémenter son code sans se soucier de cet aspect^[118]. La philosophie du MIT^{[note 1]} sur ce sujet est la suivante : l'exo-noyau apporte des mécanismes de protection, pas des politiques de sécurité^[86],[10].

Ces mécanismes de protection ont un nom : les liens sécurisés (Secure Bindings)^{[59],[5],[60]}. Ces liaisons s'effectuent entre les LibOSes et la couche matérielle et passent par le noyau qui applique ainsi sa sécurité. La performance du système n'est pas remise en question car les opérations logicielles effectuées par l'exo-noyau lors de ces étapes sont simples et rapides^[119]. Les trois techniques de base utilisées pour l'implémentation d'un lien sécurisé sont : les mécanismes matériels, les opérations en mémoire cache et le chargement de code^[120],[59].

Présentation des mécanismes :

Les mécanismes matériels

Les liens sécurisés implémentant cette solution sont utilisés pour la protection de l'accès à la ressource disque. Les droits d'accès d'une LibOS (ou LibFS) aux blocs d'un disque dur sont du code généré dynamiquement et stocké par le noyau dans le cache du disque^[120],[64].

Les opérations en mémoire cache

Cette solution est utilisée pour la protection des accès mémoire qui est basée sur la génération dynamique d'un code de vérification^[121],[122]. Ce code est stocké dans le cache de la mémoire vive (RAM) et définit les droits de la LibOS affectée. Si ces droits sont insuffisants, l'accès est refusé^[49]. L'exo-noyau utilise un large TLB ou Translation lookaside buffer logiciel (différent du TLB matériel du processeur) pour la translation d'adresses : cet espace est un cache que le noyau utilise également pour établir ces liens sécurisés entre les LibOSes et la partie matérielle^[120].

Le chargement de code

Cette méthode entre en fonction pour la protection du système contre le flux réseau entrant. Le filtre dynamique de paquets ou DPF (Dynamique Packet Filter - pare-feu) utilisé par l'exo-noyau emploie du chargement de code lors de l'analyse des paquets réseau entrants avant la mise à disposition aux LibOSes^{[49],[50],[51],[52],[53],[54]}. Le « ASH » (Application-specific Safe Handlers) est utilisé par le « DPF » pour le dialogue avec la couche LibOS/applicative^[56],[57].

Si une application pose un problème lors de l'utilisation d'une ressource matérielle, l'exo-noyau est capable de lui interdire l'accès en brisant le lien sécurisé^[5].

Grâce à la plateforme de développement (ou framework) « THINK »^{[note 11]} qui reprend les notions importantes en termes de ressources (logicielles et matérielles) de l'exo-noyau^[118], il est possible de concevoir un tel noyau. En reprenant le principe des liaisons sécurisées entre les LibOSes et le matériel en passant par l'exo-noyau, cet outil de mise en œuvre est idéal^[123],[124]. « THINK » est orienté concept exo-noyau à 100% donc application modulaire. Les pleins pouvoirs sur l'utilisation des ressources matérielles mises à disposition, les exigences en matière de flexibilité et de performances chères au concept, la notion de sécurité aux besoins du développeur : tous ces points cruciaux et faisant la force de l'architecture de l'exo-noyau sont ici réunis^[125]. Un des projets utilisant cette solution de développement est « AMP » dans l'implémentation d'un système exo-noyau pour la gestion de l'interface d'un routeur actif^[109].

Un autre projet reprend la même approche que « THINK » : le framework « OSKit »^{[note 10]}. Cette plateforme de développement permet de créer un exo-noyau grâce à une collection de bibliothèques et d'outils^[126]. Le projet « AMP » a également utilisé « OSKit » pour la création de son système exo-noyau gérant l'interface d'un routeur actif^[70].

Référencement des exo-noyaux

Nom	Architecture	Multiprocesseur	Utilisation	Auteur(s)	Année
Aegis[37],[9],[35]	MIPS	Non	Serveur	D. Engler[note 2] et F. Kaashoek[note 3]	1995
Camille[18]	RISC / CISC	Non	Embarqué	D. Deville, A. Courbot et G. Grimaud	2003
Camille RT[19]	RISC / CISC	Non	Embarqué - Temps réel	D. Deville et A. Courbot	2003
Glaze[9]	FUGU	Oui	Serveur	K. Mackenzie, J. Kubiatowicz, M. Frank, W. Lee, V. Lee, A. Agarwal, et F. Kaashoek	1996
Nemesis[note 5],[40]	x86, DEC ALPHA (RISC_64), StrongARM	Non	Serveur	University of Cambridge[note 6]	2000
Mirage[note 9],[40],[22]	x86	Oui	Cloud computing	Projet Xen	2013
Xok[8],[9],[6],[34],[35],[36]	x86_32	Non	Serveur, Routeur Actif	D. Engler et F. Kaashoek	1995
SMP-Xok[20]	x86_32	Oui	Serveur	B. Chen	2000
XomB[note 8],[21]	x86_64	Oui	Serveur	J. Larkby-Lahet, B. Madden, D. Wilkinson et D. Mosse	2010

• Hyperviseur
• Noyau de système d'exploitation
• Paravirtualisation
• Unikernel
• Virtualisation

• (en) « Mirage OS: A Cloud Operating System », 2013
• (en) Hosien Marzi et Yuntao Yang, « Microkernel based real-time embedded operating systems efficiency improvement », 19 avril 2012 - 2 mai 2012, Montreal, QC,‎ avril - mai 2012, p. 1-4 (ISBN 978-1-4673-1431-2, DOI 10.1109/CCECE.2012.6335029, lire en ligne)
• (en) James Larkby-Lahet, Brian A. Madden, Dave Wilkinson et Daniel Mosse, « XOmB: an Exokernel for Modern 64-bit, Multicore Hardware », 2010, Department of Computer Science – University of Pittsburgh Pittsburgh, PA – USA - Department of Computer Science University of California, Santa Cruz Santa Cruz, CA – USA,‎ 2010 (lire en ligne)
• (en) Matthieu Lemerre, Vincent David et Guy Vidal-Naquet, « A communication mechanism for resource isolation », 31-03-2009, New York, NY, USA,‎ février 2009, p. 1-6 (ISBN 978-1-60558-464-5, DOI 10.1145/1519130.1519131, lire en ligne)
• (en) Christophe Rippert et Jean-Bernard Stefani, « Protection in the THINK exokernel », 2008, European,‎ août 2008 (lire en ligne)
• Vivien Quema, « Vers l'exogiciel -- Une approche de la construction d'infrastructures logicielles radicalement configurables », Massachusetts Institute of Technology, Grenoble, France,‎ décembre 2005 (lire en ligne)
• (en) Kimmo Raatikainen, « Operating system issues in future end-user systems », 11-14 Septembre 2005, Berlin,‎ septembre 2005, p. 2794-2800 Vol. 4 (ISBN 9783800729098, DOI 10.1109/PIMRC.2005.1651950, lire en ligne)
• (en) Tim Leschke, « Achieving speed and flexibility by separating management from protection: embracing the Exokernel operating system », ACM SIGOPS Operating Systems Review Volume 38 Issue 4, New York, NY, USA,‎ octobre 2004, p. 5-19 (DOI 10.1145/1031154.1031155)
• Damien Deville, Alexandre Courbot et Gilles Grimaud, « Extensions Temps-Réel pour Exo-Noyau Embarqué », 2003, La Colle sur Loup, France,‎ octobre 2003, p. 1-13 (lire en ligne)
• (en) Christophe Rippert et Jean-Bernard Stefani, « THINK: A secure distributed systems architecture », 2002, LSR-IMAG laboratory, SARDES project, CNRS-INPG-INRIA-UJF,‎ 2002, p. 243-246 (DOI 10.1145/1133373.1133424, lire en ligne)
• (en) Julia Lawall, Jean-Bernard Stefani, Jean-Philippe Fassino et Gilles Muller, « THINK: A Software Framework for Component-based Operating System Kernels », 2002, France,‎ 2002 (lire en ligne)
• (en) Billy Lehner et Steven Petzinger, « MIT Exokernel Operating System », 2002,‎ 2002 (lire en ligne)
• (en) Hrishikesh Dandekar, Andrew Purtell et Stephen Schwab, « AMP: Experiences with building an exokernel-based platform for active networking », 2002, Mantova,‎ 2002, p. 77-83 (ISBN 0-7695-1564-9, DOI 10.1109/DANCE.2002.1003485)
• (en) Gregory R Ganger, Dawson R Engler, Frans Kaashoek, Hector M Briceño, Russell Hunt et Pinckney Thomas, « Fast and flexible application-level networking on exokernel systems », ACM Transactions on Computer Systems (TOCS) Volume 20 Issue 1, New York, NY, USA,‎ février 2002, p. 49-83 (DOI 10.1145/505452.505455)
• (en) Ahmed Waqar, « Multiple guest operating systems under Exo-kernel », Multi Topic Conference, Karachi,‎ décembre 2002, p. 83 (ISBN 0-7803-7715-X, DOI 10.1109/INMIC.2002.1310190)
• Christophe Rippert et Jean-Bernard Stefani, « Éléments de sécurité dans l'architecture de systèmes répartis THINK », 2002, Hammamet, Tunisie,‎ avril 2002, p. 1-6 (lire en ligne)
• (en) Frans Kaashoek, Charles Blake et Robert Morris, « EXOKERNEL AND EXOTOOLS », Massachusetts Institute of Technology, Cambridge Massachusetts,‎ janvier 2002 (lire en ligne)
• (en) Ernest Artiaga et Marisa Gil, « Running multithreaded applications in exokernel-based systems: porting CThreads to Xok », 2001, Mantova,‎ 2001, p. 77-83 (ISBN 0-7695-0987-8, DOI 10.1109/EMPDP.2001.905018, lire en ligne)
• (en) Larry Peterson, Yitzchak Gottlieb, Mike Hibler, Patrick Tullmann, Jay Lepreau, Stephen Schwab, Hrishikesh Dandekar, Andrew Purtell et John Hartman, « An OS interface for active routers », Mars 2001,‎ mars 2001, p. 473-487 (DOI 10.1109/49.917708, lire en ligne)
• (en) Ernest Artiaga, Albert Serra et Marisa Gil, « Porting multithreading libraries to an exokernel system », EW 9 Proceedings of the 9th workshop on ACM SIGOPS European workshop: beyond the PC: new challenges for the operating system, New York, NY, USA,‎ septembre 2000, p. 121-126 (DOI 10.1145/566726.566754)
• (en) Benjie Chen, « Multiprocessing with the Exokernel operating system », 2000, Massachusetts, USA,‎ février 2000, p. 1-60 (lire en ligne)
• (en) Dawson Engler, « The Exokernel Operating System Architecture », 1998, Massachusetts, USA,‎ octobre 1998, p. 1-93 (lire en ligne)
• (en) Dawson Engler et Frans Kaashoek, « Exokernels (or, making the operating system just another application library) », 1998, M.I.T. Lab for Computer Science,‎ 1998 (lire en ligne)
• (en) Frans Kaashoek, Dawson Engler, Gregory Ganger et Hector Briceno, « Application Performance and Flexibility on Exokernel Systems », 1997, New York, NY, USA,‎ décembre 1997, p. 52-65 (ISBN 0-89791-916-5, DOI 10.1145/268998.266644, lire en ligne)
• (en) Cynthia Irvine, « Security in innovative new operating systems », 4 mai 1997, Computer Science Department Naval Postgraduate School Monterey, California 93943,‎ mai 1997, p. 202-203 (ISBN 0-8186-7828-3, DOI 10.1109/SECPRI.1997.601334, lire en ligne)
• (en) Frans Kaashoek, Dawson Engler et James O'Toole, « Exokernel: an operating system architecture for application-level resource management », SIGOPS, M.I.T. Laboratory for Computer Science - Cambridge, MA 02139, U.S.A,‎ décembre 1995, p. 251-266 (ISBN 0-89791-715-4, DOI 10.1145/224056.224076)
• (en) Dawson Engler, Frans Kaashoek et James O'Toole, « The operating system kernel as a secure programmable machine », SIGOPS, New York,‎ janvier 1995, p. 78 - 82 (DOI 10.1145/202453.202474, lire en ligne)
• (en) Dawson Engler, Sandeep K Gupta et Frans Kaashoek, « AVM: Applicat ion-Level Virtual Memory », Hot Topics in Operating Systems, Orcas Island, WA,‎ mai 1995, p. 72 -77 (ISBN 0-8186-7081-9, DOI 10.1109/HOTOS.1995.513458, lire en ligne)
• (en) Dawson Engler et Frans Kaashoek, « Exterminate all operating system abstractions », Hot Topics in Operating Systems, Orcas Island, WA,‎ mai 1995, p. 78 - 83 (DOI 10.1109/HOTOS.1995.513459, lire en ligne)

v · m Principaux systèmes d’exploitation
Apple	Mac OS Classic Système 5 Système 6 Système 7 Mac OS 8 Mac OS 9 Dérivés de NeXTSTEP NeXTSTEP Rhapsody Darwin macOS iOS
Dérivés de BeOS	BlueEyedOS Haiku ZETA
DOS	DR-DOS FreeDOS MS-DOS PC-DOS Open DOS
IBM	AIX MVS OS/2 OS/360 OS/390 z/OS OS/400
Microsoft Windows	Fondés sur MS-DOS 1.0 2.x 3.x 95 98 ME Branche NT NT 3.x NT 4.0 2000 XP 2003 Vista 2008 R2 7 2012 R2 8 / 8.1 2016 10 2019 2022 11
ReactOS Foundation	Branche NT (GPL/LGPL/AGPL) non-Microsoft ReactOS
POSIX / Unix	AT&T / Laboratoires Bell Unix version 6 Unix version 7 System III (en) System V BSD FreeBSD TrueOS GhostBSD DragonFly BSD TrueNas OpenBSD NetBSD GNU Hurd Debian GNU/Hurd Arch Hurd Linux (liste) Arch Linux Calculate Linux CentOS Debian Gentoo GNU Guix Fedora Mageia Manjaro Mint openSUSE PCLinuxOS Puppy Red Hat Slackware Ubuntu Raspberry Pi OS Chromium OS/Chrome OS Autres dérivés AIX Apache NuttX ChorusOS Fuzix OS HP-UX IRIX LynxOS macOS Minix Oracle Solaris QNX Redox Tru64 UNICOS UnixWare
Dérivés d'AmigaOS	MorphOS AROS
Dérivés du TOS	EmuTOS FreeMiNT Geneva MagiC MultiTOS N.AES
D’importance historique	CP/M CTSS GCOS Genera ITS Multics Plan 9 QDOS RSTS TENEX TOPS-20 VMS SCO
Mobile	Noyau Linux Android Bada Firefox OS HarmonyOS KaiOS LG webOS Sailfish OS Tizen Ubuntu Touch UBports Autres noyaux BlackBerry OS HarmonyOS iOS Palm OS Symbian OS Windows Phone
Embarqués	Pour capteur en réseau Contiki TinyOS Pour carte à puce Java Card MULTOS Temps réel eCos FreeRTOS Linux embarqué LiteOS LynxOS MenuetOS NuttX OS-9 PikeOS QNX RTEMS RTLinux RT-Thread RTX µC/OS-II VxWorks Zephyr
Autres systèmes	eyeOS Cisco IOS Inferno MenuetOS Orbis OS CertiKOS
Pour une liste complète, voir la liste des systèmes d’exploitation et la catégorie « Système d’exploitation ».

• Lien vers la page d’accueil de ExAmour - « Open Source GNU exokernel platform » - ExAmour

• Portail de l’informatique