OptimaOS auf Rust: ein Kernel für alle Plattformen

OptimaOS: einheitlicher Rust-Kernel: Architektur für Desktop, Server und Edge

OptimaOS ist als einheitlicher Kernel konzipiert, der Desktop-Systeme, Server, Edge-Geräte und KI-Beschleuniger betreibt – ohne Forks oder Neukompilierung. Das Projekt greift die Fragmentierung direkt an: Statt mehrerer divergierender Codebasen mit unterschiedlichen Sicherheitslücken und APIs nutzt es eine einzige Binärdatei mit dynamischen Laufzeitprofilen. Kernmechanismen sind im Kernel fest verankert, während Richtlinien über einen Policy-Service dynamisch konfiguriert werden.

Bis 2026 wird sich bei traditionellen Kernels wie Linux, Windows NT oder Darwin erhebliche technische Schulden ansammeln. Forks wie Android oder eingebettetes Linux erfordern separate Sicherheitsprüfungen und Regressionstests.

Trennung von Mechanismen und Richtlinien

Die Architektur folgt dem UNIX-Prinzip: Der Kernel stellt Mechanismen bereit, während der Benutzerbereich Richtlinien definiert. Dies ist in ADR-0002 dokumentiert.

Mechanismen im Kernel (profilunabhängig):

• Speicherverwaltung: Regionen, mmap/munmap/protect.
• Prozess- und Thread-Scheduler.
• IPC-Bus mit typisierten Endpunkten.
• Capability-Graph für Ressourcenzugriffe.
• Syscall-ABI: optima_syscall_v0.

Richtlinien im Laufzeitprofil:

• Zugriffsregeln für Prozesse.
• Konfiguration von Benutzerbereichsdiensten (Netzwerkstapel, Parameter).
• Scheduler-Einstellungen (Latenz vs. Durchsatz).
• Erlaubte Syscall-Muster.

Beim Booten wird die Richtliniendatei über die Runtime-API angewendet. Eine einzige Binärdatei unterstützt sowohl das home- (Desktop-) als auch das server-Profil.

Warum Rust für Systemprogrammierung?

Rust wurde gewählt, um Speichersicherheit zur Compile-Zeit ohne Garbage Collection zu gewährleisten. Der Kernel minimiert den TCB: #[forbid(unsafe_code)] wird in kernel-core durchgesetzt, wobei unsichere Codeabschnitte auf HAL (hardware/mod.rs) beschränkt sind.

Eigenschaften der Besitzsemantik integrieren sich nahtlos mit dem Capability-Graph: Ressourcen als Besitztoken entsprechen den Lebensdauersemantiken.

Vorteile der Ökonomie umfassen cargo test, cargo build --target x86_64-unknown-uefi und robuste no_std-Unterstützung – was die Entwicklung von Betriebssystemen vereinfacht.

Projektstruktur

Ein Rust-Werkraum mit Crates:

• kernel-core: Ausführungsmotor.
• linux-compat: Bridge zum Linux-ABI (L1/L2).
• policy-service: Richtlinienverwaltung.
• device-manager: Geräteverwaltung.
• filesystem-service: Dateisysteme.
• network-service: Netzwerke.
• profile-service: Profil-Overlay.

Dienste kommunizieren mit dem Kernel über typisierte IPC und Capability, ohne direkte Abhängigkeit von kernel-core.

Schlüsselkernmodule

| Modul | Zweck |

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

| runtime.rs | KernelRuntime – Lebenszyklus-Zustandsmaschine. |

| syscall.rs | optima_syscall_v0, Kernel-Struktur. |

| ipc.rs | In-Memory-Queue-IPC mit Owner-PID. |

| memory.rs | Speicherregionen, mmap/munmap/protect. |

| scheduler.rs | Scheduler. |

| capability.rs | Capability-Graph: Gewähren/Aufheben/Übertragen. |

| policy.rs | Richtlinienregeln und Überschreibungen. |

| audit.rs | Audit-Trail. |

| console_transport.rs | UEFI-Shim ↔ Runtime. |

Console-Transport und Boot-Prozess

Zweischichtiges Architekturmodell (ADR-0003):

• Stufe A (UEFI-Shim): Transport, Diagnose, Eingabe/Ausgabe. Führt keine Befehle aus.
• Stufe B (kernel-core): Eintrittspunkt für sys.*.

Lebenszyklus: BootInit → ShimReady → RuntimeAttach → Interactive → Degraded. Diese Trennung vereinfacht die Verifikation: UEFI läuft im Boot-Modus, die Runtime arbeitet unabhängig.

Linux-ABI-Kompatibilität

linux-compat mappt Linux-Syscalls schrittweise auf optima_syscall_v0, um die Angriffsfläche zu minimieren.

L1 (fertig): clone, exit, nanosleep, mmap, sendmsg, recvmsg, grundlegende epoll.

L2-A (fertig): FD-Lebenszyklus, poll/epoll_wait.

L2-B (fertig): Signalmasken.

L2-C (fertig): epoll_ctl(DEL/MOD).

API ist noch Entwurf; Stabilität kommt später. Jeder Schritt unterliegt Kompatibilitätsmatrix-Tests.

Entwicklungsroadmap

Prioritäten:

• Boot auf echter x86_64-Hardware, Smoke-Tests, Leistungsmetriken.
• Vollständige Linux-L2, Hinzufügen von signalfd/eventfd.
• Android Binder IPC.
• Win32 L3.
• GUI: Unicode, Bildrendering.

Ziel: Die Hypothese eines einzigen Kernels ohne Leistungsabfall validieren.

Wichtige Erkenntnisse

• Ein Kernel, keine Forks, dient vielfältigen Einsatzfällen über Laufzeitprofile.
• Streng getrennte Architektur zwischen Kernel-Mechanismen und Benutzerbereichsrichtlinien.
• Rust mit #[forbid(unsafe_code)] garantiert Speichersicherheit im TCB.
• Schrittweise Linux-ABI-Unterstützung: L1/L2 komplett und verifiziert.
• Zwei-schichtiger Console-Transport ermöglicht sicheren Boot.

— Editorial Team