LLM4C2Rust: Large Language Models for Automated Memory-Safe Code Transpilation

1. Il Problema

La sicurezza della memoria è una sfida critica nell'ingegneria del software, specialmente per i sistemi legacy scritti in linguaggi non sicuri come C e C++. Si stima che circa il 70% delle vulnerabilità di sicurezza derivi da problemi di gestione della memoria (es. overflow di buffer, puntatori dangling, race condition).
Sebbene Rust offra garanzie di sicurezza della memoria a livello di compilatore attraverso il suo modello di proprietà e prestito, la migrazione manuale di grandi codebase C/C++ verso Rust è costosa, lenta e soggetta a errori.
Gli approcci automatizzati esistenti si dividono in due categorie:

• Basati su regole: Spesso producono codice Rust non idiomatico che mantiene blocchi unsafe e idiomi C, limitando i benefici di sicurezza.
• Basati su LLM (Large Language Models): Possono generare codice più idiomatico, ma soffrono di allucinazioni (generazione di informazioni false) e mancanza di garanzie semantiche, portando a codice che potrebbe non compilare o non essere sicuro come previsto.

L'obiettivo della ricerca è sviluppare un framework automatizzato che trasformi il codice C/C++ in Rust sicuro, minimizzando le allucinazioni e massimizzando la correttezza della memoria.

2. Metodologia

Gli autori propongono un framework ibrido che integra LLM (Large Language Models) con una pipeline RAG (Retrieval-Augmented Generation) e un modello SLM (Small Language Model).

Architettura del Framework

Il processo si articola in diverse fasi:

1. Segmentazione del Codice: Il codice sorgente C/C++ viene suddiviso in blocchi bilanciati (basati su parentesi graffe {}) di almeno 500 caratteri. Questo garantisce che le funzioni non vengano tagliate a metà e fornisce contesto sufficiente all'LLM rispettando i limiti di token.
2. Traspilazione a Due Stadi:
   • Fase 1 (Traspilazione Iniziale): Ogni segmento viene convertito in Rust "non sicuro" (unsafe), permettendo l'uso di puntatori grezzi e cast per preservare il comportamento originale.
   • Fase 2 (Raffinamento): Il codice Rust generato viene inviato a un secondo passaggio di prompt. L'LLM riceve istruzioni specifiche per migliorare la sicurezza, eliminando puntatori grezzi e cast non sicuri.
3. Integrazione RAG: Durante la fase di raffinamento, il sistema recupera contesto rilevante da una base di conoscenza esterna (documentazione Rust, best practice di sicurezza, esempi di gestione sicura dei puntatori). Questo contesto viene aggiunto al prompt per guidare l'LLM e ridurre le allucinazioni.
4. Verifica e Validazione:
   • L'LLM stima autonomamente il numero di violazioni (puntatori grezzi, cast non sicuri).
   • Un compilatore Rust (rustc) e script Bash personalizzati verificano il codice generato, estraendo codici di errore specifici (es. E0133, E0392 per i puntatori grezzi; E0604-E0607 per i cast) e contando le righe di codice non sicuro (unsafe lines of code - ULoCs).

Modelli Utilizzati

Lo studio ha testato tre modelli OpenAI:

• GPT-4o e GPT-4-Turbo (LLM di grandi dimensioni).
• o3-mini (SLM - Small Language Model).

3. Contributi Chiave

1. Framework Ibrido RAG-LLM: Proposta di una nuova architettura che combina la fluidità generativa degli LLM con la precisione contestuale del RAG per la traspilazione C/C++ -> Rust.
2. Valutazione della Sicurezza: Analisi approfondita della capacità degli LLM di generare codice Rust che sia sia funzionale che intrinsecamente sicuro, superando i limiti degli approcci puramente basati su regole.
3. Mitigazione delle Allucinazioni: Dimostrazione empirica che l'arricchimento del prompt con dati recuperati (RAG) riduce significativamente il tasso di allucinazioni, migliorando l'allineamento tra le stime dell'LLM e la realtà verificata dal compilatore.
4. Benchmark Esteso: Valutazione su un dataset diversificato di 7 programmi GNU Coreutils (es. uniq, cat, tail), confrontando i risultati con approcci precedenti come C2SaferRust e LAC2R.

4. Risultati Sperimentali

Gli esperimenti hanno misurato la riduzione di tre metriche chiave:

• RPD (Raw Pointer Dereferences): Dereferenziamento di puntatori grezzi.
• UTC (Unsafe Type Casts): Cast di tipo non sicuri.
• ULoCs (Unsafe Lines of Code): Righe di codice all'interno di blocchi unsafe.

Punti salienti:

• GPT-4-Turbo ha ottenuto i risultati migliori, eliminando quasi completamente RPD e UTC in 5 dei 7 programmi testati (es. uniq, cat, head, split, truncate). Ha mostrato la maggiore coerenza tra le stime self-reported e la verifica del compilatore.
• GPT-4o ha mostrato ottime prestazioni, riducendo drasticamente le strutture non sicure, sebbene con lievi imprecisioni numeriche in programmi più complessi come tail.
• o3-mini (SLM): Ha prodotto codice sintatticamente corretto ma ha mostrato un tasso di allucinazione più elevato. Spesso sovrastimava i miglioramenti di sicurezza (es. dichiarando la rimozione di puntatori grezzi che il compilatore rilevava ancora presenti). Tendeva a usare direttive dichiarative (#![forbid(unsafe_code)]) senza necessariamente risolvere le violazioni sottostanti.
• Confronto con lo Stato dell'Arte: L'approccio RAG-assisted ha superato significativamente metodi precedenti come C2SaferRust e LAC2R, raggiungendo riduzioni superiori al 90% nelle strutture non sicure in diversi casi.

5. Significato e Implicazioni

Questo lavoro dimostra che l'uso di LLM potenziati da RAG è una via praticabile ed efficace per la modernizzazione automatica del software legacy.

• Sicurezza: Il framework non solo trasla il codice, ma migliora attivamente la sua sicurezza, eliminando vulnerabilità comuni prima della compilazione.
• Affidabilità: L'integrazione del RAG mitiga il problema delle allucinazioni, rendendo gli LLM più affidabili per compiti critici di ingegneria del software dove la precisione è fondamentale.
• Scalabilità: Sebbene lo studio si sia limitato a utility Coreutils, i risultati suggeriscono che questo approccio può essere scalato per migrare sistemi critici complessi, riducendo il costo e il rischio associati alla migrazione manuale verso linguaggi sicuri come Rust.

In sintesi, il paper conferma che l'automazione basata sull'IA, se guidata da contesto rilevante e verificata da strumenti statici, può accelerare la transizione verso un ecosistema software più sicuro.