Lyx OS – Systemarchitektur

Diese Seite beschreibt den Aufbau von Lyx OS: die Drei-Domänen-Architektur (TCB / Lyra / User), die Schichten vom UEFI-Boot bis zum Ring-3-Userspace, das Speicherlayout, die Kernel-Module und das Capability-Routing-Gate.

→ Übersicht · Syscall-ABI · Kernel-Interna

┌──────────────────────────────────────────────────────────┐
│  Ring-3 – User-Domäne (eigene CR3, minimale Capabilities)│
│  Anwendungen, Shell — via SysSpawn aus VFS gestartet     │
│  Nur erlaubte Syscall-Klassen (PLEDGE_*-Bitmask)         │
├──────────────────────────────────────────────────────────┤
│  Ring-3 – Lyra-Domäne (eigene CR3, privilegierter Dienst)│
│  LLM-Inferenz · lyxc-Compiler · Tool-Registry           │
│  Schlägt vor / erteilt Capabilities — erzwingt nie       │
│  Lyra-KI-Agent (WP17) offen; Vega-Compositor (WP17b) ✅  │
├──────────────────────────────────────────────────────────┤
│  Capability Routing Gate (r3_sc_block-Protokoll)         │
│  Nicht-sensible Syscalls: TCB bedient direkt             │
│  Capability-erwerbende Syscalls: → Lyra-Mailbox          │
├──────────────────────────────────────────────────────────┤
│  Ring-0 – TCB (Trusted Computing Base, Lyx-Sprache)      │
│  PMM · VMM · Exceptions/IDT · SMP · Process             │
│  ATA · Disk · MBR · FAT32 · VFS · Keyboard              │
│  Initrd · Locale · Sync · Ring3                          │
│  Deterministisch, WCET-beschränkt — ruft das LLM nie    │
├──────────────────────────────────────────────────────────┤
│  UEFI-Bootloader (NASM, boot.asm)                        │
│  PE32+-Binary — BOOTX64.EFI                              │
├──────────────────────────────────────────────────────────┤
│  UEFI-Firmware (OVMF)  /  PC-Hardware                    │
└──────────────────────────────────────────────────────────┘

Mechanismus und Intelligenz sind strikt getrennt: Der TCB enthält kein LLM und ruft keines auf. Lyra (Ring-3) hält das Modell, der TCB hält die Hardware-Gewalt. Kein kernel/ai.lyx.

Der Bootloader (bootloader/boot.asm, NASM, ~2900 Zeilen) ist ein PE32+-Flat-Binary. UEFI lädt es als BOOTX64.EFI und ruft efi_main(ImageHandle, SystemTable) auf (MS x64 ABI).

Schritte:

1. Begrüßung über UEFI ConOut
2. Kernel laden — \\kernel.elf vom UEFI SimpleFileSystem lesen
3. ELF64 parsen — PT_LOAD-Segmente mappen, BSS nullen
4. UEFI Memory Map holen, ExitBootServices aufrufen
5. GDT laden (64-Bit Code 0x08, Data 0x10)
6. COM1 initialisieren (0x3F8 — serielle Debug-Ausgabe)
7. SYSCALL-MSR (IA32_LSTAR) auf den Ring-0-Einsprungpunkt setzen
8. Page Tables aufbauen (Identity-Map 4 GB)
9. Bump-Allocator ab physisch 0x2000000 (32 MB) initialisieren
10. Sprung in Kernel-Entry (pub fn main(boot_info_ptr: int64) in kernel.lyx)

Page-Größen:

• Kernel: 2 MB Huge Pages (PDE mit PS-Bit) für die ersten 4 GB
• Userspace (M5+): 4 KB Seiten für granulare Rechteverwaltung

Der Kernel besteht aus 25 Lyx-Units, die beim Build einzeln zu .lyu vorkompiliert und dann zu kernel.elf zusammengelinkt werden:

Initialisierungsreihenfolge in kernel.lyx:

PMM → VMM → RNG-Seed → SMP → VFS (→ Fat32VolumeInit, MbrInit) → DiskInit
  → FAT32-Mount → LocaleInit → Initrd-Mount → SysSpawn (Ring-3 Shell)
  → Keyboard-Poll → Sync-Tests → Scheduler (ProcInit, ProcActivate)

Ring-3-Code kommuniziert mit dem Kernel über einen gemeinsamen Speicherblock (r3_sc_block) und einen dedizierten Trigger-Mechanismus — kein traditionelles SYSCALL-Register-Layout.

r3_sc_block-Protokoll:

// Shared block (physische Adresse wird bei Boot-Start übergeben)
offset  0: nr      — Syscall-Nummer (int64)
offset  8: a0      — Argument 0 (int64)
offset 16: a1      — Argument 1 (int64)
offset 24: a2      — Argument 2 (int64)
offset 32: a3      — Argument 3 (int64)
offset 40: result  — Rückgabewert (int64), wird vom Kernel geschrieben

// Ablauf aus Ring-3-Sicht:
var sc: int64 := lyx_get_r3sc();    // einmalig: mmap(0,-5,...) → Blockadresse holen
poke64(sc + 0, NR);                 // Syscall-Nummer schreiben
poke64(sc + 8, arg0);               // Argumente schreiben
lyx_trigger();                      // mmap(0,-6,...) → Kernel-Handler aufrufen
var result: int64 := peek64(sc + 40);

• lyx_get_r3sc() und lyx_trigger() sind keine echten mmap-Aufrufe — der Bootloader fängt negative Größen als vmm_op-Sentinel ab (op -5 = Block-Adresse holen, op -6 = Trigger).
• User-virtuelle Puffer-Adressen (z.B. Lese-Buffer) werden im Kernel via VmmPhysFromUserVirt(proc_cr3, vaddr) in physische Adressen übersetzt, bevor sie an VFS-Funktionen weitergegeben werden.
• Ring-3-FDs sind VFS-FDs + 3 (fd 0 bleibt für stdin/Keyboard reserviert).

→ Implementierung im Kernel: ring3.lyx (handle_r3_syscall) · Vollständige ABI-Spezifikation: Syscall-Referenz · Prozess-Lebenszyklus: Prozesse & Ring-3

Lyx OS kennt keine root-Privileg-Eskalation. Jeder fd ist eine Capability: er kodiert sowohl die Ressource als auch die erlaubten Operationen (Lesen, Schreiben, Mappen, Löschen …). Capabilities können nur eingeschränkt, nie erweitert werden.

PLEDGE_*-Bitmask (implementiert in ring3.lyx):

pub con PLEDGE_STDIO:  int64 := 1;   // stdin/stdout lesen/schreiben
pub con PLEDGE_VFS:    int64 := 2;   // sys_open, sys_read, sys_write, stat
pub con PLEDGE_EXEC:   int64 := 4;   // sys_spawn
pub con PLEDGE_BLOCK:  int64 := 8;   // Raw-Block-Device-Zugriff
pub con PLEDGE_NET:    int64 := 16;  // Netzwerk-Sockets
pub con PLEDGE_PROC:   int64 := 32;  // Prozess-Management (kill, nice …)
pub con PLEDGE_ALL:    int64 := 63;  // alle Capabilities

SysPledge(PLEDGE_STDIO | PLEDGE_VFS);  // Capabilities einschränken (irreversibel)

Der Capability Routing Gate in handle_r3_syscall prüft für jede Syscall-Nummer die benötigte Capability-Klasse (syscall_capability_class) gegen die pledge_mask des Prozesses. Verstöße erzeugen ERR_CAPVIOL (Implementierung: WP15).

→ Details: Prozesse & Ring-3

Lyx OS teilt den Adressraum perspektivisch in drei Domänen auf:

Heute läuft ausschließlich die Shell als Ring-3-Prozess. Lyra (WP17) ist noch nicht implementiert.

Letzte Aktualisierung: 2026-06-25