OptimaOS sur Rust : un seul noyau pour toutes les plateformes

Le noyau unifié Rust d'OptimaOS : une architecture pour le bureau, les serveurs et les périphériques Edge

OptimaOS est conçu comme un noyau unique qui alimente les bureaux, les serveurs, les dispositifs Edge et les accélérateurs IA — sans duplication ni recompilation. Le projet affronte directement la fragmentation : au lieu de multiples bases de code divergentes avec des vulnérabilités et des API incompatibles, il repose sur une seule image binaire avec des profils d'exécution dynamiques. Les mécanismes fondamentaux sont intégrés au noyau, tandis que les politiques sont configurées dynamiquement via un service de gestion des politiques.

Dès 2026, les noyaux traditionnels comme Linux, Windows NT ou Darwin auront accumulé une dette technique considérable. Les branches telles qu'Android ou Linux embarqué nécessitent des audits de sécurité distincts et des tests de régression séparés.

Séparation des mécanismes et des politiques

L'architecture suit le principe UNIX : le noyau fournit les mécanismes, tandis que l'espace utilisateur définit les politiques. Ce principe est formalisé dans l'ADR-0002.

Mécanismes présents dans le noyau (indépendants du profil) :

• Gestion de la mémoire : régions, mmap/munmap/protect.
• Planificateur de processus et de threads.
• Bus IPC avec points d'accès typés.
• Graphe de capacités pour l'accès aux ressources.
• ABI système : optima_syscall_v0.

Politiques définies par le profil d'exécution :

• Règles d'accès aux processus.
• Configuration des services en espace utilisateur (pile réseau, paramètres).
• Paramètres du planificateur (latence vs débit).
• Modèles autorisés d'appels système.

Au démarrage, le fichier de politique est appliqué via l'API d'exécution. Une seule image binaire supporte à la fois les profils home (bureau) et server.

Pourquoi Rust pour le développement système ?

Rust a été choisi pour sa sécurité mémoire garantie à la compilation, sans ramasse-miettes. Le noyau minimise le TCB : #[forbid(unsafe_code)] est strictement appliqué dans kernel-core, tandis que le code non sécurisé est limité au HAL (hardware/mod.rs).

Les concepts de possession s'intègrent naturellement au graphe de capacités : les ressources comme des jetons de possession s'alignent parfaitement avec les durées de vie.

Les avantages de l'écosystème incluent cargo test, cargo build --target x86_64-unknown-uefi et un support robuste de no_std, ce qui simplifie grandement le développement d'un système d'exploitation.

Structure du projet

Un espace de travail Rust avec des crates :

• kernel-core : moteur d'exécution.
• linux-compat : passerelle ABI Linux (L1/L2).
• policy-service : gestion des politiques.
• device-manager : gestion des périphériques.
• filesystem-service : systèmes de fichiers.
• network-service : réseau.
• profile-service : superpositions de profils.

Les services interagissent avec le noyau via IPC typés et capacités, évitant toute dépendance directe à kernel-core.

Modules clés du noyau

| Module | Objectif |

|--------|---------|

| runtime.rs | KernelRuntime — machine à états du cycle de vie. |

| syscall.rs | optima_syscall_v0, structure Kernel. |

| ipc.rs | IPC en mémoire avec PID propriétaire. |

| memory.rs | Régions mémoire, mmap/munmap/protect. |

| scheduler.rs | Planificateur. |

| capability.rs | Graphe de capacités : accorder/rétrograder/transférer. |

| policy.rs | Règles et surcharges de politique. |

| audit.rs | Journal d'audit. |

| console_transport.rs | Adaptateur UEFI ↔ runtime. |

Transport de console et processus de démarrage

Architecture en deux couches (ADR-0003) :

• Phase A (shim UEFI) : transport, diagnostics, entrée/sortie. Ne pas exécuter de commandes.
• Phase B (kernel-core) : point d'entrée pour sys.*.

Cycle de vie : BootInit → ShimReady → RuntimeAttach → Interactive → Degraded. Cette séparation simplifie la vérification : UEFI fonctionne en mode démarrage, le runtime opère de manière autonome.

Compatibilité ABI Linux

linux-compat mappe progressivement les appels système Linux vers optima_syscall_v0, minimisant ainsi la surface d'attaque.

L1 (prêt) : clone, exit, nanosleep, mmap, sendmsg, recvmsg, epoll basique.

L2-A (prêt) : cycle de vie des descripteurs, poll/epoll_wait.

L2-B (prêt) : masques de signaux.

L2-C (prêt) : epoll_ctl(DEL/MOD).

L'API reste encore en phase de brouillon ; la stabilité viendra plus tard. Chaque étape subit un test de matrice de compatibilité.

Plan de développement

Priorités :

• Démarrage sur matériel x86_64 réel, tests de fumée, mesures de performance.
• Finalisation de Linux L2, ajout de signalfd/eventfd.
• IPC Android Binder.
• Win32 L3.
• Interface graphique : Unicode, rendu d'images.

Objectif : valider l'hypothèse d'un seul noyau sans perte de performance.

Points clés

• Un seul noyau, aucune duplication, adapté à divers usages via des profils d'exécution.
• Séparation stricte entre mécanismes du noyau et politiques en espace utilisateur.
• Rust avec #[forbid(unsafe_code)] garantit la sécurité mémoire dans le TCB.
• Support incrémental de l'ABI Linux : L1/L2 terminés et validés.
• Transport de console en deux couches permet un démarrage sécurisé.

— Editorial Team