Trent’anni di un solo linguaggio
Per oltre trent’anni il kernel Linux è stato scritto esclusivamente in C, con piccole porzioni in assembly per le interfacce hardware di basso livello. Il C offre il controllo diretto sulla memoria e sull’hardware che un kernel richiede, ma a un costo noto: le vulnerabilità di memory safety — use-after-free, buffer overflow, data race — rappresentano una quota consistente dei bug di sicurezza del kernel. I dati del progetto Google Android indicano che la maggior parte delle vulnerabilità critiche nei componenti kernel deriva da errori di gestione della memoria.
La proposta di introdurre Rust come secondo linguaggio nel kernel, discussa per anni nella comunità, raggiunge un traguardo concreto con il kernel 6.1.
L’infrastruttura Rust nel kernel 6.1
Il kernel 6.1, il cui merge window si chiude nell’ottobre 2022, include l’infrastruttura iniziale per scrivere moduli kernel in Rust. Non si tratta di riscrivere componenti esistenti: l’obiettivo è permettere lo sviluppo di nuovi driver e moduli in un linguaggio che elimina per costruzione intere classi di bug di memoria.
L’infrastruttura comprende diversi componenti. I binding verso le API C del kernel permettono al codice Rust di interagire con le strutture dati e le funzioni del kernel esistente. Un allocatore personalizzato integra il sistema di allocazione della memoria del kernel con il modello di ownership di Rust. Un panic handler specifico gestisce le situazioni di errore irrecuperabile nel contesto kernel, dove un panic non può semplicemente terminare il processo.
Le sfide dell’integrazione
Integrare Rust in un progetto C di trenta milioni di righe presenta sfide uniche. Le convenzioni ABI devono essere compatibili: le strutture dati Rust che attraversano il confine con il C devono rispettare il layout di memoria C. Il build system del kernel, basato su Kbuild e Make, deve supportare la compilazione Rust accanto al C.
Il dibattito nella comunità kernel è stato lungo. Linus Torvalds ha accolto la proposta con pragmatismo, accettando il merge nella release 6.1. Altri maintainer hanno espresso perplessità sulla complessità aggiuntiva. La decisione finale è stata di procedere in modo incrementale: l’infrastruttura entra nel kernel, i primi driver sperimentali seguiranno.
Un obiettivo preciso: i nuovi driver
L’obiettivo dichiarato non è riscrivere i sottosistemi esistenti — un’impresa improponibile per dimensione e rischio. L’obiettivo è offrire ai futuri sviluppatori di driver — uno dei componenti kernel più soggetti a bug di memoria — uno strumento che prevenga le vulnerabilità a tempo di compilazione anziché rilevarle a runtime.
Un precedente storico
Per la prima volta in trent’anni, il kernel accoglie un secondo linguaggio di programmazione a livello di sistema. La decisione riflette un riconoscimento pragmatico: il C resta insostituibile per il codice esistente, ma per il nuovo codice esiste un’alternativa che offre garanzie di sicurezza senza sacrificare le prestazioni.
Link: kernel.org