Betriebssysteme mit Rust entwickeln: Die 5 größten Herausforderungen

Die Idee, ein Betriebssystem in Rust zu schreiben, klingt verlockend: Speichersicherheit ohne Garbage Collection, Leistungsstärke und moderne Spracheigenschaften. Doch wer sich an ein solches Projekt wagt, stößt schnell auf fundamentale Probleme, die selbst erfahrene Entwickler vor Rätsel stellen. Nach Jahren der Arbeit an einem von Grund auf neu entwickelten Betriebssystem in Rust sind hier die fünf größten Herausforderungen – und wie sie sich lösen lassen.

Rusts unsafe-Problem: Der Kernel lebt gefährlich

Ein Kernel muss direkt mit Hardware interagieren, Speicher verwalten und Interrupts verarbeiten. Das bedeutet, dass unsafe-Code nicht die Ausnahme, sondern die Regel ist. Doch genau hier beginnt das Problem: Ein einziger unsicherer Block kann den gesamten Kernel destabilisieren, wenn unsauberer Code darauf aufbaut.

Warum unsafe unvermeidbar ist

In Benutzerprogrammen lässt sich unsicherer Code oft hinter klar definierte Schnittstellen verstecken. Im Kernel ist das anders: Der Scheduler, der Speicherallokator und die Interrupt-Handler arbeiten alle auf einer niedrigen Ebene, wo unsafe unverzichtbar ist. Selbst vermeintlich sichere Annahmen können hier fatale Folgen haben. Ein Fehler im Seitanfall-Handler kann das gesamte System zum Absturz bringen.

Lösungsansatz: unsafe als kontrollierte Fähigkeit behandeln

Statt unsafe zu verteufeln, sollte es als bewusste Entscheidung mit klaren Verantwortlichkeiten behandelt werden:

• Jede unsafe-Funktion benötigt einen ausführlichen // SAFETY:-Kommentar, der die Garantien der Funktion dokumentiert. Beispiel:

/// SAFETY: Die Adresse `addr` muss eine gültige MMIO-Adresse für dieses 
/// Gerät sein, 4-Byte-aligned und der Aufrufer muss das Gerätesperre halten.
pub unsafe fn mmio_write(addr: *mut u32, value: u32) {
    addr.write_volatile(value);
}

• Statische Assertionen wie const_assert! helfen, Invarianten bereits zur Kompilierzeit zu prüfen.
• Hardwarezugriffe sollten in einem dedizierten hal-Crate isoliert werden, doch der Rest des Kernels benötigt weiterhin unsafe für Kernoperationen.

Speicherallokation: Ein Henne-Ei-Problem

Moderne Programmiersprachen bieten flexible Allokatoren wie Vec, Box oder Arc. Doch für deren Nutzung wird ein globaler Allokator benötigt – der wiederum von einem Lock abhängt. Dieses Lock wiederum benötigt einen funktionierenden Scheduler. Und der Scheduler benötigt Speicherallokation. Ein klassisches Henne-Ei-Problem.

Warum frühe Allokation scheitert

Viele Entwickler warten darauf, „später“ einen Allokator zu implementieren. Doch bereits während des Bootvorgangs werden dynamische Datenstrukturen benötigt, etwa um eine initiale Freiliste für den Speicher zu erstellen. Wer hier auf spätere Implementierungen setzt, scheitert an der Realität.

Zweiphasige Allokation als Lösung

Die Lösung liegt in einer klaren Trennung der Phasen:

1. Bootstrap-Allokator: Ein einfacher Bump-Allokator, der vor dem Locking-Mechanismus und dem Scheduler läuft. Er kann allokieren, aber nicht freigeben. Der Code ist bewusst minimalistisch:

// Bootstrap-Allokator: Nur Zeigerbewegung
static mut BOOT_HEAP_START: usize = 0;
static mut BOOT_HEAP_OFFSET: usize = 0;

pub unsafe fn boot_alloc(size: usize) -> *mut u8 {
    let ptr = (BOOT_HEAP_START + BOOT_HEAP_OFFSET) as *mut u8;
    BOOT_HEAP_OFFSET += size;
    ptr
}

1. Echter Allokator: Sobald Scheduler und Spinlocks funktionieren, wird der Bootstrap-Allokator durch einen vollwertigen Allokator wie einen Buddy- oder Slab-Allokator ersetzt. Dies geschieht über das #[global_allocator]-Attribut und den alloc-Crate.

Interrupt-Handler: Wenn der Stack zum Feind wird

Interrupt-Handler laufen zwischen den Anweisungen eines Programms. Sie dürfen nicht blockieren, nicht allokieren und müssen extrem schnell sein. In Rust kommt erschwerend hinzu, dass Paniks nicht erlaubt sind, da ein Abwickeln des Stacks die unterbrochene Ausführung korrumpieren würde.

Die Gefahr von Paniks

Jeder Aufruf von unwrap() oder expect() in einem Interrupt-Handler ist riskant – selbst Debug-Assertionen, die potenziell panisch werden könnten, sind gefährlich. Ein einfacher Fehler kann das gesamte System zum Absturz bringen.

Sichere Interrupt-Handler implementieren

Die Lösung besteht in einer Kombination aus Assembler und Rust:

• Interrupt-Handler werden mit #[naked] markiert oder durch Assembler-Wrapper geschützt, die Register sichern und wiederherstellen.
• Die eigentliche Handler-Funktion in Rust ist mit extern "C" deklariert und darf niemals panisch werden.
• Das Attribut #![deny(unsafe_op_in_unsafe_fn)] erzwingt eine sorgfältige Prüfung des Codes.

Beispiel für einen x86_64-Interrupt-Handler:

#[naked]
extern "C" fn double_fault_handler() {
    unsafe {
        asm!(
            "push rax; push rcx; push rdx; ...",
            options(noreturn)
        );
        // Aufruf des sicheren Rust-Handlers
    }
}

Im sicheren Rust-Handler wird lediglich protokolliert und das System angehalten – ohne jede Möglichkeit eines Stack-Abbaus.

Parallelität: Spinlocks und die Herausforderung der Mehrkern-Systeme

Spinlocks erscheinen einfach: Solange eine Sperre gesetzt ist, wird in einer Schleife gewartet. Doch sobald mehrere Kerne im Spiel sind und der Scheduler Prozesse unterbrechen kann, wird die Sache komplex.

Warum einfache Spinlocks scheitern

Auf einem Einzelkern-System blockiert ein endlos laufender Spinlock das gesamte System. Auf Mehrkern-Systemen führt ein fehlender Schutzmechanismus zu Deadlocks, wenn etwa ein Interrupt-Handler dieselbe Sperre zu nutzen versucht.

Lösung: Phasenweise Implementierung

Die Implementierung von Spinlocks sollte in zwei klar getrennten Phasen erfolgen:

1. Phase 1 (Einzelkern, kein Scheduler): Spinlocks deaktivieren Interrupts, um Deadlocks zu vermeiden. Die Sperre wird durch eine einfache atomare Operation realisiert:

pub struct IrqSpinlock {
    lock: AtomicBool,
    data: UnsafeCell<()>, // Platzhalter für gesperrte Daten
}

impl IrqSpinlock {
    pub fn lock(&self) -> IrqGuard {
        let flags = disable_interrupts();
        while self.lock.swap(true, Ordering::Acquire) {
            enable_and_wait(flags);
            flags = disable_interrupts();
        }
        IrqGuard { lock: self, flags }
    }
}

1. Phase 2 (Mehrkern, Scheduler aktiv): Hier kommen vollwertige Mutexe zum Einsatz, die wartende Threads in eine Park-Schleife versetzen, anstatt sie endlos zu beschäftigen.

Das Kern-Trio: Allokator, Scheduler und Sperren im Gleichgewicht

Die Abhängigkeiten zwischen Allokator, Scheduler und Sperren sind eng verknüpft: Der Scheduler benötigt eine Liste wartender Prozesse, die in einem Vec gespeichert ist. Der Vec benötigt einen Allokator. Der Allokator benötigt Sperren. Und die Sperren benötigen den Scheduler, um bei Konflikten zu weichen.

Warum unabhängige Implementierung scheitert

Jeder Versuch, diese Komponenten unabhängig voneinander zu entwickeln, scheitert an der zyklischen Abhängigkeit. Die Lösung liegt in einer expliziten Schichtung der Abhängigkeiten und der Akzeptanz von temporären Bootstrap-Stubs.

Empfohlener Implementierungsansatz

1. Bootstrap-Phase: Kein Scheduler, keine vollwertigen Sperren. Stattdessen wird ein Bump-Allokator ohne Sperrmechanismen genutzt und eine statische Liste von Prozessen in einem &'static mut-Array verwaltet.

1. Initialisierungsphase: Ein einfacher Round-Robin-Scheduler wird implementiert, der mit dem Bump-Allokator arbeitet. Sperren werden zunächst als einfache atomare Variablen umgesetzt.

1. Vollständige Implementierung: Erst wenn diese Grundlagen stabil laufen, werden komplexere Allokatoren, echte Mutexe und ein priorisierter Scheduler eingeführt.

Fazit: Geduld zahlt sich aus

Ein Betriebssystem in Rust zu schreiben, ist ein ambitioniertes Unterfangen, das Entwickler vor unvorhergesehene Herausforderungen stellt. Doch wer die Fallstricke kennt und systematisch angeht, kann ein robustes und sicheres System schaffen. Die größten Hürden – unsafe-Code, Speicherallokation, Interrupt-Handler, Parallelität und zyklische Abhängigkeiten – sind lösbar. Der Schlüssel liegt in einer schrittweisen Implementierung, klaren Schnittstellen und der Bereitschaft, temporäre Kompromisse einzugehen. Mit jedem Meilenstein wird der Kernel robuster – und die anfänglichen Zweifel weichen dem Stolz auf eine funktionierende, moderne Systemsoftware.