Greg Kroah-Hartman, responsabile del supporto per i rami stabili e \"staging\" del kernel Linux e maintainer di 16 sottomoduli del kernel, ha tenuto una presentazione alla conferenza Rust Week 2026, in cui ha spiegato come il linguaggio Rust possa contribuire a prevenire l'insorgere di vulnerabilit\u00e0 nel kernel causate da errori tipici degli sviluppatori in C nella gestione della memoria, nei lock, nel trattamento degli errori e nella gestione di dati non fidati. Il principale vantaggio di Rust \u00e8 la capacit\u00e0 di rilevare tali errori in fase di compilazione, piuttosto che durante la revisione del codice da parte di persone. Tuttavia, Rust non \u00e8 visto come una panacea in grado di risolvere tutti i problemi, e non c'\u00e8 alcuna intenzione di riscrivere il kernel in Rust: si prevede un'adozione graduale di Rust attraverso il suo utilizzo per nuovi driver e sottomoduli.<\/p>\n
Come esempio di errori nel kernel che potrebbero essere stati evitati usando Rust, \u00e8 stata citata un\u2019errore nel sottosistema Bluetooth, che era rimasto inosservato per 15 anni, e un problema nel hypervisor Xen. Nel primo caso, il programmatore ha effettuato l'indirizzamento di un puntatore senza verifica, mentre nel secondo ha dimenticato di rilasciare un lock nel codice di gestione degli errori.
\nSecondo Greg, la maggior parte degli errori nel kernel \u00e8 causata da piccole disattenzioni che si accumulano nel tempo e si manifestano come vulnerabilit\u00e0. In Rust molti di questi problemi vengono prevenuti dal compilatore; ad esempio, le astrazioni Rust per i lock nel kernel consentono l'accesso ai puntatori interni delle strutture solo dopo aver acquisito il lock corrispondente, che viene rilasciato automaticamente. Senza acquisire il lock, non \u00e8 possibile accedere ai puntatori delle strutture in Rust. <\/p>\n
Greg ritiene che tali funzionalit\u00e0 di Rust avrebbero evitato il 60% degli errori riscontrati nel kernel, e i controlli eseguiti dal compilatore avrebbero risparmiato tempo agli sviluppatori nelle discussioni con gli autori riguardo la correttezza della gestione degli errori e la giustificazione dell'impostazione dei lock nei punti giusti. Inoltre, l'integrazione del supporto per Rust ha gi\u00e0 avuto effetti positivi anche sul codice C nel kernel, contribuendo a migliorare la qualit\u00e0 del codice e delle interfacce, oltre a ispirare l'adozione di alcune tecniche di sviluppo (ad esempio, sono stati implementati lock con ambito limitato).<\/p>\n
Grazie al sistema di tipi che garantisce il rispetto delle regole stabilite e all'uso di sistemi di integrazione continua che controllano il codice durante la fase di build, durante la revisione delle modifiche su Rust, i revisori possono concentrarsi sulla verifica della logica operativa, piuttosto che sul monitoraggio delle manipolazioni delle risorse. L'uso di Rust consente anche di prestare maggiore attenzione ai dati provenienti dall'hardware o da sistemi esterni. Questo si ottiene grazie a una chiara distinzione tra dati affidabili e non affidabili a livello di sistema di tipi: \u00e8 sufficiente che lo sviluppatore esegua un'analisi durante la transizione da uno stato non affidabile a uno affidabile.<\/p>\n
Negli ultimi tempi, il team responsabile della sicurezza nel kernel pubblica ogni giorno circa 13 report su vulnerabilit\u00e0, il che, rispetto alla dinamica passata nella rilevazione di vulnerabilit\u00e0, suona quasi come una follia (per esempio, ieri sono stati pubblicati 277 report su vulnerabilit\u00e0 nel kernel). Secondo Greg, l'uso di Rust \u00e8 uno dei modi concreti per ridurre il numero di errori nel kernel causati da errori tradizionali nella gestione degli errori e delle risorse. Nel kernel, il supporto per Rust ha gi\u00e0 superato il limite dell'esperimento ed \u00e8 stato riconosciuto come una funzionalit\u00e0 standard del kernel alla fine dello scorso anno. <\/p>\n
![\"Guarda](\"https:\/\/img.youtube.com\/vi\/0vhGWclF7LU\/hqdefault.jpg\")
\r\n