Veröffentlichung von Rust 1.81. Hürden bei der Integration von Rust in den Linux-Kernel.

Die neueste Version der Programmiersprache Rust 1.81 wurde veröffentlicht. Rust, ursprünglich von Mozilla entwickelt, wird nun von der unabhängigen Non-Profit-Organisation Rust Foundation weitergeführt. Der Fokus der Sprache liegt auf sicherem Umgang mit Speicher und bietet Mechanismen für hohen Parallelismus bei der Ausführung von Aufgaben, ohne auf eine Garbage Collection oder umfangreiche Runtime zurückgreifen zu müssen; das Runtime-Management beschränkt sich auf grundlegende Initialisierungen und die Verwaltung der Standardbibliothek.

Die Speicherverwaltungsmethoden in Rust befreien Entwickler von Fehlern beim Umgang mit Zeigern und schützen vor Problemen, die durch die Programmierung auf niedriger Ebene entstehen, wie z.B. den Zugriff auf freigegebenen Speicher, Dereferenzierung von Nullzeigern, Pufferüberläufe usw. Zur Verteilung von Bibliotheken, zur Gewährleistung des Builds und zum Management von Abhängigkeiten wird der Paketmanager Cargo entwickelt. Für die Bereitstellung von Bibliotheken wird das Repository crates.io unterstützt.

Die sichere Handhabung von Speicher in Rust wird während der Kompilierung durch die Überprüfung von Referenzen, das Verfolgen des Besitztums von Objekten, das Management der Lebensdauer von Objekten (Sichtbarkeitsbereiche) und die Bewertung der Korrektheit des Zugriffs auf den Speicher zur Laufzeit sichergestellt. Rust bietet außerdem Mechanismen zum Schutz vor ganzzahligen Überläufen, erfordert die verpflichtende Initialisierung von Variablenwerten vor der Verwendung, behandelt Fehler in der Standardbibliothek effektiver, implementiert das Konzept der Unveränderlichkeit (immutable) von Referenzen und Variablen standardmäßig und bietet eine starke statische Typisierung zur Minimierung logischer Fehler.

Hauptneuheiten:

• Der Trait core::error::Error wurde stabilisiert, um einheitliche Fehlerbeschreibungen zu definieren. Diese Änderung ermöglicht die Verwendung eines einheitlichen Error-Traits über verschiedene Bibliotheken hinweg, unabhängig von der Umgebung, einschließlich solcher Bibliotheken, die nicht an die Standardbibliothek gebunden sind und das Attribut „#![no_std]“ verwenden.
• In der Standardbibliothek wurden stabile und instabile Sortierfunktionen auf die Verwendung neuer Algorithmusmodelle umgestellt, die eine höhere Geschwindigkeit und kürzere Kompilierzeiten demonstrieren. Bei der Implementierung der neuen Sortieralgorithmen wird festgestellt, ob falsche Typen von Ord definiert sind, und in solchen Fällen wird ein Fehler (panic) ausgegeben, anstelle von zufällig gruppierten Daten.
• Im Linter wurde eine neue Prüfungsstufe "expect" ("#[expect(lint)]") implementiert, mit der sichergestellt werden kann, dass eine Überprüfung durchgeführt wird und eine Warnung ausgegeben wird, wenn die Prüfung fehlschlägt (aufgrund eines Implementierungsfehlers oder einer deaktivierten Überprüfung). Beispielsweise kann beim Umstieg der Codebasis auf die Verwendung der Prüfung undocumented_unsafe_blocks über Clippy "#[expect(clippy::undocumented_unsafe_blocks)]" angegeben werden, um sicherzustellen, dass während des Übergangs alle unsicheren Blöcke dokumentiert werden. In Clippy wurden zudem Prüfungen für clippy::allow_attributes und clippy::allow_attributes_without_reason implementiert, die den Austausch der "#[allow]" Attribute durch "#[expect(lint)]" vereinfachen.
• Die Dokumentation der Gründe für den Austausch von Prüfstandards (lint) wurde hinzugefügt, um neuen Entwicklern Informationen über die Gründe für die Einführung bestimmter Prüfungen bereitzustellen, die als Compiler-Nachricht ausgegeben werden. Beispielsweise: #![deny(clippy::float_arithmetic, reason = «kein Hardware-Float-Support»)]
• Eine neue Reihe von APIs wurde stabilisiert und in die stabile Version überführt, einschließlich stabilisierter Methoden und Implementierungen von Traits:
  • core::error
  • hint::assert_unchecked
  • fs::exists
  • AtomicBool::fetch_not
  • Duration::abs_diff
  • IoSlice::advance
  • IoSlice::advance_slices
  • IoSliceMut::advance
  • IoSliceMut::advance_slices
  • PanicHookInfo
  • PanicInfo::message
  • PanicMessage

  Das „const“-Merkmal, das die Verwendung in jedem Kontext anstelle von Konstanten ermöglicht, wurde in den Funktionen angewendet:

  • char::from_u32_unchecked (Funktion)
  • char::from_u32_unchecked (Methode)
  • CStr::count_bytes
  • CStr::from_ptr

  Der Typ std::panic::PanicInfo wurde in std::panic::PanicHookInfo umbenannt (die Verwendung des alten Namens bleibt bestehen, wird jedoch in der nächsten Version zu einer Warnung führen). Der Typ core::panic::PanicInfo bleibt unverändert, wird jedoch als separater Typ weiterentwickelt. Die Trennung der Typen ermöglicht die Implementierung unterschiedlicher Methoden, die speziell für die Ausführung im Kontext von snd und no_std geeignet sind.

• Der Übergang zu ABI C-unwind ('extern «C-unwind»') wurde abgeschlossen, der sich von ABI ohne das Suffix '-unwind' ('extern «C»') dadurch unterscheidet, dass sicheres Verhalten (safe) beibehalten wird, wenn der 'Unwind'-Prozess, der bei einem unerwarteten Programmabbruch oder bei der Erzeugung einer Ausnahme im C++-Stil initiiert wird, die ABI-Grenze überschreitet (zum Beispiel, wenn eine Ausnahme, die im Code einer Programmiersprache auftritt, beim Unwinding den Stack berührt, der mit dem Code einer anderen Programmiersprache verbunden ist). Seit der Veröffentlichung von Rust 1.81 löst ABI 'extern «C»' bei nicht abgefangenen Unwinds einen unerwarteten Abbruch aus.
• Der dritte Unterstützungsgrad wurde für die Plattformen i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf umgesetzt. Der dritte Grad bedeutet grundlegende Unterstützung, jedoch ohne automatisierte Tests, Veröffentlichung offizieller Builds und Überprüfung der Compilefähigkeit von Code.
• Der zweite Unterstützungsgrad für die Zielplattformen loongarch64-unknown-linux-musl und arm64ec-pc-windows-msvc wurde realisiert. Der zweite Unterstützungsgrad garantiert die Buildfähigkeit.
• Für Linux-Systeme auf LoongArch-Plattformen wird ein vollständiges Toolset und ein Profiler bereitgestellt.
• Eine Schwachstelle (CVE-2024-43402) in std::process::Command wurde behoben, die ausschließlich auf der Windows-Plattform auftritt und einen Ausweg für die Ausnutzung einer zuvor behobenen Schwachstelle namens BatBadBut bietet. Diese hing mit der Verarbeitung spezieller Zeichen bei der Verwendung von Command::arg und Command::args zusammen, die zur direkten Übergabe von Argumenten an den Prozess ohne Verarbeitung durch die Shell gedacht sind. Tatsächlich wurde beim Ausführen von bat- und cmd-Skripten der Prozess cmd.exe gestartet, der eine eigene Logik zur Argumenttrennung hat. Der Umgehungsschutz beruht darauf, dass Windows führende Leerzeichen und Punkte in Pfaden entfernt, d.h. eine Datei mit der Erweiterung „.bat. .“ wird als „.bat“ verarbeitet.

Darüber hinaus kann der Rücktritt von Wedson Almeida Filho als Projektbetreuer für Rust for Linux hervorgehoben werden, der sich mit der Integration von Werkzeugen zur Entwicklung in der Programmiersprache Rust in den Linux-Kernel beschäftigt. Nach Wedsons Ausscheiden verbleiben zwei Betreuer im Projekt: Miguel Ojeda, Autor und Hauptentwickler des Rust-for-Linux-Projekts, und Alex Gaynor, ehemaliger Direktor der Python Software Foundation, der sich nun auf die Förderung von Rust konzentriert. Der zurückgetretene Betreuer ist Mitarbeiter von Microsoft und Autor eines experimentellen Treibers mit Implementierung des EXT2-Dateisystems, der in Rust geschrieben wurde. In letzter Zeit lag Wedsons Fokus auf der Entwicklung von Werkzeugen für die Erstellung von Dateisystemen in Rust. In diesem Jahr hat Almeida 17 Commits zum Rust-for-Linux-Repository beigesteuert (zum Vergleich hat Miguel Ojeda 53 Commits hinzugefügt).

Die Gründe für den Rückzug liegen in einem Mangel an Kraft und Enthusiasmus, die einst für die Reaktion auf einige nicht-technische Belange wichtig waren. Almeida ist der Meinung, dass Entwickler viel Energie in Diskussionen über unwichtige Fragen investieren, die das übergeordnete globale Ziel in den Hintergrund drängen. Almeida bleibt überzeugt, dass die Zukunft der Kernel in der Nutzung von Programmiersprachen liegen wird, die einen sicheren Umgang mit Speicher gewährleisten. Wenn die Linux-Entwicklergemeinschaft dies nicht erkennt, wird Linux von einem anderen Kernel verdrängt werden, so wie es einst mit Unix geschah.

Die Befürworter des Rust-for-Linux-Projekts sehen sich dem Widerstand erfahrener Kernel-Entwickler gegenüber, die den Bedarf, eine neue Sprache zu lernen, nicht erkennen. In seinem Rücktrittsschreiben verweist Almeida auf eine Diskussion, die während seines Vortrags zusammen mit Kent Overstreet auf der Konferenz „Linux Storage, Filesystem, Memory-Management, and BPF Summit“ stattfand und die Verwendung von Rust zur Entwicklung von Dateisystemen diskutierte. Ted Ts’o, der Entwickler der Dateisysteme ext2/ext3/ext4, kritisierte die Bemühungen zur Einführung von Rust und verglich die Initiative Rust-for-Linux mit dem Versuch, alle dazu zu bringen, die Religion Rust anzunehmen.

In Bezug auf die Absicht von Almeida, eine Wrapper-Lösung für die in der Programmiersprache C geschriebenen Dateisystem-Interfaces zu schaffen, um diese im Rust-Code zu verwenden, wies Ted Zhou darauf hin, dass eine solche Wrapper-Lösung zwangsläufig zu Problemen führen wird. Jedes Ändern der C-Interfaces und jede Refaktorierung würden Anpassungen an dem Wrapper für Rust erfordern, und er möchte keine zusätzliche Verantwortung für die Behebung auftretender Probleme im Rust-Code und die Überwachung des Zustands des Rust-Wrappers übernehmen. Der C-Code entwickelt sich ständig weiter, und wenn dessen Änderungen die Funktionalität des Wrappers für Rust beeinträchtigen, würde dies auch die Funktionalität aller an diesen Wrapper gebundenen Dateisysteme beeinträchtigen.

Ted ist ebenfalls der Meinung, dass die Bindungen für Rust in naher Zukunft eine untergeordnete Rolle spielen werden und Probleme in den Bindungen nur für die Entwickler von Rust-for-Linux eine Herausforderung darstellen, nicht für die Gemeinschaft der Dateisystementwickler im Kernel. Es wurde darauf hingewiesen, dass nicht alle Entwickler vorhaben, Rust zu lernen, und daher nach Änderungen, die anderen Code beeinflussen, nur den abhängigen Code in C aktualisieren können, jedoch die Rust-Bindungen nicht reparieren können, da sie Rust nicht kennen. An der Diskussion beteiligte sich auch James Bottomley, der die SCSI-Subsystem betreut, und er sagte, dass je mehr Semantik in den Bindungen kodiert wird, desto fragiler sie aus Sicht der Synchronisierung werden.

In der Zwischenzeit hat Google, das im letzten Jahr die Firmware pvmfm in Rust neu geschrieben hat, die in virtuellen Maschinen wurde vereinfacht., die auf der Android-Plattform gestartet werden, teilte Erfahrungen über die schrittweise Einführung von Rust-Code in bestehende Firmware, die ursprünglich in C oder C++ geschrieben wurde. Es wird gezeigt, wie die Sicherheit der Firmware erheblich erhöht werden kann, indem funktional identische Ersatzkomponenten in Rust geschrieben werden. Bei der Einführung von Rust sollte der Fokus auf der Nutzung von Rust für neuen Code und für sicherheitskritische Funktionen liegen (z. B. Code zur Verarbeitung externer Daten aus nicht vertrauenswürdigen Quellen). Für die Integration von Rust- und C-Code werden Shims vorgeschlagen, die die Aufrufe zwischen Rust- und C-APIs übersetzen (C-API wird zur Verwendung im Rust-Code exportiert und umgekehrt), was eine schrittweise Neuschreibung von API-Elementen in Rust ermöglicht.

Quelle: opennet.ru