Megjelent a Mozilla projekt által alapított, de ma már független civil szervezet, a Rust Foundation által fejlesztett Rust 1.81 általános célú programozási nyelv. A nyelv a memória biztonságos kezelésére összpontosít, és eszközöket biztosít a feladatok magas fokú párhuzamos végrehajtásához, miközben elkerüli a szemétgyűjtőt és futási időt (a futási idő alapvetően a standard könyvtár inicializálására és karbantartására korlátozódik).
A Rust memória kezelésének módszerei megszüntetik a fejlesztők hibáit a mutatókkal való manipulálás során, és védelmet nyújtanak az alacsony szintű memória kezelésből adódó problémákkal szemben, mint például a már felszabadított memória területére való hivatkozás, null-pointer dereferálás, pufferméret túllépés stb. A könyvtárak terjesztésére, a build biztosítására és a függőségek kezelésére a Cargo csomagkezelő fejlesztés alatt áll. A könyvtárak elhelyezésére a crates.io tároló támogatott.
A memória biztonságos kezelése a Rustban a fordítási időben történik, a hivatkozások ellenőrzésén, az objektumok tulajdonjogának nyomon követésén, az objektumok élettartamának (láthatóságának) figyelembevételén és a memória hozzáférésének helyességének értékelésén keresztül a kód futtatásakor. A Rust emellett eszközöket biztosít az egész számok túllépésének elleni védelemhez, kötelezővé teszi a változók értékeinek inicializálását használat előtt, jobban kezeli a hibákat a standard könyvtárban, alkalmazza a változatlan (immutable) hivatkozások és változók fogalmát alapértelmezés szerint, és erős statikus típussal minimalizálja a logikai hibákat.
Főbb újítások:
- Stabilizálták a core::error::Error típust, amely az előállított hibaleírásokat határozza meg. A módosítás lehetővé teszi egy egységes Error típust használatát különböző könyvtárakban, függetlenül a környezettől, beleértve a nem a standard könyvtárhoz kötött könyvtárakat is, amelyek a "#![no_std]" attribútumot használják.
- A standard könyvtár stabil és instabil rendező funkciói új algoritmusok használatára lettek átültetve, amelyek magasabb sebességet és rövidebb fordítási időt mutatnak. Az új rendezési algoritmusok megvalósításánál biztosították a hibásan megadott Ord típusok azonosítását, és ilyen esetekben hiba (panic) kibocsátásával reagálnak, ahelyett, hogy véletlenszerűen csoportosított adatokat adtak volna vissza.
- A linterben új "expect" ellenőrzési szint került megvalósításra ("#[expect(lint)]"), amely lehetővé teszi a ellenőrzés végrehajtásának biztosítását és figyelmeztetés kibocsátását, amennyiben az ellenőrzés nem hajtható végre (a megvalósítás hibája vagy az ellenőrzés letiltása miatt). Például, amikor a kódalapot az undocumented_unsafe_blocks ellenőrzésére Clippy használatára állítjuk át, megadhatjuk "#[expect(clippy::undocumented_unsafe_blocks)]" a folyamat során minden unsafe blokk dokumentálásának biztosítása érdekében. A Clippy-n belül a clippy::allow_attributes és clippy::allow_attributes_without_reason ellenőrzések is megvalósításra kerültek, amelyek egyszerűsítik az "#[allow]" attribútumok "#[expect(lint)]"-re történő cseréjét.
- Lehetőséget kaptunk a ellenőrzési szintek (lint) megváltoztatásának okainak dokumentálására, amely új fejlesztők számára információt nyújt a különféle ellenőrzések hozzáadásának okairól, amelyet fordítói üzenetként adnak át. Példa: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
- Új API-k kerültak a stabil kiadások közé, beleértve a metódusok és típusimplementációk stabilizálását:
- 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
A 'const' qualifier that defines the ability to use it in any context instead of constants is applied in functions:
- char::from_u32_unchecked (function)
- char::from_u32_unchecked (method)
- CStr::count_bytes
- CStr::from_ptr
The type std::panic::PanicInfo has been renamed to std::panic::PanicHookInfo (the old name's functionality is preserved, but its usage will result in a warning starting from the next version). Meanwhile, core::panic::PanicInfo will remain unchanged but will develop as a separate type. This separation will allow implementing different methods specific to the contexts of snd and no_std.
- The transition to ABI C-unwind (‘extern ‘C-unwind’‘) has been completed, which differs from the ABI without the ‘-unwind’ suffix (‘extern ‘C’‘) by maintaining safe behavior (safe) if the unwinding process triggered by an unhandled program termination or C++-style exception crosses an ABI boundary (for example, when an exception arising from code in one programming language unwinds into a stack associated with code in another programming language). Beginning with Rust 1.81, ‘extern ‘C’‘ ABI involves emergency termination during unhandled unwinding.
- A third level of support has been implemented for the i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf platforms. The third level implies basic support, but without automated testing, publication of official builds, and verification of code buildability.
- A second level of support has been implemented for the target platforms loongarch64-unknown-linux-musl and arm64ec-pc-windows-msvc. The second level of support guarantees buildability.
- Complete tooling and profiling support have been provided for Linux systems on the LoongArch platform.
- Orvos ideiglenesen javított egy biztonsági rést (CVE-2024-43402) a std::process::Command-ban, amely csak a Windows platformon jelentkezik, és megszünteti a BatBadBut korábban javított sebezhetőségének kikerülési lehetőségét, amely a speciális karakterek feldolgozásával kapcsolatos a Command::arg és Command::args függvényekben, amelyek célja a paraméterek közvetlen átadása a folyamatnak, anélkül, hogy a parancsértelmező feldolgozná őket. Valójában a bat- és cmd-szkriptek futtatása során a cmd.exe folyamat indult el, amelynek saját argumentumkülönválasztási logikája van. A védelem kikerülésén alapul, hogy a Windows eltávolítja a vezető szóközöket és pontokat az elérési utakból, azaz egy „.bat. .” kiterjesztésű fájlt „.bat”-ként dolgoznak fel.
Ezen kívül megemlíthető, hogy Wedson Almeida Filho elhagyta a Rust for Linux projekt koordinálásáért felelős posztját, amely a Rust programozási nyelvhez kapcsolódó fejlesztési eszközök kernelbe való beillesztésével foglalkozik. Wedson távozása után még két koordinátor maradt a projektben – Miguel Ojeda, a Rust-for-Linux projekt alapítója és vezető fejlesztője, valamint Alex Gaynor, a Python Software Foundation volt igazgatója, aki a Rust népszerűsítésére váltott. Az eltávozott koordinátor, aki 4 éve csatlakozott a projekthez, a Microsoft alkalmazottja és egy kísérleti EXT2 fájlrendszer illesztőprogram szerzője, amelyet Rust nyelven írtak. Almeida közelmúltban végzett munkája a Rust nyelvű fájlrendszer-fejlesztési eszközök létrehozására összpontosított. Idén Almeida 17 commitot tett a Rust-for-Linux tárolóba (összehasonlításképpen Miguel Ojeda 53 commitot adott hozzá).
A távozás okaként a lelki és lelkesedés hiányát említik, amely egykor elég volt ahhoz, hogy reagáljon néhány technikai szempontból irreleváns dologra (nontechnical nonsense). Almeida véleménye szerint a fejlesztők sok energiát kénytelenek elkölteni lényegtelen kérdéseken folytatott vitákra, amelyek elhomályosítják a fontosabb globális célt. Almeida továbbra is hisz abban, hogy a jövő kerneljei olyan nyelvek használatán alapulnak, amelyek biztonságos memóriakezelést biztosítanak, és ha a Linux fejlesztői közösség ezt nem érti meg, akkor a Linuxot valamilyen más kernel váltja fel, ahogyan az egykor a Unixon történt.
A Rust-for-Linux projekt támogatói szembe kellett nézzenek a régi, tapasztalt kernelfejlesztők ellenállásával, akik nem látják a szükségességét egy új nyelv elsajátításának. Almeyda lemondó levelében példaként említi a beszélgetést, amely Almeyda és Kent Overstreet előadásakor zajlott a "Linux Storage, Filesystem, Memory-Management, and BPF Summit" konferencián, és amely a Rust használatáról szólt a fájlrendszerek fejlesztésében. Az Rust elfogadását Ted Ts’o, az ext2/ext3/ext4 fájlrendszerek szerzője kritizálta, aki a Rust-for-Linux kezdeményezést a Rust vallásának elfogadtatásához hasonlította.
Almeyda szándékával, hogy C nyelven írt fájlrendszer-interfacesre Rust környezetet hozzon létre, Ted Ts’o rávilágított, hogy egy ilyen réteg óhatatlan problémákhoz vezet, mivel a C interfészek bármilyen módosítása és a refaktorálás a Rust interfész módosítását igényli, és nem akarja magára vállalni a felesleges felelősséget a Rust kódjában felmerülő problémák javításáért és a Rust környezet állapotának nyomon követéséért. A C kód folyamatosan fejlődik, és ha változás következik be, ami megzavarja a Rust interfészt, ez a Rust-ra épülő összes fájlrendszer működését is befolyásolja.
Ted emellett úgy véli, hogy a közeli jövőben a Rust környezet másodlagos lesz, és a binderekben felmerülő problémák csak a Rust-for-Linux fejlesztők fejfájását okozzák, nem a kernelfájlrendszer fejlesztői közösségének. Megjegyzik, hogy nem minden fejlesztő fogja megtanulni a Rustot, így ha olyan változtatásokat eszközölnek, amelyek más kódot érintenek, csak a C-re épülő kódot frissíthetik, de nem tudják kijavítani a Rust környezetet, mert nem ismerik a Rustot. James Bottomley, a SCSI alrendszer karbantartója is csatlakozott a beszélgetéshez, aki elmondta, hogy minél több szemantika van kódolva a binderekben, annál törékenyebbé válnak a szinkronizálás biztosítása szempontjából.
Közben a Google tavaly Rust nyelven újraírt pvmfm firmware-jét használja, amely a virtuális gépekben, amelyeket Android platformon futtatnak, megosztotta tapasztalatait a Rust programozási nyelv fokozatos integrálásáról a meglévő firmware-ekbe, amelyeket eredetileg C vagy C++ nyelven írtak. Bemutatja, hogyan lehet jelentősen növelni a firmware-ek biztonságát, azonos funkcionalitású, Rust nyelven írt helyettesítő komponensek létrehozásával. A Rust bevezetésénél főként az új kód és a biztonsági szempontból kritikus funkciókhoz tartozó kód (például a megbízhatatlan forrásokból származó külső adatok kezelésére szolgáló kód) Rust nyelvű használatára javasolt összpontosítani. A Rust és C közötti kódintegrációhoz shim rétegek használata javasolt, amelyek továbbítják a hívásokat a Rust és C API között (a C API exportálva van Rust kódban való használatra és fordítva), lehetővé téve az API elemek fokozatos újraírását Rust nyelven.
Forrás: opennet.ru
