Tout système d’exploitation commence avant d’être vraiment lui-même. Le CPU démarre dans un environnement défini par la plateforme, le firmware initialise assez de matériel pour charger le premier exécutable, et cet exécutable prépare la machine pour le noyau. Ce n’est qu’après le travail de cette chaîne que le système d’exploitation peut commencer à appliquer ses propres règles. Il est facile de traiter ce chemin initial comme de la simple plomberie, mais le processus de démarrage fait partie du modèle de sécurité.

Les systèmes d’exploitation sont généralement associés au C. Cette association est compréhensible. C est petit, prévisible, proche de la machine, et historiquement dominant dans le travail sur les noyaux. Il donne au programmeur un accès direct à la mémoire, aux registres, aux layouts et aux conventions d’appel. Ce sont exactement les choses dont un noyau a besoin. Ce sont aussi exactement les choses qui rendent les noyaux difficiles à sécuriser.

Les discussions de sécurité se concentrent souvent sur des bogues individuels : un débordement de tampon une faille de député confus un parseur insuffisamment vérifié un chemin d’escalade de privilèges Ces bogues comptent, mais ils sont les symptômes d’une question plus profonde : Combien de code doit être correct pour que le système reste sûr ? Ce code est la base de calcul de confiance, généralement abrégée en TCB. La taille et la forme de la TCB déterminent combien de code doit être jugé fiable, audité, testé et raisonné.

Peu de débats de conception de systèmes d’exploitation ont duré aussi longtemps que celui qui oppose les microkernels aux kernels monolithiques. En surface, la distinction paraît simple : les kernels monolithiques gardent la plupart des services du système d’exploitation dans le kernel les microkernels déplacent la plupart des services en espace utilisateur En pratique, le compromis est plus subtil. La vraie question n’est pas de savoir si une structure est universellement plus rapide, plus propre ou plus sûre.

La plupart des systèmes d’exploitation modernes reposent sur des décennies de code accumulé, de bibliothèques et de dépendances externes. Bien que cet écosystème permette un développement rapide, il introduit aussi de la complexité, des hypothèses cachées et des risques de sécurité potentiellement non examinés. EriX adopte une approche différente. Il est développé comme un système d’exploitation en salle blanche, ce qui signifie que chaque composant - du chargeur d’amorçage aux services en espace utilisateur - est implémenté au sein du projet lui-même, sans intégrer de code source externe ni de bibliothèques tierces.

Les systèmes d’exploitation modernes imposent des frontières de sécurité entre processus, fichiers, périphériques et utilisateurs. Cependant, la manière dont ces frontières sont mises en oeuvre varie considérablement selon la conception du système. La plupart des systèmes d’exploitation classiques reposent sur le contrôle d’accès fondé sur l’identité et sur des espaces de noms globaux. Les systèmes d’exploitation à capacités adoptent une approche fondamentalement différente : ils représentent l’autorité explicitement et en font un concept de premier ordre.

Les systèmes d’exploitation font partie des logiciels les plus complexes jamais construits. Ils gèrent la mémoire, planifient le calcul, contrôlent le matériel et appliquent les frontières de sécurité qui protègent chaque application exécutée sur une machine. Pourtant, beaucoup des systèmes d’exploitation sur lesquels nous comptons aujourd’hui reposent sur des idées d’architecture datant de plusieurs décennies. Bien que ces systèmes soient extraordinairement puissants et éprouvés, ils portent aussi des décennies de complexité accumulée.