Verze Rust 1.81. Překážky v pokroku Rustu v jádru Linuxu

Byla zveřejněna verze programovacího jazyka Rust 1.81, dříve vyvíjeného projektem Mozilla, nyní rozvíjeného pod záštitou nezávislé neziskové organizace Rust Foundation. Tento jazyk je zaměřen na bezpečné nakládání s pamětí a poskytuje prostředky pro dosažení vysokého paralelního zpracování úkolů, přičemž se obejde bez využití garbage collectoru a runtime (runtime se omezuje na základní inicializaci a údržbu standardní knihovny).

Metody práce s pamětí v Rustu zbavují vývojáře chyb při manipulaci s ukazateli a chrání před problémy, které vznikají z nízkoúrovňové manipulace s pamětí, jako je přístup k oblasti paměti po jejím uvolnění, dereferencování nulových ukazatelů, přetečení bufferu atd. Pro distribuci knihoven, zajištění sestavení a správu závislostí se vyvíjí balíčkový manažer Cargo. Pro hostování knihoven je k dispozici repozitář crates.io.

Bezpečné manipulace s pamětí jsou v Rustu zajištěny během kompilace prostřednictvím kontroly referencí, sledování vlastnictví objektů, zohlednění doby života objektů (viditelnosti) a hodnocení správnosti přístupu k paměti při vykonávání kódu. Rust také poskytuje prostředky pro ochranu proti přetečení celých čísel, vyžaduje povinnou inicializaci hodnot proměnných před použitím, lépe zpracovává chyby ve standardní knihovně, aplikuje koncept neměnnosti (immutable) referencí a proměnných ve výchozím nastavení a nabízí silnou statickou typizaci pro minimalizaci logických chyb.

Hlavní novinky:

• Byl stabilizován typ core::error::Error, který určuje výstupní popisy chyb. Tato změna umožňuje používat jednotný typ Error v různých knihovnách, nezávisle na prostředí, včetně knihoven, které nejsou vázány na standardní knihovnu, a používající atribut "#![no_std]".
• Stabilní i nestabilní funkce třídění ve standardní knihovně byly převedeny na nové algoritmy, které vykazují vyšší rychlost a kratší dobu kompilace. Při implementaci nových algoritmů třídění je zajištěno rozpoznání nesprávně definovaných typových tříd Ord a v takových případech je vyvolána chyba (panic) místo náhodně seskupených dat.
• V linteru byl implementován nový úroveň kontroly "expect" ("#[expect(lint)]"), která umožňuje ověřit splnění kontroly a vypsat varování, pokud kontrola nebyla splněna (kvůli chybě v implementaci nebo vypnutí kontroly). Například při migraci kódu na kontrolu undocumented_unsafe_blocks pomocí Clippy lze uvést "#[expect(clippy::undocumented_unsafe_blocks)]" pro zajištění, že během přechodu budou všechny unsafe bloky dokumentovány. V Clippy byly také zavedeny kontroly clippy::allow_attributes a clippy::allow_attributes_without_reason, usnadňující nahrazení atributů "#[allow]" za "#[expect(lint)]".
• Byla nabízena možnost dokumentování důvodů pro změnu úrovní kontroly (lint), poskytující novým vývojářům informace o důvodech přidání dané kontroly, vyjadřované jako zpráva kompilátoru. Například: #![deny(clippy::float_arithmetic, reason = "no hardware float support")]
• Nová sada API byla převedena do stabilního stavu, včetně stabilizovaných metod a implementací typů:
  • 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

  Znak „const“, určující možnost použití v jakémkoli kontextu místo konstant, je použit ve funkcích:

  • char::from_u32_unchecked (funkce)
  • char::from_u32_unchecked (metoda)
  • CStr::count_bytes
  • CStr::from_ptr

  Typ std::panic::PanicInfo byl přejmenován na std::panic::PanicHookInfo (funkčnost starého názvu je zachována, ale od další verze jeho použití povede k zobrazení varování). Typ core::panic::PanicInfo zůstane nezměněn, ale bude rozvíjen jako samostatný typ. Oddělení typů umožní implementaci různých metod specifických pro kontext snd a no_std.

• Byl dokončen přechod na ABI C-unwind (‘extern „C-unwind“‘), který se liší od ABI bez suffixu „-unwind“ ('extern „C“') zachováním bezpečného chování (safe), pokud proces „rozmotání“ (unwinding), iniciovaný při havárii programu nebo generování výjimky ve stylu C++, překročí hranici ABI (například když výjimka vzniklá v kódu jednoho programovacího jazyka při rozmotání zasáhne zásobník spojený s kódem jiného programovacího jazyka). Od verze Rust 1.81 je v ABI ‘extern „C“‘ zapojena havarijní ukončení při nechyceném rozmotání.
• Byla realizována třetí úroveň podpory pro platformy i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Třetí úroveň zahrnuje základní podporu, ale bez automatizovaného testování, vydávání oficiálních sestavení a ověřování možnosti sestavení kódu.
• Byla realizována druhá úroveň podpory cílových platforem loongarch64-unknown-linux-musl a arm64ec-pc-windows-msvc. Druhá úroveň podpory zaručuje sestavení.
• Pro Linuxové systémy na platformě LoongArch je k dispozici kompletní nástrojový řetězec a profiler.
• Byla odstraněna zranitelnost (CVE-2024-43402) ve std::process::Command, která se projevovala pouze na platformě Windows a odstraňuje obcházení dříve opravené zranitelnosti BatBadBut, související s zpracováním speciálních znaků při použití volání Command::arg a Command::args, určených pro přímý přenos argumentů procesu bez jejich zpracování příkazovým interpretem. Ve skutečnosti při spuštění bat- a cmd-skriptu byl spuštěn proces cmd.exe, který měl vlastní logiku rozdělování argumentů. Obejít ochranu je možné díky tomu, že Windows odstraňuje vedoucí mezery a tečky v cestách, tj. soubor s příponou „.bat. .“ je zpracován jako „.bat“.

Dále lze zmínit, že Wedson Almeida Filho opustil pozici správce projektu Rust for Linux, který se zabýval zaváděním nástrojů pro vývoj v jazyce Rust do jádra Linuxu. Po odchodu Wedsona zůstali u projektu ještě dva správci — Miguel Ojeda, autor a hlavní vývojář projektu Rust-for-Linux, a Alex Gaynor, bývalý ředitel organizace Python Software Foundation, který se přeorientoval na propagaci Rustu. Odcházející správce, který se k projektu připojil před 4 lety, je zaměstnancem společnosti Microsoft a autorem experimentálního ovladače s implementací souborového systému EXT2 napsaného v jazyce Rust. V poslední době se práce Almeidy soustředila na vytváření nástrojů pro vývoj souborových systémů v jazyce Rust. V tomto roce Almeida přidal do repozitáře Rust-for-Linux 17 commitů (pro srovnání Miguel Ojeda přidal 53 commitů).

Jako důvod odchodu je uváděn nedostatek sil a nadšení, které byly kdysi přítomny pro reagování na některé nesmysly netechnického charakteru. Podle Almeidy musí vývojáři vynakládat mnoho sil na spory o nepodstatné záležitosti, což odvádí pozornost od důležitějších globálních cílů. Almeida stále věří, že budoucnost jader spočívá v používání jazyků zajišťujících bezpečnou práci s pamětí, a pokud si komunita vývojářů Linux neuvědomí tuto skutečnost, Linux bude vytlačen nějakým jiným jádrem, jak se to kdysi stalo s Unixen.

Zastánci projektu Rust-for-Linux se potýkají s potřebou překonat odpor starších, renomovaných vývojářů kernelu, kteří nevidí důvod se naučit nový jazyk. Ve svém rezignačním dopise Almeida jako příklad uvádí odkaz na diskusi, která se konala během vystoupení Almeidy a Kenta Overstreeta na konferenci „Linux Storage, Filesystem, Memory-Management, and BPF Summit“, a která se věnovala použití Rustu pro vývoj souborových systémů. Aktivitu zavádění Rustu kritizoval Ted Ts’o, autor souborových systémů ext2/ext3/ext4, který srovnal iniciativu Rust-for-Linux s pokusem donutit všechny přijmout víru Rust.

V reakci na záměr Almeidy vytvořit obal nad rozhraními souborových systémů napsanými v jazyce C pro jejich použití v kódu v jazyce Rust, Ted Ts’o upozornil, že takový obal nevyhnutelně povede k problémům, protože jakákoli změna C-rozhraní a provedení refaktorování vyžadují změnu obalu pro Rust, a on nechce převzít zbytečnou odpovědnost za opravování vznikajících problémů v kódu v Rustu a sledování stavu Rust-obalu. Kód v C se neustále vyvíjí, a pokud jeho změna naruší funkčnost obalu pro Rust, povede to k narušení funkčnosti všech souvisejících souborových systémů.

Ted rovněž považuje, že v dohledné budoucnosti zůstane obal pro Rust druhotný a vznikající problémy v bindách budou hlavní bolestí pouze pro vývojáře Rust-for-Linux, nikoli pro komunitu vývojářů souborových systémů v kernelu. Bylo uvedeno, že ne všichni vývojáři mají v úmyslu se naučit Rust, a proto po provedení změn ovlivňujících jiný kód budou schopni aktualizovat pouze závislý kód v C, ale nebudou moci opravit Rust-obaly, protože Rust neznají. Diskuse se také zúčastnil James Bottomley, který spravuje subsystém SCSI, který řekl, že čím více sémantiky je zakódováno v obalech, tím více se stávají křehčími z pohledu zajištění synchronizace.

Mezitím společnost Google, která v loňském roce přepsala na jazyk Rust firmware pvmfm, používanou v virtual machines, běžící na platformě Android, sdílela zkušenosti s postupnou integrací kódu v jazyce Rust do stávajících firmware, původně napsaných v C nebo C++. Bylo ukázáno, jak lze výrazně zvýšit bezpečnost firmware vytvářením identických funkčních náhradních komponent napsaných v jazyce Rust. Hlavní důraz při zavádění Rustu je kladen na použití Rustu pro nový kód a kód, který vykonává funkce kritické z hlediska bezpečnosti (například kód pro zpracování externích dat získaných z nedůvěryhodných zdrojů). Pro integraci kódu v Rustu a C se doporučuje používat meziprocesory (shim), které překládají volání mezi API v Rustu a C (C API je exportováno pro použití v kódu v Rustu a naopak), což umožňuje postupné přepisování prvků API v Rustu.

Zdroj: opennet.ru