Die Stabilisierung von async/await in Rust 1.39, zusammen mit dem in Version 1.33 eingeführten Pin-Typ, ermöglichte sichere selbstreferenzielle Strukturen, die für asynchrone Zustandsautomaten entscheidend sind. Diese Strukturen enthalten häufig interne Zeiger, die auf Daten verweisen, die von der Struktur selbst besessen werden, wie z.B. Puffer und aktive Ansichten in diese Puffer. Bei der Implementierung von manuellen Futures oder komplexen intrusiven Datenstrukturen müssen Entwickler auf einzelne Felder über Pin<&mut Self> zugreifen, wodurch der Bedarf an sicheren Projektionsmechanismen entsteht, die die Garantien des Speicherorts wahren.
Wenn eine Struktur über Pin gepinnt wird, garantiert der Compiler, dass ihre Speicheradresse während der Lebensdauer des Pins konstant bleibt, vorausgesetzt, der Typ implementiert nicht Unpin. Wenn die Struktur selbstreferenzielle Zeiger enthält, wie einen rohen Zeiger in einen internen Vektor, würde das Verschieben der Struktur diese Zeiger ungültig machen und zu schwebenden Referenzen führen. Ein naiver Projektilansatz, der einfach Pin<&mut Self> auf &mut Self dereferenziert, exponiert Felder für sicheren Rust-Code, der legal mem::swap oder mem::replace auf diesen Feldern aufrufen könnte, wodurch sie aus ihren gepinnten Speicherorten verschoben werden und die grundlegenden Pin-Verträge verletzt werden.
Sichere Projektion erfordert eine unsichere Umwandlung, die die Pinning-Invarianz wahrt: Wenn die übergeordnete Struktur !Unpin ist, muss die Feldprojektion Pin<&mut Field> anstelle von &mut Field zurückgeben, um das Verschieben zu verhindern. Die Implementierung muss garantieren, dass das Feld strukturell gepinnt ist, was bedeutet, dass der Zustand der Pinning-Status mit dem Zustand der übergeordneten Struktur verknüpft ist, typischerweise erreicht durch Zeigerarithmetik oder Pin::map_unchecked_mut. Für Felder, die Unpin implementieren, kann die Projektion sicher &mut Field zurückgeben, da diese Typen auch dann verschoben werden dürfen, wenn sie in gepinnten Daten geschachtelt sind, obwohl darauf geachtet werden muss, dass solche Verschiebungen andere selbstreferenzielle Felder nicht ungültig machen.
use std::pin::Pin; use std::marker::PhantomPinned; struct Buffer { data: [u8; 1024], cursor: *const u8, _pin: PhantomPinned, } impl Buffer { // Sichere Projektion auf das Datenfeld (Unpin) fn data_mut(self: Pin<&mut Self>) -> &mut [u8; 1024] { unsafe { &mut self.get_unchecked_mut().data } } // Projektion auf das Cursorfeld fn cursor(self: Pin<&mut Self>) -> *const u8 { unsafe { self.get_unchecked_mut().cursor } } }
Kontext
Wir entwickelten einen hochperformanten, null-kopierenden Parser für ein Finanzprotokoll, bei dem Nachrichten auf Teilbereiche eines wiederverwendbaren internen Puffers verweisen konnten. Der Zustand des Parsers musste über asynchrone I/O-Operationen hinweg aufrechterhalten werden, was bedeutete, dass die Struktur gepinnt werden musste, um selbstreferenzielle Zeiger auf den Puffer zu ermöglichen.
Problembeschreibung
Die Parser-Struktur hielt einen Vec<u8> Puffer und einen &[u8] Slice, der auf diesen Puffer verwies und die aktuelle Nachricht darstellte. Bei der Implementierung von Stream für diesen Parser empfängt die poll_next-Methode Pin<&mut Self>. Wir mussten den Puffer verändern (um mehr Daten zu lesen), während die Gültigkeit der Slice-Referenz aufrechterhalten wurde, was eine sorgfältige Feldprojektion erforderte.
Berücksichtigte Lösungen
Lösung A: Indexbasierte Adressierung
Anstatt einen Slice &[u8] zu speichern, speicherten wir (usize, usize) Indizes in den Vektor. Vorteile: Vollständig sicher, keine Pin-Komplexität, leicht umzusetzen. Nachteile: Laufzeit-Grenzprüfungs-Overhead, weniger ergonomische API erfordert manuelles Slicing bei jedem Zugriff, potenzielle Probleme mit Indexdesynchronisation.
Lösung B: Unsichere Pin-Projektion mit rohen Zeigern
Wir speicherten die Nachricht als rohen Zeiger *const u8 und Länge und implementierten manuelle Projektionsmethoden mit Pin::map_unchecked_mut, um auf den Puffer zuzugreifen, während das Zeigerfeld gepinnt blieb. Vorteile: Null-Kosten-Abstraktion, wahrt die Selbstreferenzialität, ermöglicht direkte Zeigerarithmetik. Nachteile: Erfordert unsafe-Codeblöcke, Risiko undefinierten Verhaltens, wenn Pin-Invarianten verletzt werden (z.B. bei falscher Implementierung von Unpin).
Lösung C: Nutzung der pin-project-Crate
Nutzung der Prozeduralen Makros zur automatischen Erstellung sicherer Projektionscodes. Vorteile: Ergonomisch, gut getestete Sicherheitsinvarianten, reduziert Boilerplate. Nachteile: Zusätzliche Abhängigkeit, makrogenerierter Code kann schwerer zu debuggen sein, geringfügige Kosten zur Kompilierzeit.
Gewählte Lösung und Ergebnis
Wir wählten Lösung B, um externe Abhängigkeiten in unserem eingebetteten Systemkontext zu vermeiden und eine explizite Kontrolle über das Speicherlayout aufrechtzuerhalten. Wir stellten sorgfältig sicher, dass die Struktur Unpin nicht implementierte, indem wir PhantomPinned hinzufügten und umfassende Miri-Tests schrieben, um die Pinning-Invarianten zu validieren. Das Ergebnis war ein Parser, der null-kopierende Semantiken mit keiner Allokation pro Nachricht erreichte und eine Durchsatzrate von 10Gbps ohne CPU-Sättigung aufrechterhielt.
Warum ist es unsound, Unpin für eine Struktur zu implementieren, die selbstreferenzielle Zeiger enthält?
Unpin signalisiert speziell, dass ein Typ selbst dann sicher bewegt werden kann, wenn er in Pin eingewickelt ist, was sicherem Code erlaubt, &mut T aus Pin<&mut T> mittels Methoden wie Pin::into_inner zu erhalten. Bei einer selbstreferenziellen Struktur ändert das Verschieben der Struktur die Speicheradresse ihrer Inhalte, wodurch alle internen Zeiger, die auf diese Inhalte verweisen, ungültig werden. Die Implementierung von Unpin würde sicherem Code erlauben, die Struktur während des Pins zu bewegen, wodurch die Sicherheitsgarantie, die Pin für asynchrone Laufzeiten bietet, verletzt würde und zu Use-after-free-Sicherheitslücken führen könnte. Daher müssen solche Strukturen PhantomPinned verwenden, um ausdrücklich von Unpin auszuschließen und unbeabsichtigte automatische Implementierungen zu verhindern.
Wie unterscheidet sich die Projektion für Enum-Varianten im Vergleich zu Strukturfeldern?
Viele Kandidaten gehen davon aus, dass die Projektionsmechanik für Enums und Strukturen identisch ist, aber Enums stellen einzigartige Herausforderungen dar, da der Diskriminant bestimmt, welche Variante aktiv ist. Die Projektion von Pin<&mut Enum> auf eine spezifische Variante erfordert die Sicherstellung, dass die Variante gepinnt bleibt, während auch verhindert wird, dass der Diskriminant sich ändert, da das Wechseln der Varianten die zugrunde liegenden Daten bewegen würde. Rust fehlt die stabile eingebaute Unterstützung für Variantenprojektion, da Diskriminant und Variantdaten Überlegungen zum Speicherlayout teilen; sichere Projektion erfordert unsicheren Code, der die aktive Variante sichert und garantiert, dass während des Pins keine Variantenwechsel stattfinden.
Welche Rolle spielt PhantomPinned bei der Verhinderung automatischer Trait-Implementierungen?
Anfänger übersehen oft, dass Rust Unpin automatisch für die meisten Typen implementiert, es sei denn, sie enthalten ausdrücklich !Unpin-Felder, was den enthaltenden Typ standardmäßig zu !Unpin machen würde. PhantomPinned ist ein nullgrößer Marker-Typ, der ausdrücklich als !Unpin definiert ist und als negative Implementierungsbedingung dient, wenn er in einer Struktur enthalten ist. Ohne diesen Marker, selbst wenn Entwickler unsicheren Projektion-Code schreiben, der annimmt, dass die Struktur unbeweglich ist, könnte der Compiler Unpin automatisch implementieren, wodurch sicherem Code erlaubt wird, die Struktur über Pin::into_inner_unchecked zu extrahieren und zu bewegen, wobei unsichere Invarianten verletzt werden und undefiniertes Verhalten aufgerufen wird.