In questo articolo Indice dei contenuti 2 sezioni
Automatizzare la conversione del codice C in Rust senza costringere gli sviluppatori a riscrivere tutto a mano: è questa la scommessa di Canonical, che ha avviato insieme alla University of Bristol un progetto di ricerca lungo tre anni. L’idea non è semplicemente tradurre la sintassi da un linguaggio all’altro, operazione già alla portata di diversi strumenti, ma arrivare a produrre codice Rust leggibile, sicuro e soprattutto fedele al comportamento dell’originale scritto in C.
Il nodo è tutt’altro che teorico. Chi mantiene software di sistema, componenti di sicurezza o infrastrutture mature si trova davanti a repository con centinaia di migliaia di righe accumulate negli anni, piene di correzioni, ottimizzazioni e comportamenti consolidati che nessuno vuole perdere. Riscrivere da zero significa spesso bruciare anni di lavoro e rischiare regressioni difficili da individuare. Il progetto punta quindi a mettere insieme machine learning, analisi dei programmi, testing e metodi formali per trasformare quei repository riducendo al minimo il ricorso a blocchi unsafe.
Perché il passaggio da C a Rust interessa così tanto
Una fetta enorme del software critico continua a poggiare su C e C++, linguaggi che danno un controllo chirurgico su memoria e hardware ma scaricano sul programmatore la responsabilità di evitare errori come use after free, buffer overflow, dereferenziazioni non valide e race condition. Rust nasce proprio per bloccare molte di queste classi di bug già in fase di compilazione, senza rinunciare al controllo diretto su memoria e risorse e senza garbage collector.
I numeri spiegano l’interesse crescente delle aziende. Google ha riferito che in Android la quota di vulnerabilità legate alla sicurezza della memoria è passata dal 76% del 2019 al 24% del 2024, mano a mano che cresceva la quota di codice scritto con linguaggi memory safe. Gli stessi tecnici stimano che circa il 70% delle vulnerabilità gravi nei grandi codebase basati su linguaggi non memory safe appartenga storicamente a questa famiglia. Rust del resto non è più una curiosità sperimentale: la versione 1.0 risale al 15 maggio 2015 e da allora ha messo radici in sistemi operativi, firmware, browser e componenti di sicurezza.
Ubuntu ha già adottato implementazioni Rust di strumenti storicamente legati al mondo Unix, come uutils coreutils, reimplementazione multipiattaforma delle GNU Core Utilities, e la versione Rust di sudo. Sono però progetti nati e mantenuti come implementazioni autonome, una cosa ben diversa dal tradurre automaticamente un repository C già esistente.
AppArmor come banco di prova, non come annuncio
Per capire fin dove può spingersi il metodo, Canonical userà casi di studio reali come AppArmor e snap confine. La società tiene però a chiarire un punto: la loro presenza nel progetto non equivale a dire che verranno riscritti in Rust. Serviranno a misurare difficoltà, limiti e affidabilità dell’approccio su codice vero, non su esempi di laboratorio.
C’è poi la parte più delicata, quella della verifica. Il codice Rust generato verrà considerato non attendibile finché strumenti indipendenti non avranno raccolto prove sufficienti della sua correttezza. Il compilatore Rust può dimostrare parecchie proprietà sulla gestione della memoria, ma non ha modo di sapere se una funzione convertita calcoli esattamente quello che calcolava la sua controparte in C.
Per l’equivalenza comportamentale i ricercatori intendono combinare fuzz testing e tecniche formali. Con il fuzzing si generano grandi quantità di input, compresi valori anomali e combinazioni pensate per toccare percorsi di esecuzione raramente esercitati, poi si eseguono la versione C e quella Rust confrontando risultati e comportamento osservabile. Un’idea simile è già stata sperimentata da C2Rust con il suo sistema di cross checking, che mette a confronto le tracce di esecuzione delle due versioni per scovare divergenze. Qui l’ambizione è andare oltre, affiancando ai test controlli ancora più rigorosi.
Il punto, insomma, non è far scrivere Rust a un’intelligenza artificiale, cosa che i modelli generativi sanno già fare in modo discreto, ma dimostrare con prove tecniche che centinaia di migliaia di righe generate automaticamente possano sostituire codice C maturo senza cambiarne il comportamento. Ed è anche il motivo per cui la ricerca durerà tre anni.
