Lyx OS – Systemarchitektur

Diese Seite beschreibt den Aufbau von Lyx OS: welcher Code in Ring 0 läuft und welcher in Ring 3, wie beide miteinander reden, und wo Prozesse und Treiber dabei sitzen. Dazu 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 · Treibermodell · Prozesse & Ring-3 · Werkzeuge in /bin · Vega

Lyx OS benutzt genau zwei Schutzringe der CPU: Ring 0 für den Kernel, Ring 3 für alles andere. Ring 1 und 2 bleiben ungenutzt — sie tragen auf x86-64 keinen Nutzen, den eine saubere Syscall-Grenze nicht besser erbringt.

┌─────────────────────────────────────────────────────────────┐
│ RING 3                                                      │
│                                                             │
│   Vega-Compositor  ← Startziel, preemptiver Scheduler-Faden │
│     ├── term            Terminal                            │
│     ├── taskmgr         Aufgabenverwaltung                  │
│     └── /bin/<werkzeug> als Kind des Terminals              │
│                                                             │
│   Tier-1-Treiber:  usbhid · i2chid                          │
│   lyxc             (als LBF)                                │
│   shell.elf        Wartungs-Shell (Rückfallebene)           │
│   Lyra             — noch nicht umgesetzt                   │
├─────────────────────────────────────────────────────────────┤
│ SYSCALL-GRENZE   r3_sc_block + Capability Routing Gate      │
├─────────────────────────────────────────────────────────────┤
│ RING 0 — TCB                                                │
│                                                             │
│   Speicher   PMM · VMM · Bump-Arena                         │
│   Ablauf     Scheduler (4096 Fäden, ≤ 8 Kerne) · SMP · IDT  │
│   Dateien    VFS · FAT32 · IOFS · Initrd                    │
│   Tier-0-Treiber:                                           │
│     Platten  ATA · AHCI · NVMe · virtio-blk · RAM · USB-MSC │
│     Netz     e1000 · pcnet · rtl8139 · virtio-net + TCP/IP  │
│     Bus      PCI · ACPI · xHCI · I²C (DesignWare)           │
│     Ton      HDA · AC97      Eingabe  PS/2-Tastatur         │
│   Laden      ELF64-Loader · LBF-Loader (LYX!)               │
├─────────────────────────────────────────────────────────────┤
│ UEFI-Bootloader (boot.asm, PE32+ → 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) soll das Modell halten, vorschlagen und Capabilities erteilen — erzwingen tut ausschließlich Ring 0.

Historisch gewachsen, und beide sind heute in Gebrauch:

ps liest die Fadentabelle (Syscalls 206/207), top die achild-Plätze (202). Dass beides nebeneinandersteht, ist kein Entwurf, sondern der Stand: die Ereigniswarteschlangen wurden bereits von den acht slot+2-Kennungen auf die Faden-Kennungen umgestellt (EV_PIDS = 256).

Der Bootstrap-Kern (BSP) trägt den Compositor. Die übrigen Kerne werden hochgefahren und laufen im Leerlauf; ein fest zugeordneter Rechenfaden auf Kern 1 ist die geprüfte Vorgabe. Das MP3-Dekodieren auf einem eigenen Kern ist gebaut, aber noch nicht die Vorgabe — unter KVM mit vier vCPUs erreicht der Bootlauf die Diagnoseausgabe nicht zuverlässig. Deshalb zeigt top regelmäßig Kern 0 nahe 100 % und die übrigen nahe 0 %.

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:

→ Welche Controller, Busse und Geräteklassen heute bedient werden — und womit man einen eigenen Treiber schreibt: Treibermodell.

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;       // Rohzugriff auf Blockgeräte
pub con PLEDGE_NET:     int64 := 16;      // Netzwerk-Sockets
pub con PLEDGE_PROC:    int64 := 32;      // Prozessverwaltung (kill, nice …)
pub con PLEDGE_ALL:     int64 := 63;      // die sechs oben
pub con PLEDGE_DISPLAY: int64 := 65536;   // Bildspeicher beanspruchen (sys_fb_map)
pub con PLEDGE_DEVICE:  int64 := 131072;  // MMIO abbilden, PCI lesen (Tier-1-Treiber)
pub con PLEDGE_CONFIG:  int64 := 262144;  // persistente Konfiguration SCHREIBEN

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

Perspektivisch teilt Lyx OS den Adressraum in drei Domänen. Zwei davon gibt es, eine ist Entwurf:

Die frühere Angabe „heute läuft ausschließlich die Shell als Ring-3-Prozess“ ist überholt: In Ring 3 laufen inzwischen der Compositor als Startziel, seine Fenster, 42 Werkzeuge in /bin, zwei Treiber und der Compiler selbst. Die Wartungs-Shell ist die Rückfallebene, nicht mehr der Normalfall.

Was die Trennung heute schon leistet und was nicht: Der Kernel hält jeden Prozess an seiner Maske fest — ein LBF ohne Manifest bekommt nur PLEDGE_STDIO. Was er nicht leistet: das Manifest ist eine Selbstauskunft, und für Tier-1-Treiber wird keine Isolationsgarantie nach außen behauptet. Die Grenzen stehen im Treibermodell.

Letzte Aktualisierung: 2026-08-27 — Abschnitt 1 als „Die zwei Ringe„ neu geschrieben (was in Ring 0 und Ring 3 läuft, die beiden Prozesstabellen, SMP-Rollen); PLEDGE-Liste um DISPLAY/DEVICE/CONFIG ergänzt samt Hinweis, dass PLEDGE_ALL sie nicht enthält; Abschnitt 7 auf den Stand gebracht. Erhoben aus kernel/kernel.lyx, ring3.lyx, sched_ring3.lyx, sched_types.lyx, drv.lyx.

Vorherige Aktualisierung: 2026-06-25