Lansarea Rust 1.81. Obstacole în promovarea Rust în nucleul Linux.

A fost publicat versiunea 1.81 a limbajului de programare general-purpose Rust, dezvoltat inițial de proiectul Mozilla, dar acum gestionat de organizația non-profit Rust Foundation. Limbajul se concentrează pe lucrul sigur cu memoria și oferă instrumente pentru atingerea unui înalt grad de paralelism în execuția sarcinilor, fără a utiliza un colector de gunoi și runtime (runtime-ul se reduce la inițializarea de bază și întreținerea bibliotecii standard).

Metodele de gestionare a memoriei în Rust scutesc dezvoltatorul de erori în manipularea pointerilor și protejează împotriva problemelor care apar din lucrul de nivel scăzut cu memoria, cum ar fi accesarea unui spațiu de memorie după ce acesta a fost eliberat, dereferința pointerilor nuli, depășirea limitelor buffer-ului etc. Pentru distribuirea bibliotecilor, asigurarea construirii și gestionarea dependențelor, se dezvoltă managerul de pachete Cargo. Pentru găzduirea bibliotecilor, suportul este oferit prin intermediul repository-ului crates.io.

Lucrul sigur cu memoria este asigurat în Rust în timpul compilării prin verificarea referințelor, urmărirea proprietății obiectelor, luarea în considerare a timpului de viață al obiectelor (domeniul de vizibilitate) și evaluarea corectitudinii accesului la memorie în timpul execuției codului. Rust oferă, de asemenea, instrumente pentru protejarea împotriva suprasaturării numerice, impune inițializarea obligatorie a valorilor variabilelor înainte de utilizare, gestionează mai bine erorile în biblioteca standard, aplică conceptul de referințe și variabile imutabile (immutable) din oficiu și oferă o tipizare statică puternică pentru a minimiza erorile logice.

Noutăți principale:

• A fost stabilizat tipul core::error::Error, care definește descrierile erorilor afișate. Modificarea permite utilizarea unui singur tip Error în diferite biblioteci, indiferent de mediu, inclusiv în biblioteci care nu sunt legate de biblioteca standard, care folosesc atributul „#![no_std]”.
• Funcțiile de sortare stabile și instabile din biblioteca standard au fost traduse pentru a utiliza noi algoritmi, care demonstrează o viteză mai mare de execuție și un timp de compilare mai scurt. În implementarea noilor algoritmi de sortare, s-a asigurat definirea tipurilor Ord incorect definite și generarea de erori în astfel de cazuri (panic) în loc de date grupate aleatoriu.
• În linter a fost implementat un nou nivel de verificare „expect” („#[expect(lint)]”), care permite asigurarea îndeplinirii verificării și afișarea unei atenționări dacă verificarea nu este efectuată (din cauza unei erori de implementare sau a dezactivării verificării). De exemplu, atunci când se convertește baza de cod pentru a utiliza verificarea undocumented_unsafe_blocks prin Clippy, se poate specifica „#[expect(clippy::undocumented_unsafe_blocks)]” pentru a se asigura că, în timpul tranziției, toate blocurile unsafe vor fi documentate. De asemenea, în Clippy au fost implementate verificările clippy::allow_attributes și clippy::allow_attributes_without_reason, care facilitează înlocuirea atributelor „#[allow]” cu „#[expect(lint)]”.
• A fost oferită posibilitatea documentării motivului înlocuirii nivelurilor de verificare (lint), oferind dezvoltatorilor noi informații despre motivele adăugării unor verificări, care sunt afișate ca mesaje de compilare. De exemplu: #![deny(clippy::float_arithmetic, reason = „no hardware float support“)]
• O nouă porțiune de API a fost transformată în stabilitate, inclusiv metode și implementări ale tiparelor stabilize.
  • 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

  Semnul „const”, care definește capacitatea de utilizare în orice context în locul constantelor, este utilizat în funcții:

  • char::from_u32_unchecked (funcție)
  • char::from_u32_unchecked (metodă)
  • CStr::count_bytes
  • CStr::from_ptr

  Tipul std::panic::PanicInfo a fost redenumit în std::panic::PanicHookInfo (numele vechi va continua să fie disponibil, dar începând din următoarea versiune, utilizarea sa va genera un avertisment). În același timp, core::panic::PanicInfo va rămâne neschimbat, dar va evolua ca un tip distinct. Separarea tipurilor va permite implementarea unor metode diferite, specifice contextului snd și no_std.

• Tranziția la ABI C-unwind ('extern «C-unwind»') a fost finalizată, care diferă de ABI fără sufixul '-unwind' ('extern «C»') prin păstrarea comportamentului sigur (safe), în cazul în care procesul de 'desfășurare' (unwinding) inițiat de o eroare de program sau de generarea unei excepții de tip C++ traversează granița ABI (de exemplu, când o excepție generată în codul unui limbaj de programare afectează stiva asociată cu codul din alt limbaj de programare). Începând cu lansarea Rust 1.81, în ABI 'extern «C»' este implicată tratarea erorilor în caz de desfășurare necontrolată.
• A fost implementat al treilea nivel de suport pentru platformele i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Al treilea nivel presupune suport de bază, dar fără teste automatizate, publicarea unor versiuni oficiale și verificarea capabilității de compilare a codului.
• A fost implementat al doilea nivel de suport pentru platformele țintă loongarch64-unknown-linux-musl și arm64ec-pc-windows-msvc. Al doilea nivel de suport garantează compilarea.
• Pentru sistemele Linux pe platforma LoongArch, a fost furnizată o suită completă de instrumente și un profiler.
• A fost remediată vulnerabilitatea (CVE-2024-43402) în std::process::Command, care se manifestă doar pe platforma Windows și care elimină o cale de exploatare a unei vulnerabilități anterior corectate, asociată cu gestionarea caracterelor speciale la utilizarea apelurilor Command::arg și Command::args, destinate transmiterii directe a argumentelor către proces, fără procesare de către interpreterul de comenzi. În practică, la rularea scripturilor bat- și cmd-, a fost lansat procesul cmd.exe, având propria logică de separare a argumentelor. Metoda de exploatare se bazează pe faptul că Windows elimină spațiile și punctele inițiale din căi, astfel încât un fișier cu extensia '.bat. .' este tratat ca '.bat'.

În plus, trebuie menționat că Wedson Almeida Filho s-a retras din funcția de mentor al proiectului Rust for Linux, care se ocupă cu integrarea instrumentelor de dezvoltare în nucleul Linux pentru limbajul Rust. După plecarea lui Wedson, proiectul a rămas cu încă doi mentori — Miguel Ojeda, autor și dezvoltator principal al proiectului Rust-for-Linux, și Alex Gaynor, fost director al organizației Python Software Foundation, care s-a concentrat pe promovarea Rust. Mentorul care a părăsit proiectul acum patru ani este angajat al companiei Microsoft și autor al unui driver experimental cu implementare a systemului de fișiere EXT2, scris în Rust. Recent, activitatea lui Almeida a fost concentrată pe crearea de instrumente pentru dezvoltarea systemelor de fișiere în Rust. Anul acesta, Almeida a contribuit la repository-ul Rust-for-Linux cu 17 commituri (spre comparație, Miguel Ojeda a adăugat 53 de commituri).

Ca motiv pentru plecare, se menționează lipsa de energie și entuziasm care cândva exista pentru a răspunde la unele aberații nontehnice. Potrivit lui Almeida, dezvoltatorii sunt nevoiți să investească multă energie în dispute despre chestiuni nesemnificative, care distrag atenția de la obiectivul global mai important. Almeida continuă să creadă că viitorul nucleelor se bazează pe utilizarea limbajelor care asigură un management sigur al memoriei, iar dacă comunitatea dezvoltatorilor Linux nu va înțelege acest lucru, Linux va fi înlocuit cu un alt nucleu, așa cum s-a întâmplat anterior cu Unix.

Susținătorii proiectului Rust-for-Linux s-au confruntat cu necesitatea de a depăși rezistența din partea vechilor dezvoltatori experimentați, care nu văd nicio necesitate de a învăța un nou limbaj. În scrisoarea sa de demisie, Almeida citează ca exemplu o discuție care a avut loc în timpul prezentării sale și a lui Kent Overstreet la conferința "Linux Storage, Filesystem, Memory-Management, and BPF Summit", dedicată utilizării Rust pentru dezvoltarea systemelor de fișiere. Activitatea de integrare a Rust a fost criticată de Ted Ts'o, autor al systemelor de fișiere ext2/ext3/ext4, care a comparat inițiativa Rust-for-Linux cu încercarea de a forța pe toți să adopte religia Rust.

În răspuns la intenția lui Almeida de a crea un wrapper peste interfețele sistemelor de fișiere scrise în C pentru utilizarea în codul Rust, Ted Ts'o a subliniat că un astfel de wrapper va duce inevitabil la probleme, deoarece orice modificare a interfețelor C și efectuarea refactorizărilor vor necesita modificări ale wrapper-ului pentru Rust și nu dorește să își asume responsabilitatea suplimentară pentru corectarea problemelor apărute în codul Rust și pentru urmărirea stării wrapper-ului Rust. Codul în C se dezvoltă constant, iar dacă modificările afectează funcționarea wrapper-ului pentru Rust, acest lucru va duce la probleme în toate sistemele de fișiere legate de acest wrapper.

Ted consideră, de asemenea, că, în viitorul apropiat, wrapper-ul pentru Rust va rămâne secundar, iar problemele din bind-urile Rust vor fi o bătaie de cap doar pentru dezvoltatorii Rust-for-Linux, nu pentru comunitatea dezvoltatorilor de sisteme de fișiere din nucleu. S-a menționat că nu toți dezvoltatorii vor să învețe Rust și, prin urmare, după efectuarea modificărilor care afectează alte coduri, vor putea să actualizeze doar codul dependent din C, dar nu vor putea corecta bind-urile Rust, deoarece nu cunosc Rust. La discuție a participat și James Bottomley, care coordonează subsistemul SCSI, care a spus că cu cât se codifică mai multă semantica în wrapper-e, cu atât acestea devin mai fragile din punct de vedere al asigurării sincronizării.

Între timp, compania Google, care anul trecut a rescris în Rust firmware-ul pvmfm, utilizat în virtuálne mašini, lansate pe platforma Android, a împărtășit experiența sa în integrarea treptată a codului scris în Rust în firmware-urile existente, inițial scrise în C sau C++. A fost demonstrat cum se poate îmbunătăți semnificativ securitatea firmware-urilor, creând componente identice ca funcționalitate, scrise în Rust. Se sugerează acordarea unei atenții deosebite utilizării Rust pentru codul nou și codul care îndeplinește funcții critice din punct de vedere al securității (de exemplu, codul de procesare a datelor externe, obținute din surse nesigure). Pentru integrarea codului Rust cu C se sugerează utilizarea de shim-uri, care traduc apelurile între API-urile Rust și C (API-ul C este exportat pentru utilizare în codul Rust și invers), permițând astfel rescrierea treptată a elementelor API în Rust.

Sursa: opennet.ro