Shpërthimi i Rust 1.81. Pengesat në avancimin e Rust në bërthamën Linux

Është publikuar versioni i gjuhës së programimit të përgjithshëm Rust 1.81, i zhvilluar nga projekti Mozilla, por tani nën mbikëqyrjen e organizatës jo-fitimprurëse Rust Foundation. Gjuha fokusohet në sigurinë e punës me memorje dhe ofron mjete për të arritur paralelizëm të lartë në ekzekutimin e detyrave, duke mos përdorur një mbledhës plehrash dhe runtime (runtime përfshin vetëm inicializimin themelor dhe mbështetje për bibliotekën e standardit).

Metodat e punës me kujtesën në Rust e çlirojnë zhvilluesin nga gabimet gjatë manipulimit të treguesve dhe mbrojnë nga problemet që lindin nga puna me nivel të ulët me kujtesën, siç janë referimi në një zonë kujtese pas çlirimit të saj, dereferimi i treguesve null, tejkalimi i kufijve të tamponëve etj. Për shpërndarjen e biblioteka, për të siguruar ndërtimin dhe menaxhimin e varësive, projekti zhvillon menaxherin e paketave Cargo. Për ruajtjen e bibliotekave, mbështetet depoja crates.io.

Përdorimi i sigurt i memories sigurohet në Rust gjatë kompilimit përmes verifikimit të lidhjeve, gjurmimit të pronësisë së objekteve, përllogaritjes së kohëzgjatjes së objekteve (fushave të dukshmërisë) dhe vlerësimit të saktësisë së qasjes në memorie gjatë ekzekutimit të kodit. Rust gjithashtu ofron mjete për mbrojtje nga tejkalimet e numrave të plotë, kërkon inicializim të detyrueshëm të vlerave të variablave para përdorimit, menaxhon më mirë gabimet në bibliotekën standarde, aplikon konceptin e lidhjeve dhe variablave të pandryshueshëm (immutable) si parazgjedhje, dhe ofron tipizim të fortë statik për minimizimin e gabimeve logjike.

Të rejat kryesore:

• Tipos core::error::Error është stabilizuar, i cili përcakton përshkrimet e gabimeve të nxjerra. Ky ndryshim lejon përdorimin e një tipi të vetëm Error në biblioteka të ndryshme, pa marrë parasysh mjedisin, përfshirë biblioteka që nuk janë të lidhura me bibliotekën standarde, që përdorin atributin «#![no_std]».
• Funksionet e stabilizuara dhe të pa-stabilizuara të renditjes në bibliotekën standarde janë transferuar në përdorimin e algoritmeve të reja, që demonstrojnë shpejtësi më të lartë dhe kohë më të shkurtër kompilimi. Në implementimin e algoritmeve të reja të renditjes, është siguruar përcaktimi i tiparëve të Ord që janë të papërcaktuar dhe nxjerrja e një gabimi (panic) në këto raste në vend të të dhënave të grupuara rastësisht.
• Në linter është implementuar një nivel i ri verifikimi «expect» («#[expect(lint)]»), i cili lejon të sigurohet që verifikimi është kryer dhe të nxjerrë një paralajmërim nëse verifikimi nuk është kryer (për shkak të një gabimi në implementim ose çaktivizimit të verifikimit). Për shembull, kur transferohet baza e kodit në përdorimin e verifikimit të undocumented_unsafe_blocks përmes Clippy, mund të caktosh «#[expect(clippy::undocumented_unsafe_blocks)]» për të siguruar që gjatë kalimit të gjitha blloqet unsafe do të dokumentohen. Në Clippy gjithashtu janë implementuar verifikimet clippy::allow_attributes dhe clippy::allow_attributes_without_reason, që lehtësojnë zëvendësimin e atributeve «#[allow]» me «#[expect(lint)]».
• Është ofruar mundësia për të dokumentuar arsyeja e zëvendësimit të niveleve të verifikimit (lint), që siguron informacion për zhvilluesit e rinj në lidhje me arsyet e shtimit të verifikimeve të caktuara, të nxjerra si mesazhe nga kompajleri. Për shembull: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
• Një sasi e re API është kaluar në kategorinë stabile, përfshirë stabilizimin e metodave dhe implementimeve të tipazheve:
  • 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

  Karakteristika «const», që përcakton mundësinë e përdorimit në çdo kontekst në vend të konstantave, është aplikuar në funksionet:

  • char::from_u32_unchecked (funksion)
  • char::from_u32_unchecked (metodë)
  • CStr::count_bytes
  • CStr::from_ptr

  Tipi std::panic::PanicInfo është riemëruar në std::panic::PanicHookInfo (përdorimi i emrit të vjetër do të ruhet, por që nga versioni tjetër përdorimi i tij do të shkaktojë një paralajmërim). Megjithatë, core::panic::PanicInfo do të mbetet ashtu siç është, por do të zhvillohet si një tip i ndarë. Ndarja e tipeve do të lejojë implementimin e metodave të ndryshme, specifike për ekzekutimin në kontekstin e snd dhe no_std.

• Është përfunduar kalimi në ABI C-unwind (‘extern «C-unwind»‘), i cili dallon nga ABI pa sufixin «-unwind» (‘extern «C»‘) për ruajtjen e sjelljes së sigurt (safe), nëse procesi i «çmontimit» (unwinding), i inicuar gjatë crashing të programit apo gjenerimit të një përjashtimi në stilin C++, prek kufirin e ABI (p.sh., kur një përjashtim i ndodhur në kodin e një gjuhe programimi, gjatë çmontimit prek stakun e lidhur me kodin e një gjuhe tjetër programimi). Në versionin Rust 1.81, ABI ‘extern «C»‘ aktivizon crashing në rastin e çmontimit të pa kapur.
• Është implementuar një nivel i tretë mbështetjeje për platformat i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Niveli i tretë parashikon mbështetje bazike, por pa testim automatizuar, publikim të ndërtimeve zyrtare dhe verifikim të mundësisë për ndërtimin e kodit.
• Është implementuar një nivel i dytë mbështetjeje për platformat e objektivave loongarch64-unknown-linux-musl dhe arm64ec-pc-windows-msvc. Niveli i dytë i mbështetjes parashikon garancinë e ndërtimit.
• Për sistemet Linux në platformën LoongArch është ofruar një komplet i plotë mjetesh dhe profilues.
• Është eliminuar një vunerabilitet (CVE-2024-43402) në std::process::Command, që shfaqet vetëm në platformën Windows dhe eliminon një rrugë anashkalimi të vunerabilitetit të mëparshëm BatBadBut, që lidhet me trajtimin e karaktereve speciale gjatë përdorimit të thirrjeve Command::arg dhe Command::args, të destinuara për të kaluar drejtpërdrejt argumentet procesit, pa u trajtuar nga interpreti i komandave. Në fakt, kur ekzekutoheshin skriptet bat dhe cmd, procesi cmd.exe, që kishte logjikën e tij të ndarjes së argumenteve, aktivizohej. Rrugë anashkalimi mbështetet në faktin se Windows heq hapësirat dhe pikat kryesore në rrugët, dmth, një skedar me shtrirjen «.bat. .» trajtohet si «.bat».

Gjithashtu, mund të theksohet largimi i Wedson Almeida Filho nga pozita e zhvilluesit të projektit Rust për Linux, i cili merret me integrimin e mjeteve për zhvillimin në gjuhën Rust në kernelin Linux. Pas largimit të Wedson, projekti ka ende dy zhvillues të tjerë — Miguel Ojeda, autor dhe zhvillues kryesor i projektit Rust-for-Linux, dhe Alex Gaynor, ish-drejtor i Organizatës Python Software Foundation, i cili kaloi në promovimin e Rust. Zhvilluesi i larguar, i cili u bashkua me projektin 4 vjet më parë, është punonjës i kompanisë Microsoft dhe autor i një drejtuesi eksperimental me implementimin e FS EXT2, shkruar në gjuhën Rust. Kohët e fundit, puna e Almeida ishte e fokusuar në krijimin e mjeteve për zhvillimin e sistemeve të skedarëve në gjuhën Rust. Këtë vit, Almeida kontribuoi në depozitat Rust-for-Linux me 17 komite (për krahasim, Miguel Ojeda e shtoi 53 komite).

Si arsye për largimin përmendet mungesa e forcës dhe entuziazmit, të cilat dikur ishin të nevojshme për të reaguar ndaj disa absurditeteve jotehnike. Sipas Almeida, zhvilluesit janë të detyruar të shpenzojnë shumë energji në diskutime për çështje të parëndësishme, që i heqin vëmendjen qëllimit më të rëndësishëm global. Almeida vazhdon të besojë se e ardhmja e kernelit është përdorimi i gjuhëve që sigurojnë sigurinë e punës me memorien, dhe nëse komuniteti i zhvilluesve Linux nuk e kupton këtë, Linux do të zëvendësohet nga ndonjë kernel tjetër, ashtu siç ndodhi dikur me Unix.

Përkrahësit e projektit Rust-for-Linux përballen me nevojën për të tejkaluar rezistencën nga zhvilluesit e vjetër, të njohur për ekspertizën e tyre, të cilët nuk shohin nevojën për të mësuar një gjuhë të re. Në letrën e tij të dorëheqjes, Almeida përmend një diskutim që u mbajt gjatë një paraqitjeje të tij dhe Kent Overstreet në konferencën "Linux Storage, Filesystem, Memory-Management, dhe BPF Summit", i cili ishte i fokusuar në përdorimin e Rust për zhvillimin e sistemeve të skedarëve. Aktivitetin për integrimin e Rust e kritikoi Ted Ts'o, autori i sistemeve të skedarëve ext2/ext3/ext4, i cili e krahasoi nismën Rust-for-Linux me një përpjekje për të detyruar të gjithë të pranojnë religjionin e Rust.

Në përgjigje të qëllimit të Almeida për të krijuar një mbështetje mbi ndërfaqet e sistemeve të skedarëve të shkruara në gjuhën C për t'i përdorur në kodin në gjuhën Rust, Ted Ts'o theksoi se një mbështetje e tillë do ta sillte patjetër një sërë problemesh, pasi çdo ndryshim në ndërfaqet e gjuhës C dhe refaktorizimi do të kërkonin ndryshimin e mbështetjes për Rust, dhe ai nuk dëshiron të marrë përsipër përgjegjësi të tepërta për rregullimin e problemeve që lindin në kodin në Rust dhe mbajtjen e gjendjes së mbështetjes Rust. Kodi në C vazhdon të evoluojë dhe nëse ndonjë ndryshim prish funksionimin e mbështetjes për Rust, kjo do të çonte nëmungesën e funksionit të të gjitha sistemeve të skedarëve të lidhura me atë mbështetje.

Ted gjithashtu beson se në afatin e shkurtër mbështetja për Rust do të mbetet një çështje dytësore dhe shfaqja e problemeve në lidhjet do të jetë një dhembje koke vetëm për zhvilluesit e Rust-for-Linux, dhe jo për komunitetin e zhvilluesve të sistemeve të skedarëve në kernel. Është përmendur se nuk të gjithë zhvilluesit kanë për qëllim të mësojnë Rust dhe prandaj, pas bërjes së ndryshimeve që ndikojnë në kodin tjetër, ata do të jenë në gjendje të përditësojnë vetëm kodin e varur në C, por nuk do të jenë në gjendje të rregullojnë lidhjet Rust, pasi nuk e dinë Rust-in. Në diskutim mori pjesë gjithashtu James Bottomley, që mbikëqyr nën-sistemin SCSI, i cili tha se sa më shumë semantika të kodifikohet në lidhje, aq më të brishta bëhen ato nga pikëpamja e sinhronizimit.

Ndërkohë, kompania Google, e cila vitin e kaluar ri-shkroi në gjuhën Rust firmware pvmfm, e përdorur në makinat virtuale, që funksionojnë në platformën Android, ndau përvojën e saj për inkorporimin gradual të kodit në gjuhën Rust në firmware ekzistues, fillimisht të shkruara në C ose C++. Tregohet se si mund të përmirësohet ndjeshëm siguria e firmware-it duke krijuar komponente zëvendësuese me funksionalitet identik, të shkruara në gjuhën Rust. Vëmendja kryesore në integrimin e Rust është përkushtuar për përdorimin e Rust për kodin e ri dhe atë që kryen funksione kritike për sigurinë (p.sh., kodi për trajtimin e të dhënave të jashtme, që vijnë nga burime të pasigurta). Për integrimin e kodit në Rust dhe C, propozohet përdorimi i shtresave (shim), që përkthejnë thirrjet midis API-ve në Rust dhe C (C API eksportohet për t'u përdorur në kodin në Rust dhe anasjelltas), të cilat lejojnë kalimin gradual në shkruarjen e elementeve të API-së në Rust.

Burimi: opennet.ru