# Osum-Kernel — was fehlt zum modernen Kern (Recherche 29.08.2026)

Grundlage: eigene Tiefenrecherche (5 Sub-Agenten, Quellen im Text) + gemessener Bestand.
Bestand heute: 139.062 Zeilen Kernel, 70 Module, Abbild 2,8 MB, Boot 941 ms unter KVM.
Scheduler = gewichtetes Round-Robin mit GLOBALER Aufgabentabelle. I/O = synchron
("read block n / write block n"). Fensterserver und alle Treiber IM Kernel. Kein poll.

---

## 1. TREIBERABSTUERZE — nicht Mikrokernel, sondern NEUSTARTBARKEIT

Der Vollumbau zum Mikrokernel ist NICHT der richtige Weg. Kosten der Isolation, gemessen:
seL4-IPC-Fastpath 300-600 Zyklen one-way, realistisch 1000-2000 Zyklen (0,3-0,7 us) pro
Request/Reply; dazu Adressraumwechsel mit TLB-/Cache-Verlust (1-3 us ohne PCID) und
KPTI-artige Kosten (schnellster Syscall von <130 auf bis zu 660 Zyklen). Bei 10k Ops/s
egal, bei 1M Ops/s (NVMe, 10GbE) toedlich. Isolationskosten skalieren mit der AUFRUFRATE.

**Was Windows, macOS und Linux stattdessen tun — und was wir uebernehmen:**
- **Windows TDR**: Watchdog je Auftrag (Standard 2 s), dann Engine-/Adapter-Reset, Kontexte
  werden verworfen, Programme bekommen DEVICE_REMOVED. >5 Resets in 60 s = Bugcheck.
- **Linux DRM**: Fence-Timeout, Engine- oder Voll-Reset per PCI-FLR, haengender Kontext
  wird "gebannt", andere ueberleben.
- **Windows UMDF / macOS DriverKit**: Protokoll- und Zustandslogik in den User-Space,
  im Kern bleiben nur Interrupt-Annahme, DMA-Mapping, Bus/Power. Apple hat KEXTs
  faktisch abgeschafft — starker Beleg, dass das traegt.
- **Kernsatz: nicht der CODE wird isoliert, sondern der AUFTRAG.**

**IOMMU ist die Voraussetzung, nicht die Kuer.** Ein Userspace-Treiber ohne IOMMU ist eine
Illusion: er kann dem Geraet jede physische Adresse als DMA-Ziel geben und schreibt damit
in Kernelcode oder Seitentabellen — an jeder MMU vorbei. Erst VT-d/AMD-Vi/SMMU mit
Interrupt-Remapping sperrt ihn wirklich ein. Map/Unmap kostet us -> vorab gemappte,
wiederverwendete DMA-Pools statt Mapping pro I/O.

**Aufteilung, die sich in der Praxis bewaehrt hat:**
| Klasse | wohin | Grund |
|---|---|---|
| USB-Geraete (HID, Audio, Drucker, Storage-Klasse) | User-Space | ms-Latenz, hohe Fehlerdichte |
| GPU / Compositor | geteilt: Submission+Speicher im Kern, Rest aussen | Compiler sind die Hauptabsturzquelle |
| WLAN | geteilt: MLME aussen, Datenpfad im Kern | 802.11-Timing ist hart |
| Dateisysteme (ausser Wurzel) | User-Space | Korrektheit vor Durchsatz, FUSE kostet 2-4x |
| NIC | Kern oder Poll-Mode mit geteiltem Ring | 10GbE = 14,88 Mpps, kein IPC pro Paket moeglich |
| Timer, IRQ, Scheduler, MMU, Bus, NVMe-Pfad | zwingend Kern | Sub-us-Latenz |

**Treiber-Neustart technisch (5 Schritte):** Fehlererkennung per Watchdog/IOMMU-Fault ->
Geraet stilllegen (FLR, Bus-Master aus, IRQ maskieren, DMA-Mappings ENTFERNEN, bevor
Speicher frei wird — sonst Use-after-free durch laufendes DMA) -> Handles gehoeren dem
KERN, nicht dem Treiber, Auftraege werden gepuffert -> Zustand nur zwei Klassen erlaubt:
rekonstruierbar oder verwerfbar -> neuer Prozess, DMA-Pools neu mappen, Warteschlange
abarbeiten, Clients bekommen DEVICE_RESET.

**Urteil: 80 % der Stabilitaet fuer ~10 % des Mikrokernel-Aufwands.**

---

## 2. I/O — die groesste Luecke. Completion statt Readiness.

Heute: synchron, kein poll, kein aio, kein Ring. Das ist die schwerste Altlast, die wir
uns selbst gebaut haben — und sie ist JETZT noch billig zu beheben.

**Warum completion-basiert (io_uring/IOCP) und nicht readiness-basiert (epoll):**
readiness braucht 2 Syscalls pro Operation, hat TOCTOU-Rennen und funktioniert fuer
regulaere Dateien gar nicht (die sind immer "bereit"). Completion ist eine Primitive fuer
Platte, Socket, Timer und Metadaten zugleich, erlaubt Buendelung, Verkettung und
Zero-Copy-Benachrichtigung. **Readiness laesst sich auf Completion abbilden, umgekehrt nicht.**

**Zahlen (Linux, NVMe/Optane, 4K random read, ein Kern):**
klassisches pread 0,5-0,7 M IOPS · libaio 1,2 M · io_uring mit Polling und festen
Puffern 1,7-3,5 M. Latenz 2-3 us statt 6-10 us. Gegenueber epoll bei Netzlast 10-40 %
mehr Anfragen/s.

**Polling vs. Interrupt:** ein Interrupt kostet 1-3 us. Unterhalb ~10 us Geraetelatenz
gewinnt Polling (Optane, CXL); bei normalen TLC-SSDs (60-100 us) lohnt es nicht mehr.
Hybrid-Polling (erst schlafen, dann pollen) halbiert die CPU-Last bei gleicher Latenz.

**Aufbaureihenfolge, die die Recherche empfiehlt — und die Reihenfolge ist der Punkt:**
1. Objekt-Handles + Refcounting mit klarer asynchroner Lebensdauer, **Abbruch-Token von
   Anfang an**. Der teuerste io_uring-Fehler war nachtraeglich eingebautes Async.
2. Kernintern ALLES als request -> completion modellieren; das heutige synchrone
   "read block n" wird zum Sonderfall (abschicken + warten).
3. Ring-ABI: SQ/CQ im geteilten Speicher, feste versionierte Eintragsgroesse, explizite
   Speicherbarrieren, Rueckstau statt Verwerfen bei Ueberlauf.
4. Blockschicht mit Warteschlange je Kern, Completion auf dem abschickenden Kern.
5. Registrierte Puffer/Handles, DMA-Mapping-Cache, O_DIRECT-Pfad.
6. Netz: Multishot-Accept/Recv, Pufferringe; Zero-Copy erst danach.
7. POSIX-read/poll als duenne Schicht DARUEBER — nicht als zweiter Pfad daneben.

**Warnung aus der Praxis:** 2023 stammten laut Google rund **60 % der eingereichten
Linux-Kernel-Exploits aus io_uring**; Google hat es auf Android und ChromeOS deaktiviert.
Ursache ist die komplexe asynchrone Lebensdauer. Deshalb Punkt 1 zuerst, und
Sicherheits-Hooks pro Operation von Beginn an.

---

## 3. SCHEDULER — von globaler Liste zu pro-Kern

Heute: eine globale Aufgabentabelle mit gewichtetem Round-Robin (sched.fi, 1341 Zeilen).
Fair und ohne Verhungern, aber die globale Sperre ist ab **4-8 Kernen messbar** und ab
**8-16 Kernen der Flaschenhals** — darueber wird mehr Kern = weniger Durchsatz.
Cache-Line-Bouncing kostet 40-100 ns im selben L3, 150-400 ns ueber Sockel hinweg,
gegen ~1 ns bei L1-Treffer.

**Was moderne Kerne tun:**
- **EEVDF** (Linux seit 6.6): "Lag" = Rueckstand gegenueber dem fairen Anteil; nur wer
  Rueckstand hat, ist waehlbar. Virtuelle Frist vd = ve + slice/weight, es gewinnt die
  frueheste. **Kurze Zeitscheibe = automatisch niedrige Latenz, ohne Heuristik.**
  CFS' Interaktivitaets-Raterei entfaellt.
- **Windows**: 32 Stufen, Boosts bei I/O-Ende und Vordergrundfenster, Anti-Verhungern.
- **Apple**: QoS-Klassen steuern gleichzeitig Prioritaet, I/O-Drossel und Kernwahl.

**Reihenfolge fuer uns:** (1) Runqueue je Kern + Work-Stealing (nur bei leerer eigener
Liste, vom anderen Ende), (2) EEVDF-Auswahlregel statt gewichtetem RR, (3) Kapazitaets-
gewicht fuer heterogene Kerne, (4) Prioritaetsvererbung bei Sperren + tickless,
(5) RCU fuer ueberwiegend lesende Strukturen, (6) NUMA zuletzt.

**Heterogene Kerne (P/E, big.LITTLE) NICHT ignorieren:** sonst landen latenzkritische
Faeden auf E-Kernen (2-4x langsamer, Ruckler, Audio-Aussetzer), und gleiche Zeitscheibe
bedeutet auf ungleichen Kernen ungleiche Arbeit — die Fairness-Annahme bricht.
Minimalfix: Kapazitaetsgewicht je Kern, vruntime-Fortschritt entsprechend skalieren.

**"KI-gestuetztes Scheduling": zu 90 % Marketing.** Eine Entscheidung darf 100-500 ns
kosten, da passt kein neuronales Netz hinein. Echt ist ML nur auf langsamen Ebenen
(Platzierung, Frequenz, Cluster-Groesse). Fuer uns: irrelevant.

---

## 4. "KI-READY" — was das auf Kernebene wirklich heisst

Nicht Modelle im Kernel, sondern vier nuechterne Bausteine:

1. **mmap fuer Modelldateien** — der wichtigste Punkt. Modell per mmap statt laden:
   kein Kopieren, Start in Millisekunden, Gewichte liegen dateigestuetzt und SAUBER im
   Seiten-Cache — bei Speicherdruck werden sie verworfen und neu gelesen statt in den
   Auslagerungsbereich zu wandern. Mehrere Prozesse teilen dieselben Seiten.
2. **Grosse Seiten (2 MiB)**: ein 40-GB-Arbeitssatz braucht mit 4-KiB-Seiten ~10 Mio.
   Eintraege, der TLB fasst 1500-2500. 5-15 % Durchsatz haengen daran.
3. **Vektorregister im Kontextwechsel sichern (XSAVE)** — ohne das zerstoert der erste
   Interrupt die AVX-Register. Ohne AVX2/NEON-Dotprod verliert man Faktor 3-5.
4. **Speicherdruck statt OOM-Killer**: Auslagern ist bei Inferenz toedlich — ein
   Token-Schritt liest ALLE Gewichte sequenziell; landet ein Bruchteil auf SSD, faellt
   die Rate von ~15 auf <0,5 Token/s.

**Was CPU-Inferenz realistisch leistet** (Q4, ~50 GB/s RAM-Bandbreite, 8 Kerne):
TinyLlama 1,1B: 25-50 Token/s · Qwen 3B: 10-20 · Llama 8B: 5-10 · 70B: 0,5-1,5 (unbrauchbar).
Dekodieren ist bandbreitenbegrenzt: Token/s ~ Bandbreite / Modellgroesse.

**Beschleuniger — ehrlich:** In JEDEM Fall laeuft signierte, proprietaere Firmware auf dem
Geraet; "offen" endet an der Befehlswarteschlange. amdgpu allein ist ~5 Mio. Zeilen.
Einen GPU-Treiber selbst zu schreiben ist unrealistisch. Der einzige herstellerueber-
greifende offene Weg waere Vulkan Compute (20-40 % langsamer als CUDA).

**Kleinster sinnvoller Schritt:** 2-MiB-Seiten + mmap mit Bedarfsseiten + XSAVE im
Taskwechsel, dann ggml/llama.cpp als EIN Userspace-Prozess mit minimaler libc, 1B-Modell,
einfaedig. Erst danach SMP-Threadpool.

---

## 5. SICHERHEIT — was 2026 Pflicht ist

**Billig und alternativlos (Kosten ~0):**
- **NX / W^X** — keine ausfuehrbaren Datenseiten.
- **SMEP** — Kernel darf keinen Nutzercode ausfuehren (killt ret2usr).
- **SMAP** — Zugriff auf Nutzerdaten nur ausdruecklich (2 Instruktionen je Kopie).
- **Intel CET: IBT + Schattenstapel** (<1 %) — ROP praktisch tot. ARM: PAC+BTI (0,5-3 %).
- **IOMMU** — Pflicht, siehe Abschnitt 1.
- KCFI 1-2 %. KASLR ist auf x86 nur ~9 Bit und per Timing oft umgehbar — Kosmetik ohne
  Leck-Haertung.

**Capabilities statt uid/gid — und das ist eine Tag-1-Entscheidung:** uid ist "ambient
authority", jedes Programm erbt ALLE Rechte des Nutzers (Confused Deputy, setuid, Root als
einziger Fehlerpunkt). Eine Capability buendelt Objekt + Rechte in einem unfaelschbaren
Token; Fuchsia/Zircon hat deshalb kein globales open("/etc/shadow"). **Nachtraeglich nicht
einbaubar.** Passt exakt zu unserem Paketformat und den geplanten Programm-Rechten.

**Formale Verifikation (seL4):** ~8.700 Zeilen C brauchten ~200.000 Beweiszeilen und
20-25 Personenjahre = 2-3 Personenjahre je 1000 Zeilen. Nur fuer einen Kern <10k Zeilen
denkbar — fuer uns nicht.

**Rust vs. Firn:** Rust hat bei Android speicherbedingte Luecken von 76 % auf 24 % gedrueckt.
Firn mit GC deckt Use-after-free im Userland ab, ABER: im Kernprofil laeuft Firn ohne GC,
und GC im Kern ist grundsaetzlich problematisch (Pausen, Allokation im Interrupt-Kontext,
Objektverschiebung vs. DMA). Was uns gegenueber Rust fehlt, ist ein Ausleihenpruefer, der
Datenrennen zur Uebersetzungszeit ausschliesst.

**Boot ab Tag 1 vorsehen:** ein einziges signiertes Kernel+initrd-Abbild, Messkette in
TPM-PCRs, verity-geschuetzte Wurzel, Rollback-Zaehler, Attestierungs-Schnittstelle.
Nachruesten ist teuer, weil es das ganze Update- und Schluesselwesen betrifft.

---

## 6. VORGESCHLAGENE REIHENFOLGE (Kernel-Runden)

| # | Runde | Inhalt | warum jetzt |
|---|---|---|---|
| K-1 | **HANDLE** | Objekt-Handles mit Refcount, asynchrone Lebensdauer, Abbruch-Token | Fundament fuer ALLES weitere. Nachtraeglich = der teuerste io_uring-Fehler |
| K-2 | **ASYNC** | kernintern request->completion, synchron wird Sonderfall | die groesste Luecke |
| K-3 | **RING** | SQ/CQ im geteilten Speicher, Rueckstau, poll als Schicht darueber | ersetzt spaeter poll sauber |
| K-4 | **PERCPU** | Runqueue je Kern + Work-Stealing | globale Sperre kippt ab 8 Kernen |
| K-5 | **EEVDF** | Lag + virtuelle Frist statt gewichtetem RR | Desktop-Latenz ohne Heuristik |
| K-6 | **IOMMU** | VT-d/AMD-Vi, DMA-Pools, Interrupt-Remapping | Voraussetzung fuer alles Weitere |
| K-7 | **RESTART** | Watchdog je Auftrag, Geraet stilllegen, Treiber-Neustart, DEVICE_RESET | 80 % Stabilitaet fuer 10 % Aufwand |
| K-8 | **HARDEN** | NX/W^X, SMEP, SMAP, IBT+Schattenstapel | fast gratis, sofort wirksam |
| K-9 | **CAPS** | Capability-Modell statt reinem uid/gid | Tag-1-Entscheidung, nicht nachruestbar |
| K-10 | **AIMEM** | 2-MiB-Seiten, mmap mit Bedarfsseiten, XSAVE im Taskwechsel | kleinster echter Schritt Richtung KI |
| K-11 | **USERDRV** | USB- und Dateisystemtreiber in den User-Space | erst nach IOMMU sinnvoll |

Nicht auf der Liste, bewusst: Mikrokernel-Vollumbau, KI-Scheduler, eigener GPU-Treiber,
formale Verifikation. Begruendungen stehen oben.