Release Rust 1.96. Einschätzung der Eignung von Rust zur Erstellung von Firmware für Mikrocontroller.

Die Programmiersprache Rust 1.96 wurde veröffentlicht. Ursprünglich von Mozilla entwickelt, wird sie nun unter der Aufsicht der unabhängigen gemeinnützigen Organisation Rust Foundation weiterentwickelt. Die Sprache konzentriert sich auf die sichere Handhabung von Speicher und bietet Mittel zur Erreichung hoher Parallelität bei der Verarbeitung von Aufgaben, ohne auf einen Garbage Collector oder ein Runtime-System zurückgreifen zu müssen (das Runtime-System beschränkt sich auf die grundlegende Initialisierung und die Unterstützung der Standardbibliothek).

Die Methoden zur Arbeit mit dem Speicher in Rust zielen darauf ab, Fehler beim Manipulieren von Zeigern zu vermeiden und Probleme zu schützen, die aus der niedrigstufigen Arbeit mit Speicher resultieren können, wie z. B. den Zugriff auf Speicherbereiche nach deren Freigabe, das Dereferenzieren von Nullzeigern, das Überlaufen von Buffern usw. Zur Verbreitung von Bibliotheken und zur Verwaltung von Abhängigkeiten wird der Paketmanager Cargo entwickelt. Der Repository-Service crates.io unterstützt die Bereitstellung von Bibliotheken.

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:

• Das Modul range wurde hinzugefügt, das neue Typen implementiert, die dazu dienen, die veralteten Typen Range, RangeInclusive, RangeToInclusive und RangeFrom zu ersetzen. Diese neuen Typen ermöglichen die Speicherung von Bereichen in Copy-Strukturen. Der Typ Range definiert Bereiche, die durch den minimalen und maximalen zulässigen Wert begrenzt sind (letzteres jedoch nicht einschließend), während der Typ RangeFrom Zahlen ab einem bestimmten Wert definiert. Der Typ RangeInclusive umfasst die Werte des angegebenen Bereichs einschließlich beider Grenzen. Zukünftige Versionen werden zusätzliche Typen wie RangeFull und RangeTo einführen, und die alte Implementierung wird in core::range::legacy::* übertragen, während die Syntax "N..M" auf den neuen Typen umgestellt wird.

  Die neuen Typen unterscheiden sich darin, dass sie anstelle des Trait Iterator den Trait IntoIterator implementieren, d.h. sie definieren, wie der Typ in einen Iterator umgewandelt wird, anstatt einen eingebauten Iterator zu verwenden. Dieser Ansatz ermöglicht die Verwendung der Kopieroperation mit neuen Typen (Trait Copy, der zeigt, dass Werte des Typs durch einfaches Kopieren dupliziert werden können), die zuvor aufgrund von Inkompatibilität mit Typen mit eingebauten Iteratoren nicht verfügbar war.
  Zum Beispiel ermöglichen neue Typen, die Grenzen eines Slices in einer Struktur zu speichern, die vollständig kopiert wird, ohne die Anfangs- und Endwerte separat speichern zu müssen:

  use core::range::Range;

  #[derive(Clone, Copy)]
  pub struct Span(Range);

  impl Span {
  pub fn of(self, s: &str) -> &str {
  &s[self.0]
  }
  }

• Die Makros „assert_matches!“ und „debug_assert_matches!“ wurden hinzugefügt, um die Übereinstimmung eines Wertes mit einem angegebenen Muster zu überprüfen und die Ausführung bei Abweichungen sofort zu beenden. Die neuen Makros unterscheiden sich von den Ausdrücken „assert!(matches!(..))“ und „debug_assert!(matches!(..))“ durch die Ausgabe von Debugging-Informationen mit den Werten, die den Fehler verursacht haben. Um Überschneidungen mit Drittanbieter-Makros zu vermeiden, die ähnliche Namen haben, erfordern die neuen Makros den expliziten Import der Bibliothek „core::assert_matches“.

  use core::assert_matches;

  fn get_random_number() -> u32 {
  4
  }

  fn main() {
  assert_matches!(get_random_number(), 1..=6);
  }

• Beim Bauen für die Zielplattform WebAssembly wurde die Übergabe der Linker-Option „—allow-undefined“ eingestellt, die das Binden bei vorhandenen undefinierten Symbolen erlaubte, die in das Modul „env“ umgewandelt wurden. Beim Bauen für WebAssembly müssen jetzt standardmäßig alle mit dem Linken verbundenen Symbole definiert sein. Um das alte Verhalten wiederherzustellen, kann die Umgebungsvariable „RUSTFLAGS=-Clink-arg=—allow-undefined“ oder der Ausdruck ‘#[link(wasm_import_module = „env“)]’ im Code verwendet werden.
• Eine neue Reihe von APIs wurde stabilisiert und in die stabile Version überführt, einschließlich stabilisierter Methoden und Implementierungen von Traits:
  • assert_matches!
  • debug_assert_matches!
  • From for AssertUnwindSafe
  • From for LazyCell
  • From for LazyLock
  • core::range::RangeToInclusive
  • core::range::RangeToInclusiveIter
  • core::range::RangeFrom
  • core::range::RangeFromIter
  • core::range::Range
  • core::range::RangeIter
• Im Paketmanager Cargo wurde die Sicherheitsanfälligkeit CVE-2026-5223 behoben, die ausgenutzt werden kann, um den Quellcode eines anderen crate-Pakets im lokalen Paket-Cache desselben Repositories durch Manipulation von symbolischen Links innerhalb des crate zu überschreiben. Die Sicherheitsanfälligkeit tritt nur beim Arbeiten mit externen Paket-Repositories auf und betrifft nicht die Nutzer des Repositories crates.io, da das Hochladen von Paketen mit symbolischen Links in crates.io verboten ist.

Zusätzlich kann die Veröffentlichung (PDF) der Ergebnisse einer Analyse zur Eignung der Programmiersprache Rust für die Entwicklung von Firmware für Mikrocontroller und eingebettete Systeme mit eingeschränkten Ressourcen hervorgehoben werden.
Die Studie wurde von STMicroelectronics in Zusammenarbeit mit mehreren europäischen Universitäten durchgeführt. Zwei isolierten Entwicklerteams wurde die Aufgabe gestellt, die gleiche Firmware für Mikrocontroller STM32U585AI mit Arm Cortex-M33-Kern zu implementieren. Das erste Team entwickelte die Firmware in C, das zweite in Rust.

Die Tests der abgeschlossenen Arbeit zeigten keine nennenswerten Vorteile bei der Verwendung von C gegenüber Rust für die Entwicklung von Firmware für Mikrocontroller, wenn man den Speicherverbrauch und die Leistung vergleicht. Darüber hinaus ermöglichte die Nutzung des in Rust geschriebenen systemweiten Runtimes des Open-Source-Projekts Ariel OS, einen niedrigeren Speicherverbrauch im Rust-Projekt im Vergleich zur C-Implementierung, die einen traditionellen Stack auf Basis der newlib-Bibliothek verwendete.

Die Größe der resultierenden Firmware betrug 84100 Byte im Rust-Projekt und 76744 Byte im C-Projekt (10% weniger), aber der Speicherverbrauch in der Rust-Firmware war deutlich niedriger — 24640 Byte gegenüber 42608 Byte. Bei der Leistung zeigte die Rust-Implementierung während der Tests von frühen Prototypen, die in 6 Wochen entwickelt wurden, eine doppelt so hohe Leistung wie die C-Implementierung, aber beide Implementierungen lagen deutlich unter der berechneten maximalen Leistung. Nach 4 Wochen, die für die Optimierung aufgewendet wurden, erreichten beide Implementierungen einen ungefähr gleichen Wert, der nahe am berechneten Maximum lag.

Quelle: opennet.ru