Vydanie Rust 1.81: Prekážky integrácie s jadrom Rust Linux

Bol vydaný univerzálny programovací jazyk Rust 1.81, založený projektom Mozilla, ale teraz vyvinutý pod záštitou nezávislej neziskovej organizácie Rust Foundation. Jazyk sa zameriava na bezpečnosť pamäte a poskytuje prostriedky na dosiahnutie vysokej paralelnosti úloh, pričom sa vyhýba používaniu zberača odpadu a runtime (beh je zredukovaný na základnú inicializáciu a údržbu štandardnej knižnice).

Metódy spracovania pamäte Rustu chránia vývojára pred chybami pri manipulácii s ukazovateľmi a chránia pred problémami, ktoré vznikajú v dôsledku nízkoúrovňového spracovania pamäte, ako je prístup k oblasti pamäte po jej uvoľnení, dereferencovanie nulových ukazovateľov, pretečenie vyrovnávacej pamäte atď. Na distribúciu knižníc, poskytovanie zostáv a správu závislostí projekt vyvíja správcu balíkov Cargo. Úložisko crates.io je podporované pre hosťovanie knižníc.

Bezpečnosť pamäte je v Rust zabezpečená v čase kompilácie prostredníctvom kontroly referencií, sledovania vlastníctva objektu, sledovania životnosti objektov (rozsahov) a hodnotenia správnosti prístupu do pamäte počas vykonávania kódu. Rust tiež poskytuje ochranu proti pretečeniu celých čísel, vyžaduje povinnú inicializáciu hodnôt premenných pred použitím, lepšie zvláda chyby v štandardnej knižnici, štandardne aplikuje koncept nemenných referencií a premenných, ponúka silné statické typovanie na minimalizáciu logických chýb.

Hlavné inovácie:

  • Vlastnosť core::error::Error, ktorá definuje zobrazované popisy chýb, bola stabilizovaná. Táto zmena vám umožňuje používať jednu vlastnosť Error v rôznych knižniciach, bez ohľadu na prostredie, vrátane knižníc, ktoré nie sú viazané na štandardnú knižnicu, pomocou atribútu „#![no_std]“.
  • Stabilné a nestabilné funkcie triedenia v štandardnej knižnici boli prevedené na používanie nových algoritmov, ktoré vykazujú vyšší výkon a kratšie časy kompilácie. Pri implementácii nových triediacich algoritmov je možné v takýchto prípadoch odhaliť nesprávne definované typy objednávok a namiesto náhodne zoskupených údajov vypísať chybu (panik).
  • Linter implementuje novú úroveň kontroly „expect“ („#[expect(lint)]“), ktorá vám umožňuje overiť, že kontrola bola dokončená, a zobraziť varovanie, ak kontrola nie je dokončená (kvôli chybe v implementácii alebo zakázanie kontroly). Napríklad pri migrácii kódovej základne na použitie Clippyho kontroly undocumented_unsafe_blocks môžete zadať „#[expect(clippy::undocumented_unsafe_blocks)]“, aby ste sa uistili, že všetky nebezpečné bloky budú počas prechodu zdokumentované. Clippy tiež implementuje kontroly clippy::allow_attributes a clippy::allow_attributes_without_reason, vďaka čomu je ľahké nahradiť atribúty „#[allow]“ atribútmi „#[expect(lint)]“.
  • Poskytuje sa možnosť zdokumentovať dôvod nahradenia úrovní kontroly (lint), čím sa novým vývojárom poskytnú informácie o dôvodoch pridania konkrétnej kontroly, ktoré sa vypíšu ako správa kompilátora. Napríklad: #![deny(clippy::float_arithmetic, reason = “žiadna podpora hardvéru float”)]
  • Nová časť API bola presunutá do kategórie stabilných, vrátane metód a implementácií vlastností boli stabilizované:
    • core::error
    • hint::assert_unchecked
    • fs::existuje
    • AtomicBool::fetch_not
    • Trvanie::abs_diff
    • IoSlice::advance
    • IoSlice::advance_slices
    • IoSliceMut::advance
    • IoSliceMut::advance_slices
    • PanicHookInfo
    • PanicInfo::správa
    • PanicMessage

    Atribút „const“, ktorý určuje možnosť jeho použitia v akomkoľvek kontexte namiesto konštánt, sa používa vo funkciách:

    • char::from_u32_unchecked (funkcia)
    • char::from_u32_unchecked (metóda)
    • CStr::count_bytes
    • CStr::from_ptr

    Typ std::panic::PanicInfo bol premenovaný na std::panic::PanicHookInfo (funkčnosť starého názvu je zachovaná, ale od ďalšej verzie bude jeho používanie viesť k varovaniu). V tomto prípade core::panic::PanicInfo zostane tak, ako je, ale bude sa vyvíjať ako samostatný typ. Oddelenie typov vám umožní v nich implementovať rôzne metódy, ktoré sú špecifické pre vykonávanie v kontexte snd a no_std.

  • Dokončený prechod na C-unwind ABI („externé „C-unwind“), ktoré sa líši od ABI bez prípony „-unwind“ („externé „C“) zachovaním bezpečného správania pri procese odvíjania ), ktorý sa spustí, keď program zlyhá alebo je vyvolaná výnimka v štýle C++, prekročí hranicu ABI (napríklad, keď sa výnimka vyvolaná v kóde v jednom programovacom jazyku uvoľní dotykom zásobníka spojeného s kódom v inom programovacom jazyku). Od vydania Rust 1.81 bolo „externé „C“ ABI povolené zlyhať pri nezistenom odvíjaní.
  • Tretia úroveň podpory bola implementovaná pre 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. Tretia úroveň zahŕňa základnú podporu, ale bez automatického testovania, zverejňovania oficiálnych verzií alebo kontroly, či je možné kód zostaviť.
  • Bola implementovaná druhá úroveň podpory pre cieľové platformy loongarch64-unknown-linux-musl a arm64ec-pc-windows-msvc. Druhá úroveň podpory zahŕňa záruku montáže.
  • pre Linux-systémy na platforme LoongArch sú dodávané s kompletnou sadou nástrojov a profilerom.
  • Zraniteľnosť (CVE-2024-43402) v std::process::Command, ktorá ovplyvňuje iba platformu, bola opravená. Windows a eliminuje riešenie pre zneužitie predtým opravenej zraniteľnosti BatBadBut, ktorá zahŕňala spracovanie špeciálnych znakov pri použití volaní Command::arg a Command::args, ktoré sú navrhnuté tak, aby priamo odovzdávali argumenty procesu bez ich spracovania interpretom príkazov. V skutočnosti sa pri spustení skriptov bat a cmd spúšťal proces cmd.exe, ktorý má vlastnú logiku na oddeľovanie argumentov. Obídenie je založené na skutočnosti, že Windows odstráni úvodné medzery a bodky v cestách, t. j. súbor s príponou „.bat.“ sa spracuje ako „.bat“.

Za zmienku stojí aj odchod Wedsona Almeidu Filha z pozície správcu projektu Rust. Linux, zapojený do implementácie jadra Linux vývojové nástroje pre jazyk Rust. Po Wadsonovom odchode má projekt stále dvoch správcov: Miguela Ojedu, autora a hlavného vývojára nástroja Rust pre...Linux, a Alex Gaynor, bývalý riaditeľ Python Software Foundation, ktorý sa zameral na propagáciu Rustu. Odchádzajúci správca, ktorý sa k projektu pripojil pred štyrmi rokmi, je zamestnancom spoločnosti Microsoft a autorom experimentálneho ovládača implementujúceho súborový systém EXT2, napísaného v Ruste. Almeidova nedávna práca sa zamerala na vytváranie nástrojov na vývoj súborových systémov v Ruste. Tento rok Almeida prispel do Rust-for-repository.Linux 17 commitov (pre porovnanie, Miguel Ojeda pridal 53 commitov).

Dôvodom odchodu je nedostatok energie a nadšenia, ktoré kedysi bolo potrebné na reakciu na určité netechnické nezmysly. Podľa Almeidu sú vývojári nútení vynakladať veľa energie na hádky o nepodstatných problémoch, ktoré podkopávajú dôležitejší celkový cieľ. Almeida naďalej verí, že budúcnosť jadier spočíva v používaní pamäťovo bezpečných jazykov a ak komunita vývojárov Linux tak toto nepochopíš, Linux bude nahradené nejakým iným jadrom, ako sa to stalo s Unixom svojho času.

Podporovatelia projektu Rust-for-Linux čelil potrebe prekonať odpor skúsených, dlhoročných vývojárov jadra, ktorí nevideli potrebu učiť sa nový jazyk. Vo svojej rezignácii Almeida uvádza ako príklad diskusiu, ktorá sa odohrala počas Almeidovej prezentácie s Kentom Overstreetom naLinux Summit o úložisku, súborovom systéme, správe pamäte a BPF“ bol venovaný použitiu Rustu na vývoj súborových systémov. Snahy o implementáciu Rustu kritizoval Ted Ts'o, autor súborových systémov ext2/ext3/ext4, ktorý porovnal Rust pre...Linux s pokusom prinútiť každého prijať hrdzavé náboženstvo.

V reakcii na zámer Almeidy vytvoriť obal okolo rozhraní súborových systémov napísaných v jazyku C na použitie v kóde Rust, Ted Tso poukázal na to, že takýto obal by nevyhnutne viedol k problémom, pretože akákoľvek zmena v rozhraniach C a refaktoring by si vyžadovali zmeny väzieb pre Rust a nechce preberať zbytočnú zodpovednosť za opravu problémov v kóde Rust a sledovanie stavu väzby Rust. C kód sa neustále vyvíja a ak jeho zmena naruší funkčnosť frameworku Rust, povedie to k narušeniu všetkých súborových systémov spojených s týmto frameworkom.

Ted sa tiež domnieva, že v dohľadnej budúcnosti zostane viazanie pre Rust druhoradé a že problémy s viazaním budú pre vývojárov Rust-for-to-Business len problémom.Linux, a nie pre komunitu vývojárov súborových systémov jadra. Bolo zdôraznené, že nie všetci vývojári majú v úmysle naučiť sa Rust, a preto po vykonaní zmien, ktoré ovplyvňujú iný kód, budú môcť iba aktualizovať závislý kód C, ale nebudú môcť opraviť väzby Rust, pretože Rust nepoznajú. Do diskusie sa zapojil aj James Bottomley, správca subsystému SCSI, s tým, že čím viac sémantiky je zakódovaných do väzieb, tým krehkejšie sa stávajú z hľadiska synchronizácie.

Medzitým spoločnosť Google, ktorá minulý rok prepísala firmvér pvmfm používaný v virtuálne stroje, spustený na platforme Android, podelila sa o svoje skúsenosti s postupným začleňovaním kódu Rust do existujúceho firmvéru pôvodne napísaného v jazyku C alebo C++. Ukázala, ako možno výrazne zlepšiť bezpečnosť firmvéru vytvorením funkčne identických náhradných komponentov napísaných v jazyku Rust. Pri implementácii Rustu navrhla zamerať sa na používanie Rustu pre nový kód a kód, ktorý vykonáva bezpečnostne kritické funkcie (napríklad kód na spracovanie externých údajov prijatých z nedôveryhodných zdrojov). Na integráciu kódu Rust a C navrhla použitie modulov (shim), ktoré prekladajú volania medzi API Rust a C (API jazyka C sa exportuje na použitie v kóde Rust a naopak), čo umožňuje postupné prepisovanie prvkov API v Ruste.

Zdroj: opennet.ru

Kúpte si spoľahlivý hosting pre stránky s DDoS ochranou, VPS VDS servery 🔥 Kúpte si spoľahlivý webhosting s ochranou DDoS, VPS VDS servery | ProHoster