Exo-noyau

Logo du MIT

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].

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 termes 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 termes 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].