Utgivning av Rust 1.81. Hinder för att främja Rust i Linux-kärnan

Utgivningen av programmeringsspråket Rust 1.81, som ursprungligen utvecklades av Mozilla men nu drivs av den oberoende ideella organisationen Rust Foundation, har publicerats. Språket fokuserar på säker minneshantering och tillhandahåller verktyg för hög grad av parallell exekvering av uppgifter, utan att använda skräpinsamlare eller runtime (runtime är begränsat till grundläggande initialisering och underhåll av standardbiblioteket).

Minneshanteringsmetoderna i Rust skyddar utvecklare från att göra fel vid manipulering av pekare och skyddar mot problem som uppstår vid låg nivå minnesarbete, såsom att komma åt minnesområden efter att de har frigjorts, dereferera nullpekare, buffer overflow, etc. För distribution av bibliotek, byggande och hantering av projektberoenden utvecklas paketförvaltaren Cargo. För lagring av bibliotek stöds ett repository på crates.io.

Säker minneshantering säkerställs i Rust under kompilering genom att kontrollera referenser, spåra ägandeskap över objekt, ta hänsyn till livslängden av objekt (synlighet) och utvärdera korrekt minnesåtkomst under körning av koden. Rust erbjuder också verktyg för att skydda mot heltalsöverflöden, kräver obligatorisk initialisering av variabelvärden innan de används, hanterar fel bättre i standardbiblioteket, tillämpar konceptet av oföränderliga (immutable) referenser och variabler som standard och erbjuder stark statisk typning för att minimera logiska fel.

Huvudsakliga nyheter:

• Typen core::error::Error har stabiliserats och definierar de felbeskrivningar som skrivs ut. Denna ändring gör det möjligt att använda en enhetlig typ av Error i olika bibliotek, oavsett miljö, inklusive bibliotek som inte är kopplade till standardbiblioteket och använder attributet «#![no_std]».
• Stabila och ostabila sorteringsfunktioner i standardbiblioteket har översatts till att använda nya algoritmer som visar högre prestanda och kortare kompilerings tid. I implementeringen av de nya sorteringsalgoritmerna säkerställs det att felaktigt definierade typer av Ord identifieras och att fel (panic) i sådana fall rapporteras istället för att data grupperas slumpmässigt.
• I lint-programmet har en ny nivå av kontroll «expect» («#[expect(lint)]») implementerats, vilket gör att man kan försäkra sig om att kontrollen utförs och att ett varningsmeddelande visas om kontrollen inte uppfylls (till följd av ett fel i implementeringen eller avstängning av kontrollen). Till exempel, vid övergången av kodbasen till att använda kontrollen undocumented_unsafe_blocks via Clippy kan man ange «#[expect(clippy::undocumented_unsafe_blocks)]» för att säkerställa att alla unsafe-block dokumenteras under övergången. Clippy har också infört kontrollerna clippy::allow_attributes och clippy::allow_attributes_without_reason, vilket förenklar byte av attributen «#[allow]» till «#[expect(lint)]».
• Möjligheten att dokumentera orsaken till ändringar av kontrollnivåer (lint) har tillhandahållits, vilket ger nya utvecklare information om orsaken till att en viss kontroll har lagts till och som skrivs ut som ett meddelande från kompilatorn. Till exempel: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
• En ny uppsättning API har blivit stabiliserad, inklusive stabilisering av metoder och implementeringar av 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

  Beteckningen «const», som definierar möjligheten att använda det i vilken kontext som helst istället för konstanter, används i funktioner:

  • char::from_u32_unchecked (funktion)
  • char::from_u32_unchecked (metod)
  • CStr::count_bytes
  • CStr::from_ptr

  Typen std::panic::PanicInfo har omdöpts till std::panic::PanicHookInfo (den gamla namnet är fortfarande i bruk, men från nästa version kommer användningen att resultera i en varning). Samtidigt kommer core::panic::PanicInfo att förbli oförändrat, men utvecklas som en separat typ. Typdelning möjliggör implementering av olika metoder specifika för att köra i kontexten av snd och no_std.

• Övergången till ABI C-unwind (‘extern «C-unwind»‘) har slutförts, vilket skiljer sig från ABI utan suffixet «-unwind» (‘extern «C»‘) genom att bevara säkert beteende (safe) om processen av ‘unwinding’, som initieras vid programkrasch eller undantag i C++-stil, korsar ABI-gränsen (t.ex. när ett undantag som inträffat i koden på ett språk påverkar stacken relaterad till koden på ett annat språk). Från och med Rust-version 1.81 utlöses en programkrasch i ABI ‘extern «C»‘ vid icke fångad ‘unwinding’.
• Tredje nivå av stöd har implementerats för plattformarna i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Tredje nivån innebär grundläggande stöd men utan automatiserad testning, publicering av officiella byggen och verifiering av möjligheten att bygga koden.
• Andra nivån av stöd har implementerats för de målplattformarna loongarch64-unknown-linux-musl och arm64ec-pc-windows-msvc. Den andra nivån av stöd garanterar byggprocessen.
• För Linux-system på LoongArch-plattformen har komplett verktygssats och profileringsverktyg tillhandahållits.
• En sårbarhet (CVE-2024-43402) i std::process::Command, som endast uppträder på Windows-plattformen, har åtgärdats och eliminerar en attackvektor för utnyttjande av tidigare åtgärdad sårbarhet BatBadBut, relaterad till hantering av specialtecken vid användning av anrop av Command::arg och Command::args, avsedda för direkt överföring av argument till processen utan bearbetning av kommandotolk. Vid körning av bat- och cmd-skript kördes processen cmd.exe, vilken har sin egen logik för att separera argument. Skyddsomgången baseras på att Windows tar bort ledande blanksteg och punkter i sökvägar, dvs. en fil med förlängning «.bat. .» behandlas som «.bat».

Dessutom kan man notera att Wedson Almeida Filho har lämnat sin post som projektledare för Rust for Linux, som syftar till att införa verktyg för utveckling av Rust i Linux-kärnan. Efter Wedsions avhopp finns det två kvarvarande projektledare — Miguel Ojeda, skapare och huvudutvecklare av Rust-for-Linux-projektet, och Alex Gaynor, tidigare chef för Python Software Foundation, som nu fokuserar på att främja Rust. Den avgående projektledaren, som gick med i projektet för fyra år sedan, är anställd hos Microsoft och författare till en experimentell drivrutin som implementerar EXT2-filsystemet, skriven i Rust. På senare tid har Almeida fokuserat på att skapa utvecklingsverktyg för filsystem i Rust. I år har Almeida bidragit med 17 commits till Rust-for-Linux-repoet (till jämförelse har Miguel Ojeda lagt till 53 commits).

Som orsak till sin avgång nämner han brist på energi och entusiasm, som en gång var nödvändig för att bemöta viss icke-teknisk nonsens. Enligt Almeida tvingas utvecklarna lägga ner mycket kraft på argumentation kring oväsentliga frågor som gör att de mer viktiga globala målen går förlorade. Almeida fortsätter att tro att framtiden för kärnor ligger i användningen av språk som möjliggör säkert minneshantering, och om Linux-utvecklarsamhället inte förstår detta, kommer Linux att konkurreras ut av en annan kärna, precis som Unix en gång blev.

Stödet för Rust-for-Linux-projektet har stött på motstånd från etablerade utvecklare av kärnan som inte ser behovet av att lära sig ett nytt språk. I sitt avgångsbrev nämner Almeida ett exempel från en diskussion som ägde rum under hans och Kent Overstreets presentation vid konferensen "Linux Storage, Filesystem, Memory-Management, and BPF Summit", som handlade om att använda Rust för utveckling av filsystem. Ted Ts'o, skaparen av ext2/ext3/ext4-filsystemen, kritiserade initiativet att implementera Rust, och jämförde det med att försöka tvinga alla att anta Rust som en religion.

Som svar på Almeida's avsikt att skapa ett wrapper för de C-språksbaserade filsystemens gränssnitt för att användas i Rust-kod, påpekade Ted Tso att en sådan wrapper oundvikligen skulle leda till problem, eftersom varje förändring av C-gränssnitten och refaktoriseringen skulle kräva en förändring av wrappern för Rust, och han vill inte ta på sig det extra ansvaret för att åtgärda uppkomna problem i Rust-koden och för att övervaka tillståndet för Rust-wrappern. C-koden utvecklas ständigt, och om dess förändring stör wrappern för Rust, skulle det leda till problem för alla filsystem beroende av denna wrapper.

Ted anser också att en wrapper för Rust under överskådlig framtid kommer att förbli sekundär och att problem i bindningarna kommer att vara ett huvudvärk endast för Rust-for-Linux-utvecklare, snarare än för gemenskapen av filsystemutvecklare i kärnan. Det påpekas att inte alla utvecklare är villiga att lära sig Rust och därför, efter att ha gjort förändringar som påverkar annan kod, bara kan uppdatera den beroende C-koden, men inte kan åtgärda Rust-wrappern eftersom de inte känner till Rust. Diskussionen inkluderade också James Bottomley, som stöder SCSI-underavsnittet, som sa att ju mer semantik som kodas i wrappers, desto mer ömtåliga blir de när det gäller att säkerställa synkronisering.

Under tiden har Google, som förra året omskrev pvmfm-firmware i Rust, som används i virtuella maskiner, som körs på Android-plattformen, delade med sig av erfarenheter kring gradvis integrering av kod skriven i Rust i befintliga firmware, som ursprungligen skrevs i C eller C++. Det visades hur man kan avsevärt öka säkerheten i firmware genom att skapa funktionellt identiska komponent-byten, skrivna i Rust. Huvudfokus vid införandet av Rust bör ligga på att använda Rust för ny kod och kod som utför kritiska funktioner ur säkerhetssynpunkt (till exempel kod för hantering av externa data som kommer från osäkra källor). För integration av Rust- och C-kod föreslås det att använda shim-lager som översätter anrop mellan Rust- och C-API (C-API exporteras för användning i Rust-kod och vice versa), vilket möjliggör en gradvis omskrivning av API-element till Rust.

Källa: opennet.ru