Vor Rust 1.36 verliteten Entwickler sich auf std::mem::uninitialized, um Stapelspeicher für Werte zu reservieren, die später initialisiert werden würden. Diese Funktion war grundsätzlich unsicher, da sie dem Compiler mitteilte, dass ein gültiges T an dieser Speicherstelle existierte, obwohl die Bits zufällig waren. Bei Typen mit Sicherheitsinvarianten—wie bool, char oder Referenzen—führte dies zu unmittelbarem undefiniertem Verhalten, da der Compiler basierend auf der Annahme optimierte, dass der Wert gültig war (z. B. dass ein bool 0 oder 1 war). RFC 1892 führte MaybeUninit<T> als eine unionsähnliche Abstraktion ein, um explizit Speicher zu kennzeichnen, der noch kein gültiges T enthält, und damit dieses Sicherheitsloch zu schließen.
Das Kernproblem ergibt sich aus LLVM's Behandlung von uninitialisiertem Speicher als undef oder poison, verbunden mit der automatischen Generierung von Drop-Gleitmitteln in Rust. Wenn der Compiler glaubt, dass eine Variable des Typs T aktiv ist, kann er Destruktoraufrufe oder Nischenoptimierungen ausführen. Wenn T ein bool ist, könnte ein uninitialisiertes Byte den Wert 2 haben, was die Bitgültigkeitsinvarianz verletzt. Das Lesen während der Drop-Prüfung oder der Diskriminatorinspektion stellt undefiniertes Verhalten dar. Darüber hinaus, wenn die Initialisierung während eines Arrays fehlschlägt, wird das Drop-Gleitmittel für den Array-Typ versuchen, alle Elemente zu löschen, wobei uninitialisierte Stapelbytes als Zeiger interpretiert werden, was zu Use-After-Free- oder Double-Free-Fehlern führt.
MaybeUninit<T> fungiert als typisierter Container, der möglicherweise ein gültiges T enthält oder nicht. Dadurch wird verhindert, dass der Compiler von der Initialisierung ausgeht, wodurch die Emission von Drop-Gleitmitteln und ungültigen Bitmusteroptimierungen unterbunden wird. Der Programmierer muss manuell nachverfolgen, welche Instanzen initialisiert sind, typischerweise über einen separaten Index oder ein boolesches Array. Um einen Wert zu extrahieren, verwendet man assume_init, assume_init_ref oder std::ptr::read, jedoch nur nachdem bewiesen wurde, dass ein gültiges T über write oder Zeigermanipulation geschrieben wurde. Die kritische Invarianz ist, dass assume_init niemals auf Speicher aufgerufen werden darf, der nicht vollständig initialisiert ist, und wenn eine teilweise initialisierte Struktur aufgegeben wird, muss der Programmierer nur die initialisierten Elemente manuell mit ptr::drop_in_place ablegen, um Ressourcenausfälle zu vermeiden.
use std::mem::{self, MaybeUninit}; use std::ptr; fn init_array_fallible<T, E, const N: usize>( mut f: impl FnMut(usize) -> Result<T, E>, ) -> Result<[T; N], E> { let mut array: [MaybeUninit<T>; N] = unsafe { MaybeUninit::uninit().assume_init() }; let mut i = 0; while i < N { match f(i) { Ok(val) => { array[i].write(val); i += 1; } Err(e) => { for j in 0..i { unsafe { ptr::drop_in_place(array[j].as_mut_ptr()); } } return Err(e); } } } Ok(unsafe { mem::transmute::<[MaybeUninit<T>; N], [T; N]>(array) }) }
Sie entwickeln einen no_std Kernel-Treiber für eine Netzwerkschnittstellenkarte, bei der die Heap-Allokation verboten ist und die Latenz deterministisch sein muss. Sie müssen eine feste Tabelle von 1024 Connection-Objekten im Stapelspeicher reservieren. Jede Initialisierung von Connection beinhaltet einen Hardwareregisterschreibvorgang, der fehlschlagen kann, wenn der NIC-Puffer voll ist. Die Herausforderung besteht darin, sicherzustellen, dass, wenn die 500. Verbindung fehlschlägt, die vorherigen 499 korrekt geschlossen werden (Dateideskriptoren ablegen und DMA-Zuordnungen freigeben), während die verbleibenden 524 Slots unberührt bleiben, um undefiniertes Verhalten beim Ablegen von uninitialisiertem Speicher zu vermeiden.
Ein möglicher Ansatz besteht darin, Default::default() zu verwenden, um das Array mit Sentinel-Werten vorab zu initialisieren. Dies erfordert, dass Connection Default implementiert, was problematisch ist, da eine "Standard"-Verbindung dennoch Kernelressourcen erwerben würde, die explizit freigegeben werden müssen, was den Fehlerpfad kompliziert. Darüber hinaus verschwenden 1024 Dummy-Verbindungen nur zum Überschreiben Initialisierungszyklen und verletzen die strengen Zeitvorgaben des Treibers zum Hochfahren der Schnittstelle.
Eine zweite Strategie verwendet Vec<Connection> mit with_capacity und dynamischem Pushen, gefolgt von der Konvertierung in ein festes Array. Dies ist sicher und idiomatisch im Benutzerspeicher. Allerdings erfordert Vec einen globalen Allokator, der in diesem Kernel-Kontext nicht verfügbar ist. Es führt auch potenzielle Panic-Pfade und Speicherfragmentierung ein, die im Kernel-Speicher inakzeptabel sind, und die Konvertierung in ein Array fester Größe erfordert Laufzeitüberprüfungen, die die Fehlerbehandlung komplizieren.
Der dritte Ansatz nutzt MaybeUninit<[Connection; 1024]>, um den Speicher ohne Initialisierung zu reservieren. Erfolgreich initialisierte Verbindungen werden über MaybeUninit::write geschrieben, und wenn ein Fehler an Index i auftritt, iterieren wir manuell von 0 bis i-1 und rufen ptr::drop_in_place auf jedem initialisierten Slot auf, bevor wir den Fehler zurückgeben. Bei Erfolg transmutieren wir das gesamte Array in den initialisierten Typ. Wir haben diese Lösung gewählt, weil sie nullkosten Stack-Allokation mit deterministischer Leistung bietet, die no_std-Beschränkung erfüllt und sicherstellt, dass die Ressourcenbereinigung nur für tatsächlich initialisierte Objekte erfolgt. Das Ergebnis war ein robuster Treiber, der niemals undefiniertes Verhalten während der teilweise fehlerhaften Wiederherstellung aufrief und konsistente Mikrosekunden-Niveau-Initialisierungslatenzen aufrechterhielt.
Warum stellt der Aufruf von assume_init auf einem uninitialisierten MaybeUninit<T> undefiniertes Verhalten dar, selbst wenn der Wert danach nie explizit gelesen wird?
Viele Kandidaten glauben, dass undefiniertes Verhalten nur auftritt, wenn Sie auf die Daten physisch zugreifen, wie z.B. sie zu drucken oder darauf zu verzweigen. Allerdings informiert Rust's Typsystem den Compiler, dass ein gültiges T existiert, sobald assume_init aufgerufen wird. Für Typen mit Nischenoptimierungen (wie bool, char, Option<&T>, oder NonNull<T>) kann der Compiler Code generieren, der das Bitmuster inspiziert, um Enum-Varianten oder Gültigkeit zu bestimmen. Wenn der Speicher zufällige Bits enthält (z.B. 0xFF für ein bool), wird diese Inspektion undefiniertes Verhalten in LLVM auslösen (Laden von poison oder undef). Darüber hinaus fügt der Compiler, wenn der Geltungsbereich endet, Drop-Gleitmittel für das T ein, das versucht, Destruktoren für Mülldaten auszuführen, was zu Abstürzen oder Sicherheitsanfälligkeiten führen kann. Daher ist assume_init ein Vertrag, bei dem der Programmierer eine gültige Initialisierung garantiert; dessen Verletzung vergiftet den Zustand des Compilers, unabhängig von expliziten Lesevorgängen.
Was ist der Unterschied zwischen der Verwendung von MaybeUninit::write und std::ptr::write auf dem Zeiger, der von MaybeUninit::as_mut_ptr() zurückgegeben wird, und wann ist jede angemessen?
MaybeUninit::write ist eine sichere Methode, die das Eigentum an einem T übernimmt und es in den uninitialisierten Slot schreibt, wobei ein veränderlicher Verweis auf die nun initialisierten Daten zurückgegeben wird. Sie ist bevorzugt, wenn Sie den Wert bereit haben und sofortigen sicheren Zugriff wünschen. Im Gegensatz dazu ist std::ptr::write eine unsichere Funktion, die einen Wert an einen Rohzeiger schreibt, ohne den alten Wert zu lesen oder abzulegen (was kritisch ist, da der Speicher uninitialisiert ist). Sie müssen ptr::write verwenden, wenn Sie durch einen Rohzeiger schreiben, der von as_mut_ptr() erhalten wurde und die Einschränkungen des Ausleiheprüfers von write umgehen müssen, oder wenn Sie niedrigere Abstraktionen implementieren, bei denen Sie nur Rohzeiger haben. Der Hauptunterschied besteht darin, dass write Sicherheitsgarantien und Lebensdauern verfolgt, während ptr::write manuelle Überprüfungen erfordert, dass das Ziel gültig, ordnungsgemäß ausgerichtet und uninitialisiert ist, um Alias-Verletzungen oder vorzeitige Löschungen zu vermeiden.
Wie kann man korrekt ein teilweise initialisiertes Array von MaybeUninit<T> ablegen, ohne Ressourcen zu verschwenden oder undefiniertes Verhalten auszulösen, und warum ist die Reihenfolge der Vorgänge kritisch?
Wenn die Initialisierung an Index i fehlschlägt, müssen Sie nur die Elemente 0..i ablegen. Das korrekte Verfahren besteht darin, von 0 bis i-1 zu iterieren und std::ptr::drop_in_place(array[j].as_mut_ptr()) aufzurufen. Dies führt den Destruktor für T aus, ohne den Wert aus dem MaybeUninit-Wrapper zu bewegen (was den Slot in einen Zustand verschieben würde, obwohl er technisch immer noch uninitialisiert ist). Es ist entscheidend, diese Bereinigung sofort bei einem Fehler durchzuführen, bevor der Fehler zurückgegeben wird, um sicherzustellen, dass der Stapelrahmen sauber aufgelöst wird. Wenn Sie stattdessen versucht hätten, mem::forget auf das Array anzuwenden oder einfach zurückzukehren, würde der MaybeUninit-Wrapper abgelegt werden (ein No-Op), jedoch würden die lebenden T-Instanzen ihren Ressourcen (wie Datei-Handles oder Heap-Speicher) entgehen. Andererseits, wenn Sie versehentlich die Elemente i..N ablegen würden, würden Sie undefiniertes Verhalten hervorrufen, indem Sie Müllspeicher als gültige T-Instanzen behandeln.