SafeFFI: Sicherheit an der Grenze zwischen Safe und Unsafe

Rusts unsafe-Blöcke sind die Stelle, an der das Sicherheitsmodell seine Garantien verliert. Sie sind notwendig — für FFI, Speicherallokation, Hardware-Zugriff — aber sie sind auch die Quelle der meisten Sicherheitslücken in Rust-Programmen. Drei aktuelle Forschungsarbeiten zeigen, wie man diese Grenze sicherer macht.

SafeFFI: Checks nur dort, wo sie nötig sind

SafeFFI (2025) adressiert ein grundlegendes Problem: Sanitizer (wie AddressSanitizer) fügen Memory-Safety-Checks ein, um unsafe-Code zu überwachen. Aber sie instrumentieren alle Memory-Accesses, auch die, die der Rust-Typsystem bereits als sicher bewiesen hat. Das führt zu massivem Overhead — oft 2- bis 10-fach langsamer.

SafeFFI optimiert das: es platziert Checks nur an der Grenze zwischen safe und unsafe — also genau dort, wo unsafe-Code in safe-Code übergeht oder umgekehrt. Innerhalb von safe-Code (wo der Borrow Checker garantiert, dass alles sicher ist) werden keine Checks benötigt.

// Ohne SafeFFI: Sanitizer instrumentiert jeden Zugriff
unsafe fn raw_process(buf: *mut u8, len: usize) {
    for i in 0..len {
        // AddressSanitizer: Check bei jedem *buf[i]
        // Overhead: O(n) Checks, obwohl safe-Code dies bereits garantiert
        *buf.add(i) = transform(*buf.add(i));
    }
}

// Mit SafeFFI: Check nur an der Grenze
fn safe_wrapper(buf: &mut [u8]) {
    // SafeFFI: ein Check an der Grenze (ist buf gültig?)
    // Danach: keine weiteren Checks — der Borrow Checker übernimmt
    for byte in buf.iter_mut() {
        *byte = transform(*byte);
    }
}

Das Ergebnis: der Safety-Overhead sinkt dramatisch, ohne dass Sicherheitsgarantien verloren gehen.

Die Safe/Unsafe-Grenze verstehen

In Rust gibt es zwei Welten:

Safe Rust: Der Borrow Checker garantiert Speichersicherheit zur Compile-Zeit. Keine Runtime-Checks nötig.
Unsafe Rust: Der Programmierer ist verantwortlich. Keine Compile-Zeit-Garantien. Runtime-Checks (Sanitizer) werden gebraucht.

Die Grenze dazwischen ist kritisch: wenn unsafe-Code einen Pointer an safe-Code übergibt, muss sichergestellt sein, dass der Pointer gültig ist. SafeFFI platziert genau dort den Check — und nirgendwo sonst.

Design Patterns in Rust-Backends

Benefits of Applying Software Design Patterns to Backend Rust Applications (2026) ist die erste systematische Untersuchung von Design Patterns in Rust. Design Patterns (wie Singleton, Factory, Observer, Strategy) wurden ursprünglich für objektorientierte Sprachen wie Java definiert. Aber Rust hat ein anderes Typsystem, keine Vererbung, und Ownership-Semantik. Wie funktionieren Patterns in Rust?

Die Studie untersucht drei repräsentative Komponenten von Produktions-Backends und zeigt:

Patterns verbessern Code-Qualität — auch in Rust, aber anders als in OO-Sprachen
Rusts Typsystem erzwingt einige Pattern-Invarianten zur Compile-Zeit — ein Vorteil, den Java/C# nicht haben
Einige Patterns sind in Rust unnötig — z. B. das Null-Object-Pattern, weil Rust Option<T> hat

// Strategy-Pattern in Rust: Traits statt Vererbung
trait PaymentStrategy {
    fn pay(&self, amount: u64) -> Result<(), PaymentError>;
}

struct CreditCard { number: String }
impl PaymentStrategy for CreditCard {
    fn pay(&self, amount: u64) -> Result<(), PaymentError> {
        // Kreditkartenlogik
        Ok(())
    }
}

struct PayPal { email: String }
impl PaymentStrategy for PayPal {
    fn pay(&self, amount: u64) -> Result<(), PaymentError> {
        // PayPal-Logik
        Ok(())
    }
}

// Nutzung: der Compiler stellt sicher, dass jede Strategy pay() implementiert
fn checkout(payment: &dyn PaymentStrategy, amount: u64) -> Result<(), PaymentError> {
    payment.pay(amount)
}

Das Strategy-Pattern in Rust nutzt Traits statt Vererbung — und der Compiler stellt zur Compile-Zeit sicher, dass jede Implementierung die pay-Methode hat. In Java würde das eine NullPointerException zur Laufzeit riskieren, wenn eine Implementierung vergessen wird.

GPU-Offload in Rust: Sicher und Portabel

GPU Offload in Rust: Portable, Safe, and Fast (2026) löst ein langwieriges Problem: GPU-Programmierung erfordert traditionell entweder herstellerspezifische DSLs (CUDA für NVIDIA, HIP für AMD) oder unsafe Raw-Pointer in Rust. Diese Arbeit präsentiert ein Zero-Overhead-Framework, das Rusts Ownership-Modell auf die GPU überträgt — ohne Vendor-Lock-in und ohne unsafe.

// GPU-Kernel in sicherem Rust (konzeptionell)
fn vector_add(a: &[f32], b: &[f32]) -> Vec<f32> {
    // Das Framework überträgt die Ownership-Semantik auf die GPU
    // Kein unsafe, kein manueller Speicher-Transfer
    a.iter().zip(b.iter()).map(|(&x, &y)| x + y).collect()
}
// Das Framework kompiliert dies für CUDA, HIP und Metal — portabel

Die Implikation: Rusts Sicherheitsmodell ist nicht auf die CPU beschränkt. Mit den richtigen Abstraktionen kann dieselbe Sicherheit auf der GPU gelten.

Was das für die Praxis bedeutet

Werkzeug/Konzept	Problem	Lösung
SafeFFI	Sanitizer-Overhead	Checks nur an der Safe/Unsafe-Grenze
Design Patterns	Code-Qualität in Backends	Patterns an Rusts Typsystem angepasst
GPU-Offload	GPU-Programmierung ohne unsafe	Zero-Overhead, multi-vendor, safe

Für Rust-Entwickler: nutzt Traits statt Vererbung für Patterns, vertraut dem Typsystem für Invarianten, und denkt an SafeFFI, wenn ihr unsafe für FFI nutzt.