Udgaven af programsproget Rust 1.81, oprindeligt udviklet af Mozilla og nu videreudviklet under paraplyen af den uafhængige nonprofitorganisation Rust Foundation, er blevet offentliggjort. Sproget fokuserer på sikker hukommelsesstyring og tilbyder værktøjer til at opnå høj parallel udførelse af opgaver, uden brug af en garbage collector og runtime (runtime reduceres til grundlæggende initialisering og vedligeholdelse af standardbiblioteket).
Metoder til hukommelsesarbejde i Rust befrier udviklere fra fejl ved manipulation af pekere og beskytter mod problemer, der opstår ved lavniveau håndtering af hukommelse, såsom adgang til hukommelsesområder efter frigivelse, dereferering af nulpekere, buffer-overløb osv. For distribution af biblioteker, byggeprocesser og afhængighedsstyring udvikles pakkehåndteringssystemet Cargo. For opbevaring af biblioteker understøttes repository'et crates.io.
Sikker håndtering af hukommelse sikres i Rust under kompilering ved referencekontrol, sporing af ejerskab af objekter, hensyntagen til livstid af objekter (synlighed) og vurdering af korrekt adgang til hukommelse under kodeudførelse. Rust tilbyder også midler til beskyttelse mod heltals-overløb, kræver obligatorisk initialisering af variabelværdier før brug, håndterer fejl bedre i standardbiblioteket, anvender konceptet med uforanderlige (immutable) referencer og variabler som standard og tilbyder stærk statisk typisering for at minimere logiske fejl.
Hovednyhederne:
- Typen core::error::Error er blevet stabiliseret, hvilket definerer de fejlbeskeder, der udskrives. Ændringen gør det muligt at bruge den samme fejltype Error på tværs af forskellige biblioteker, uafhængigt af miljøet, inklusive biblioteker, der ikke er knyttet til standardbiblioteket, som bruger attributten «#![no_std]».
- Stabile og ustabile sorteringsfunktioner i standardbiblioteket er blevet oversat til at bruge nye algoritmer, der viser højere hastighed og kortere kompileringstid. Implementeringen af de nye sorteringsalgoritmer sikrer, at ukorrekt definerede typer Ord identificeres og viser en fejl (panic) i sådanne tilfælde i stedet for tilfældigt grupperede data.
- En ny niveau af kontrol, «expect» («#[expect(lint)]»), er blevet implementeret i linteren, hvilket giver mulighed for at sikre, at kontrolen udføres og udskriver en advarsel, hvis kontrollen ikke er udført (på grund af fejl i implementeringen eller deaktivering af kontrollen). For eksempel, når man konverterer kodebasen til at bruge kontrol af undocumented_unsafe_blocks via Clippy, kan man angive «#[expect(clippy::undocumented_unsafe_blocks)]» for at sikre, at alle unsafe-blocks dokumenteres i overgangsprocessen. Clippy har også implementeret kontrol af clippy::allow_attributes og clippy::allow_attributes_without_reason, der forenkler udskiftning af attributter «#[allow]» med «#[expect(lint)]».
- Muligheden for at dokumentere årsagen til udskiftning af kontrolniveauer (lint) er blevet givet, hvilket giver nye udviklere information om, hvorfor den pågældende kontrol blev tilføjet, og dette præsenteres som en kompilatorbesked. For eksempel: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
- En ny batch af API'er er blevet klassificeret som stabile, herunder stabilisering af metoder og implementeringer af 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
Kendetegnet «const», som bestemmer muligheden for at bruge det i enhver kontekst i stedet for konstanter, anvendes i funktioner:
- char::from_u32_unchecked (funktion)
- char::from_u32_unchecked (metode)
- CStr::count_bytes
- CStr::from_ptr
Typen std::panic::PanicInfo er omdøbt til std::panic::PanicHookInfo (den tidligere betegnelse er stadig i brug, men fra næste version vil brug af denne give en advarsel). Samtidig forbliver core::panic::PanicInfo uændret, men vil udvikle sig som en separat type. Opdelingen af typerne muliggør implementeringen af forskellige metoder, der er specifikke for udførelse i konteksterne snd og no_std.
- Overgangen til ABI C-unwind (‘extern «C-unwind»‘) er afsluttet, hvilket adskiller sig fra ABI uden suffikset «-unwind» (‘extern «C»‘) ved at opretholde sikker adfærd (safe), hvis den "afvikling" (unwinding), der initieres ved et programfejl eller C++-stil undtagelse, krydser grænsen for ABI (for eksempel når en undtagelse, der opstår i kode fra et programmeringssprog, under afviklingen påvirker stakken relateret til kode fra et andet programmeringssprog). Fra Rust-version 1.81 er nødstop aktiveret i ABI ‘extern «C»‘ ved ikke-fanget afvikling.
- Der er implementeret tredje niveau af support til platforme 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 niveau indebærer grundlæggende support, men uden automatiseret testning, publicering af officielle builds og kontrol af mulighed for at bygge kode.
- Der er implementeret andet niveau af support for de målrettede platforme loongarch64-unknown-linux-musl og arm64ec-pc-windows-msvc. Andet niveau af support indebærer garanti for bygning.
- For Linux-systemer på LoongArch-platformen er der leveret komplet værktøjssæt og profileringsværktøjer.
- Sårbarheden (CVE-2024-43402) i std::process::Command, som kun optræder på Windows-platformen, er blevet rettet for at lukke en udnyttelsesvej for den tidligere rettede sårbarhed BatBadBut, der er relateret til håndteringen af specialtegn ved brug af Command::arg og Command::args, der er designet til at sende argumenter direkte til processen uden at blive behandlet af kommandotolkeren. I praksis, når bat- og cmd-scripts blev kørt, blev processen cmd.exe startet, som har sin egen logik til argumentopdeling. Beskyttelsesomgåelsen bygger på, at Windows fjerner førende mellemrum og punkter i stier, dvs. en fil med udvidelsen ".bat. ." behandles som ".bat".
Derudover kan det nævnes, at Wedson Almeida Filho har forladt sin post som vedligeholder af projektet Rust for Linux, som arbejder på at integrere værktøjer til udvikling i Linux-kernen ved hjælp af Rust. Efter Wedsons afgang har projektet stadig to vedligeholdere tilbage — Miguel Ojeda, forfatter og hovedudvikler af projektet Rust-for-Linux, og Alex Gaynor, tidligere direktør for Python Software Foundation, som har skiftet fokus til at fremme Rust. Den forhenværende vedligeholder, som tilsluttede sig projektet for 4 år siden, er ansat ved Microsoft og forfatter til en eksperimentel driver med implementering af filsystemet EXT2 skrevet i Rust. I den seneste tid har Almeida fokuseret på at udvikle værktøjer til filsystemer i Rust. I år har Almeida bidraget med 17 commits til Rust-for-Linux-repositoriet (til sammenligning har Miguel Ojeda bidraget med 53 commits).
Årsagen til hans afgang nævnes som en mangel på kræfter og entusiasme, som han engang havde til at reagere på en del ikke-teknisk vrøvl. Ifølge Almeida er udviklerne tvunget til at bruge mange kræfter på diskussioner om mindre væsentlige spørgsmål, der underminerer det mere vigtige globale mål. Almeida fortsætter med at tro, at fremtiden for kernen ligger i brugen af sprog, der sikrer sikker hukommelse, og hvis Linux-udviklersamfundet ikke forstår dette, vil Linux blive skubbet til side af en anden kerne, som det engang skete med Unix.
Støtterne af projektet Rust-for-Linux er stødt på behovet for at overvinde modstand fra gamle, etablerede udviklere af kernen, som ikke ser behovet for at lære et nyt sprog. I sit afgangsbrev henviser Almeida til en diskussion, der fandt sted under hans og Kent Overstreets oplæg på konferencen 'Linux Storage, Filesystem, Memory-Management, and BPF Summit', som var dedikeret til brugen af Rust til udvikling af filsystemer. Ted Ts'o, forfatteren af filsystemerne ext2/ext3/ext4, kritiserede aktiviteten ved at implementere Rust og sammenlignede initiativet Rust-for-Linux med at forsøge at få alle til at acceptere Rust som en religion.
Som svar på Almeidas hensigt om at skabe en wrapper over de C-sprog interface til filsystemer til brug i kode skrevet i Rust, påpegede Ted Ts'o, at en sådan wrapper uundgåeligt vil føre til problemer, da enhver ændring af C-interfacene og refaktorering kræver ændringer i Rust-wrapperen, og han ønsker ikke at påtage sig det ekstra ansvar for at rette op på de problemer, der opstår i Rust-koden samt at følge med i tilstanden af Rust-wrapperen. Koden i C udvikler sig konstant, og hvis en ændring forstyrrer funktionen af Rust-wrapperen, vil det også medføre forstyrrelser i alle filsystemer, der er afhængige af denne wrapper.
Ted mener også, at i den nærmeste fremtid vil wrapperen for Rust forblive sekundær, og opståen af problemer i bindingerne vil kun være en hovedpine for udviklerne af Rust-for-Linux og ikke for samfundet af udviklere af filsystemer i kernen. Det er blevet nævnt, at ikke alle udviklere agter at lære Rust, og derfor vil de efter at have foretaget ændringer, der påvirker anden kode, kun kunne opdatere den afhængige kode i C, men ikke kunne rette Rust-wrapperne, da de ikke kender Rust. Diskussionen blev også deltaget af James Bottomley, der vedligeholder SCSI undergruppen, som sagde, at jo mere semantik der kodes i wrapperne, desto mere skrøbelige bliver de med hensyn til at sikre synkronisering.
I mellemtiden har Google, som sidste år omskrev pvmfm-firmware til Rust, der anvendes i virtuelle maskiner, der kører på Android-platformen, delte erfaringer med gradvist at integrere kode skrevet i Rust i eksisterende firmware, der oprindeligt er skrevet i C eller C++. Det vises, hvordan man betydeligt kan forbedre sikkerheden i firmwaren ved at skabe identiske komponenter skrevet i Rust som erstatninger. Fokus for implementeringen af Rust foreslås at være på brugen af Rust til ny kode og kode, der udfører funktioner, der er kritiske for sikkerheden (f.eks. kode til behandling af eksterne data fra uskadelige kilder). For at integrere Rust- og C-kode foreslås det at bruge lag (shim), der oversætter opkald mellem API'er på Rust og C (C API'en eksporteres til brug i Rust-kode og omvendt), hvilket muliggør en gradvis omskrivning af API-elementer til Rust.
Kilde: opennet.ru
