Uscita di Rust 1.81. Ostacoli nella promozione di Rust nel kernel Linux

È stata pubblicata la release del linguaggio di programmazione Rust 1.81, originariamente sviluppato da Mozilla e ora mantenuto sotto l'egida dell'organizzazione no-profit indipendente Rust Foundation. Il linguaggio si concentra sulla gestione sicura della memoria e fornisce strumenti per ottenere elevato parallelismo nell'esecuzione dei compiti, senza fare uso di garbage collector e runtime (il runtime è limitato a una semplice inizializzazione e al supporto della libreria standard).

I metodi di gestione della memoria in Rust liberano gli sviluppatori dagli errori nella manipolazione dei puntatori e li proteggono da problematiche derivanti dal lavoro a basso livello con la memoria, come l'accesso a zone di memoria dopo la loro liberazione, la dereferenziazione di puntatori nulli, il superamento dei limiti del buffer, e così via. Per la distribuzione delle librerie, la gestione della compilazione e delle dipendenze, si è sviluppato un gestore di pacchetti chiamato Cargo. Le librerie sono ospitate nel repository crates.io.

La gestione sicura della memoria in Rust è garantita durante la compilazione tramite il controllo dei riferimenti, il tracciamento della proprietà degli oggetti, la gestione della durata degli oggetti (scope) e la valutazione della correttezza dell'accesso alla memoria durante l'esecuzione del codice. Rust offre anche strumenti per proteggere da overflow interi, richiede l'inizializzazione obbligatoria dei valori delle variabili prima dell'uso, gestisce meglio gli errori nella libreria standard, applica il concetto di riferimenti e variabili immutabili per impostazione predefinita e offre una forte tipizzazione statica per ridurre al minimo gli errori logici.

Novità principali:

• Stabilito il trait core::error::Error, che definisce le descrizioni degli errori restituiti. Questa modifica consente di utilizzare un unico trait Error in diverse librerie, indipendentemente dall'ambiente, incluse le librerie non legate alla libreria standard che utilizzano l'attributo «#![no_std]».
• Le funzioni di ordinamento stabili e instabili nella libreria standard sono state aggiornate per utilizzare nuovi algoritmi, che mostrano maggiori velocità di esecuzione e tempi di compilazione ridotti. Nell'implementazione dei nuovi algoritmi di ordinamento è stata garantita l'individuazione di tipi Ord errati e, in questi casi, viene generato un errore (panic) invece di dati raggruppati in modo casuale.
• Nel linter è stato implementato un nuovo livello di controllo "expect" ("#[expect(lint)]"), che consente di verificare che il controllo venga eseguito e di emettere un avviso se il controllo fallisce (a causa di un errore nell'implementazione o della disattivazione del controllo). Ad esempio, durante la conversione della base di codice per utilizzare il controllo undocumented_unsafe_blocks tramite Clippy, si può specificare "#[expect(clippy::undocumented_unsafe_blocks)]" per garantire che durante il passaggio tutte le aree unsafe siano documentate. In Clippy sono state inoltre implementate le verifiche clippy::allow_attributes e clippy::allow_attributes_without_reason, che semplificano la sostituzione degli attributi "#[allow]" con "#[expect(lint)]".
• È stata fornita la possibilità di documentare il motivo della sostituzione dei livelli di verifica (lint), fornendo ai nuovi sviluppatori informazioni sui motivi per cui è stata aggiunta una certa verifica, mostrata come messaggio del compilatore. Ad esempio: #![deny(clippy::float_arithmetic, reason = «no hardware float support»)]
• Una nuova serie di API è stata traslata nella categoria stabile, stabilizzando i metodi e le implementazioni dei tipi:
  • 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

  L'indicatore «const», che determina la possibilità di utilizzo in qualsiasi contesto al posto delle costanti, è stato applicato nelle funzioni:

  • char::from_u32_unchecked (funzione)
  • char::from_u32_unchecked (metodo)
  • CStr::count_bytes
  • CStr::from_ptr

  Il tipo std::panic::PanicInfo è stato rinominato in std::panic::PanicHookInfo (l'uso del vecchio nome è ancora supportato, ma dalla prossima versione, il suo utilizzo genererà un avviso). Nel frattempo, core::panic::PanicInfo rimarrà invariato, ma verrà sviluppato come un tipo separato. La separazione dei tipi permetterà di implementare metodi diversi, specifici per l'esecuzione nel contesto di snd e no_std.

• È stata completata la transizione all'ABI C-unwind (‘extern «C-unwind»‘), che differisce dall'ABI senza il suffisso «-unwind» (‘extern «C»‘) per la conservazione del comportamento sicuro (safe). Questo comportamento è mantenuto se il processo di 'unwinding' avviato a seguito di un'uscita imprevista del programma o di generazione di un'eccezione in stile C++ supera il confine dell'ABI (per esempio, quando un'eccezione sollevata nel codice di un linguaggio di programmazione influisce sullo stack associato al codice di un altro linguaggio durante l'unwinding). A partire dalla versione 1.81 di Rust, nell'ABI ‘extern «C»‘ è attivata l'uscita imprevista in caso di unwinding non gestito.
• È stato implementato un terzo livello di supporto per le piattaforme i686-unknown-redox, xtensa-esp32-none-elf, xtensa-esp32s2-none-elf, xtensa-esp32s3-none-elf, xtensa-esp32-espidf, xtensa-esp32s2-espidf, xtensa-esp32s3-espidf. Il terzo livello prevede un supporto di base, ma senza test automatizzati, pubblicazione di versioni ufficiali e verifica della capacità di compila il codice.
• È stato implementato un secondo livello di supporto per le piattaforme target loongarch64-unknown-linux-musl e arm64ec-pc-windows-msvc. Il secondo livello di supporto garantisce la possibilità di compilazione.
• Per i sistemi Linux sulla piattaforma LoongArch è stato fornito un completo set di strumenti e un profiler.
• È stata risolta una vulnerabilità (CVE-2024-43402) in std::process::Command, che si manifesta solo sulla piattaforma Windows, rimuovendo una via di sfruttamento di una vulnerabilità precedentemente corretta, BatBadBut, relativa alla gestione dei caratteri speciali nei chiamate a Command::arg e Command::args, progettate per un passaggio diretto degli argomenti al processo, senza l'elaborazione da parte dell'interprete dei comandi. In realtà, l'esecuzione di script .bat e .cmd avviava il processo cmd.exe, che possiede una propria logica di suddivisione degli argomenti. La vulnerabilità si basa sul fatto che Windows rimuove spazi e punti iniziali nei percorsi, quindi un file con estensione «.bat. .» viene trattato come «.bat».

Inoltre, va segnalato il ritiro di Wedson Almeida Filho dalla posizione di maintainer del progetto Rust for Linux, impegnato nell'integrazione di strumenti per lo sviluppo in linguaggio Rust nel kernel Linux. Dopo l'uscita di Wedson, il progetto conta ancora su altri due maintainer: Miguel Ojeda, autore e principale sviluppatore del progetto Rust-for-Linux, e Alex Gaynor, ex direttore della Python Software Foundation, passato alla promozione di Rust. Il maintainer uscente, che si è unito al progetto quattro anni fa, è un dipendente di Microsoft e autore di un driver sperimentale con implementazione del filesystem EXT2, scritto in Rust. Recentemente, il lavoro di Almeida si era concentrato sulla creazione di strumenti per lo sviluppo di filesystem in Rust. Quest'anno Almeida ha contribuito con 17 commit al repository di Rust-for-Linux (per confronto, Miguel Ojeda ha aggiunto 53 commit).

Tra le ragioni per la partenza si cita la mancanza di energia ed entusiasmo, che un tempo erano fondamentali per rispondere a alcune fandonie non tecniche (non-technical nonsense). Secondo Almeida, gli sviluppatori sono costretti a investire molta energia in dispute su questioni irrilevanti, che minano un obiettivo globale più importante. Almeida continua a credere che il futuro del kernel risieda nell'uso di linguaggi che garantiscano una gestione sicura della memoria, e se la comunità degli sviluppatori Linux non lo capirà, allora Linux verrà sostituito da un altro kernel, come è già avvenuto in passato con Unix.

I sostenitori del progetto Rust-for-Linux si sono trovati a dover affrontare la resistenza di sviluppatori veterani del kernel che non vedono la necessità di apprendere un nuovo linguaggio. Nella sua lettera di dimissioni, Almeida cita come esempio una discussione avvenuta durante il suo intervento insieme a Kent Overstreet alla conferenza "Linux Storage, Filesystem, Memory-Management, and BPF Summit", dedicata all'uso di Rust per lo sviluppo di filesystem. L'iniziativa di introdurre Rust è stata criticata da Ted Ts’o, autore dei filesystem ext2/ext3/ext4, il quale ha paragonato il progetto Rust-for-Linux a un tentativo di costringere tutti ad adottare la religione di Rust.

In risposta all'intento di Almeida di creare un wrapper sopra le interfacce dei file system scritte in C per utilizzarle nel codice Rust, Ted Tso ha sottolineato che un tale wrapper porterà inevitabilmente a problemi, poiché qualsiasi modifica agli interfaccie C e il refactoring richiederanno cambiamenti nel wrapper per Rust, e non vuole prendersi la responsabilità per la risoluzione dei problemi che potrebbero sorgere nel codice Rust e per il monitoraggio della situazione del wrapper Rust. Il codice in C è in costante evoluzione e se una sua modifica comprometterà il funzionamento del wrapper per Rust, ciò porterà a malfunzionamenti in tutti i file system collegati a quel wrapper.

Ted crede anche che, nel prossimo futuro, il binding per Rust rimarrà secondario e che i problemi nei binding saranno un mal di testa solo per gli sviluppatori di Rust-for-Linux, non per la comunità degli sviluppatori di file system nel kernel. Si osserva che non tutti gli sviluppatori intendono studiare Rust e, pertanto, dopo aver apportato modifiche che influenzano il codice altrui, potranno aggiornare solo il codice dipendente in C, ma non saranno in grado di correggere i binding in Rust, poiché non conoscono Rust. Alla discussione ha partecipato anche James Bottomley, che gestisce la sottosistema SCSI, il quale ha affermato che più semantica viene codificata nei binding, più diventano fragili in termini di sincronizzazione.

Nel frattempo, Google, che lo scorso anno ha riscritto in Rust il firmware pvmfm, utilizzato in macchine virtuali, lanciati sulla piattaforma Android, ha condiviso l'esperienza di un'integrazione graduale del codice in Rust nelle firmware esistenti, originariamente scritte in C o C++. È stato mostrato come si possa notevolmente aumentare la sicurezza delle firmware creando componenti di sostituzione identici nelle funzionalità, scritti in Rust. L'attenzione principale nell'implementazione di Rust dovrebbe essere rivolta all'uso di Rust per il nuovo codice e per quello che svolge funzioni critiche dal punto di vista della sicurezza (ad esempio, codice per la gestione di dati esterni provenienti da fonti non affidabili). Per integrare codice in Rust e C si suggerisce di utilizzare degli shim, che traducono le chiamate tra API in Rust e C (l'API C viene esportata per l'uso nel codice Rust e viceversa), consentendo una riscrittura graduale degli elementi API in Rust.

Fonte: opennet.ru