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.

Cet article explore ce que signifie le développement en salle blanche dans la pratique, pourquoi il est utile et quels compromis il introduit.

Que signifie “salle blanche” ?⌗

Dans le contexte d’EriX, le développement en salle blanche signifie :

  • Aucun code source externe n’est copié ou réutilisé
  • Aucune bibliothèque ni aucun crate tiers n’est inclus
  • Tous les composants sont implémentés au sein du projet
  • Seules les spécifications et documentations publiques peuvent être consultées

Le résultat est un système où chaque ligne de code est :

  • comprise
  • auditable
  • conçue intentionnellement

Ce n’est pas seulement une décision juridique ou de licence ; c’est une décision architecturale.

Pourquoi éviter le code externe ?⌗

Éviter les dépendances externes peut sembler restrictif. Le développement logiciel moderne encourage généralement la réutilisation, et les grands écosystèmes existent précisément pour éviter de réinventer la roue.

Cependant, les systèmes d’exploitation ne sont pas des applications ordinaires.

1. Complexité cachée⌗

Le code externe apporte souvent des hypothèses implicites :

  • sur l’agencement de la mémoire
  • sur les modèles de concurrence
  • sur la gestion des erreurs
  • sur le comportement de la plateforme

Ces hypothèses peuvent ne pas s’aligner avec l’architecture d’un nouveau système d’exploitation, surtout s’il est construit autour des capacités et d’un isolement strict.

2. Base de calcul de confiance (TCB) élargie⌗

Chaque dépendance augmente la taille de la base de calcul de confiance.

Si une bibliothèque tierce est utilisée dans le noyau ou dans des composants système critiques, sa correction devient une partie des garanties de sécurité du système.

Le développement en salle blanche garde la TCB :

  • petite
  • contrôlée
  • définie explicitement

3. Auditabilité et vérification⌗

Un système entièrement construit en interne peut être audité systématiquement.

  • Tout le code unsafe peut être examiné
  • Tous les invariants peuvent être documentés
  • Toutes les interfaces peuvent faire l’objet d’un raisonnement

C’est particulièrement important pour un système comme EriX, qui met l’accent sur :

  • l’autorité explicite
  • la sécurité à capacités
  • une conception minimale du noyau

4. Liberté architecturale⌗

Réutiliser du code existant contraint souvent les décisions de conception.

Par exemple :

  • adopter une bibliothèque peut imposer une forme particulière d’API
  • intégrer du code existant peut exiger des couches de compatibilité
  • des abstractions héritées peuvent se retrouver dans de nouveaux composants

Le développement en salle blanche permet au système d’être façonné entièrement par ses propres principes, plutôt que par des contraintes héritées.

Salle blanche ou réimplémentation⌗

Il est important de distinguer le développement en salle blanche d’une simple réimplémentation.

Le développement en salle blanche ne signifie pas réécrire aveuglément des systèmes existants.

Il implique plutôt :

  • l’étude de spécifications publiques
  • la compréhension des principes sous-jacents
  • la conception de nouvelles implémentations à partir des premiers principes

Par exemple :

  • Un système de fichiers peut suivre la sémantique POSIX, tout en étant implémenté indépendamment
  • Un chargeur d’amorçage peut suivre les spécifications UEFI, tout en utilisant une structure personnalisée
  • Une bibliothèque standard C peut exposer la même API, tout en étant écrite entièrement en Rust

L’objectif est la compatibilité là où elle est nécessaire, sans réutilisation de code.

La salle blanche en pratique⌗

Dans EriX, les contraintes de salle blanche sont appliquées à l’ensemble du système.

Aucun crate externe⌗

Même en Rust, où la réutilisation des dépendances est courante, EriX évite les crates externes.

À la place, il définit des composants internes réutilisables tels que :

  • des utilitaires mémoire
  • des primitives de synchronisation
  • des abstractions de capacités

Bibliothèques internes⌗

Les fonctionnalités réutilisables sont organisées en crates internes, par exemple :

  • lib-bootimg
  • lib-capabi
  • lib-ipc

Ces bibliothèques sont :

  • versionnées
  • contrôlées au sein du projet
  • conçues spécifiquement pour les besoins du système

Structure stricte du dépôt⌗

Chaque sous-système est isolé :

  • chargeur d’amorçage
  • noyau
  • IPC
  • gestion de la mémoire
  • services en espace utilisateur

Cela impose la modularité et empêche les couplages cachés.

Builds reproductibles⌗

La conception en salle blanche s’étend aussi au processus de build.

Le système vise :

  • des builds déterministes
  • des hypothèses minimales sur la chaîne d’outils
  • des étapes de build explicites

Cela garantit que les artefacts peuvent être reproduits et vérifiés.

Avantages d’un OS en salle blanche⌗

1. Compréhension complète du système⌗

Chaque composant est connu et compris.

Il n’y a pas de dépendances opaques ni de comportements cachés.

2. Modèle de sécurité plus fort⌗

Avec une TCB plus petite et contrôlée :

  • il existe moins de surfaces d’attaque
  • les invariants sont plus faciles à faire respecter
  • la sécurité à capacités peut être implémentée proprement

3. Meilleure plateforme de recherche⌗

EriX n’est pas seulement un système d’exploitation ; c’est aussi une plateforme de recherche.

Le développement en salle blanche permet :

  • l’expérimentation de nouvelles abstractions
  • la mesure précise des compromis de conception
  • un raisonnement clair sur l’autorité et l’isolement

4. Maintenabilité à long terme⌗

Bien qu’ils demandent plus de travail au départ, les systèmes en salle blanche peuvent être plus faciles à maintenir :

  • pas de rupture de dépendance
  • pas de changements upstream à suivre
  • pas de conflits de versions

Le système évolue selon ses propres termes.

Compromis et défis⌗

Le développement en salle blanche n’est pas sans coût.

1. Développement plus lent⌗

Tout doit être construit à partir de zéro :

  • bibliothèques de base
  • support d’exécution
  • services système

Cela augmente considérablement l’effort initial.

2. Réinventer la roue⌗

De nombreux problèmes ont déjà été résolus ailleurs.

Les réimplémenter exige du temps et une conception soigneuse.

3. Moins de raccourcis⌗

Il n’est pas possible de :

  • importer rapidement une bibliothèque
  • s’appuyer sur des écosystèmes existants
  • déléguer la complexité à du code externe

Toute la complexité doit être traitée directement.

4. Responsabilité de conception accrue⌗

Chaque abstraction doit être conçue délibérément.

Les erreurs ne peuvent pas être facilement masquées en remplaçant des dépendances.

Pourquoi cette approche convient à EriX⌗

EriX est construit autour de quelques principes centraux :

  • base de calcul de confiance minimale
  • autorité explicite par les capacités
  • séparation stricte entre noyau et espace utilisateur
  • reproductibilité et déterminisme

Le développement en salle blanche soutient tous ces objectifs.

Il garantit que :

  • l’autorité n’est jamais cachée dans du code externe
  • les invariants du système sont entièrement contrôlés
  • l’architecture reste cohérente dans tous les composants

Une base pour le self-hosting⌗

La conception en salle blanche soutient aussi l’objectif à long terme du self-hosting.

Pour construire EriX à l’intérieur d’EriX, le système doit inclure :

  • sa propre chaîne d’outils
  • ses propres bibliothèques d’exécution
  • ses propres interfaces système

Un système qui dépend fortement de composants externes aurait du mal à atteindre ce niveau d’indépendance.

Et ensuite⌗

Concevoir un système d’exploitation en salle blanche est un effort de long terme. Cela demande une planification attentive, une implémentation disciplinée et la volonté de construire des composants fondamentaux à partir de zéro.

Mais cela crée aussi un système qui est :

  • transparent
  • contrôlé
  • profondément compris

Dans de futurs articles, nous passerons des principes à l’implémentation, en commençant par le processus d’amorçage initial et la conception du format d’image de démarrage du système.