Dentro Fil-C: Un Modello Semplificato per C/C++ Sicuro in Termini di Memoria

Decodificare Fil-C: Sicurezza della Memoria per il Codice Legacy

Nella continua ricerca di una programmazione di sistema sicura, è emerso un nuovo contendente chiamato Fil-C, che si propone come un'implementazione sicura in termini di memoria di C e C++. Mentre il sistema di produzione implica complesse riscritture di LLVM IR, un modello semplificato recentemente pubblicato demistifica i suoi concetti fondamentali. Questo modello rivela una trasformazione automatica del codice sorgente che cambia fondamentalmente il modo in cui operano i puntatori, introducendo un garbage collector in un ambiente di gestione della memoria notoriamente manuale.

La Trasformazione Fondamentale: Un AllocationRecord per Ogni Puntatore

Al suo interno, il modello semplificato di Fil-C aggiunge un livello di metadati ombra a ogni puntatore. All'interno di ogni funzione, ogni variabile locale di tipo puntatore acquisisce una variabile companion AllocationRecord*. Questo record, una struttura di dati contenente limiti e metadati, diventa il guardiano per gli accessi alla memoria.

Le semplici operazioni sui puntatori vengono riscritte per propagare questi metadati. Un'assegnazione come p1 = p2; diventa p1 = p2, p1ar = p2ar;. Fondamentalmente, il casting di un valore non puntatore a un tipo puntatore risulta in un AllocationRecord NULL, contrassegnandolo come insicuro. Questa riscrittura fondamentale prepara il terreno per controlli di sicurezza completi.

L'Allocazione di Memoria Ottiene un Revisione di Sicurezza

Il modello intercetta le chiamate alla libreria standard. Una chiamata a malloc(size) viene riscritta per chiamare filc_malloc(size). La filc_malloc semplificata esegue un'azione sorprendente: esegue tre allocazioni distinte invece di una.

• Una per la memoria utente richiesta (visible_bytes).
• Una per un array invisible_bytes corrispondente, che memorizzerà i metadati AllocationRecord* per eventuali puntatori memorizzati all'interno della memoria utente.
• Una per la struct AllocationRecord stessa, che collega le altre due allocazioni.

Questa struttura tripartita è il motore della sicurezza di Fil-C. Ora ogni allocazione heap porta con sé informazioni sulla sua provenienza e sui suoi limiti.

Controllo dei Limiti e Sicurezza dei Caricamenti di Puntatori

Dereferenziare un puntatore non è più un semplice recupero di memoria. La trasformazione inserisce controlli sui limiti utilizzando l'AllocationRecord* associato. Ad esempio, leggere un intero diventa un controllo che l'offset sia all'interno della regione visible_bytes.

Il sistema diventa più sofisticato quando il valore caricato o memorizzato è esso stesso un puntatore. Poiché il compilatore non può vedere direttamente nella memoria heap, utilizza l'array invisible_bytes. Se un puntatore risiede in visible_bytes + i, il suo AllocationRecord* associato viene memorizzato in invisible_bytes + i. Ciò garantisce che i metadati dei puntatori fluiscano correttamente attraverso le strutture di dati.

L'Inevitabile Garbage Collector

Una rivelazione fondamentale del modello è che Fil-C introduce un garbage collector in C/C++. La funzione filc_free semplificata libera solo le allocazioni visible_bytes e invisible_bytes, lasciando l'AllocationRecord stesso. Un GC, che potrebbe essere un semplice garbage collector stop-the-world, successivamente traccia questi record, liberando quelli irraggiungibili e chiamando filc_free su di essi.

Ciò ha implicazioni profonde: dimenticare di chiamare free non causa più una perdita di memoria. Tuttavia, le chiamate esplicite a free rimangono preziose per il rilascio tempestivo delle risorse. Il GC abilita anche operazioni sicure di indirizzo-di su variabili locali promuovendole all'heap quando il loro indirizzo potrebbe sfuggire.

Gestire l'Imprevedibile: Memmove e Provenienza

Funzioni come memmove rappresentano una sfida unica, poiché operano su intervalli di byte arbitrari senza informazioni sul tipo. La soluzione di Fil-C è un'euristica: sposta i metadati dei puntatori (invisible_bytes) solo per intervalli che sono correttamente allineati per i puntatori. Ciò porta al curioso risultato che spostare otto byte allineati si comporta diversamente da otto spostamenti separati di un singolo byte.

Questo rigoroso monitoraggio dei metadati dei puntatori rende Fil-C un sistema concreto con una provenienza dei puntatori esplicita. Invalida le ottimizzazioni del compilatore che assumono che p1 e p2 siano intercambiabili se detengono lo stesso indirizzo, poiché possono trasportare metadati AllocationRecord* diversi.

Complessità di Produzione e Casi d'Uso nel Mondo Reale

Il modello semplificato elimina complessità significative richieste per un sistema di produzione. La concorrenza richiede un GC più sofisticato e una gestione attenta delle operazioni atomiche. I puntatori a funzione richiedono metadati aggiuntivi e potenzialmente un ABI di chiamata uniforme per prevenire attacchi di confusione del tipo.

Le preoccupazioni ovvie sono le prestazioni e l'overhead di memoria, che sollecitano potenziali ottimizzazioni come l'allocazione pigra di invisible_bytes o la collocazione dei metadati. Quindi, quando si utilizzerebbe un tale sistema? L'autore suggerisce diversi scenari:

1. Proteggere grandi basi di codice C/C++ esistenti con un GC e un compromesso di prestazioni per la sicurezza della memoria, forse come un passo intermedio verso una riscrittura.
2. Come strumento per trovare bug, simile all'esecuzione del codice sotto AddressSanitizer (ASan).
3. Abilitare una valutazione sicura in fase di compilazione in linguaggi come Zig, dove il linguaggio di compilazione e il linguaggio di runtime sono gli stessi.
4. Come modello pratico per studiare la provenienza dei puntatori e la semantica del compilatore.

Un Compromesso Strategico per un Problema Persistente

Fil-C rappresenta un approccio radicale e ingegnerizzato a un problema vecchio di decenni. Non cambia i linguaggi C/C++ ma trasforma il loro modello di esecuzione, scambiando il controllo manuale con la sicurezza automatizzata attraverso metadati e garbage collection. Sebbene il costo delle prestazioni sia sostanziale, il modello fornisce un chiaro progetto meccanico per dotare di sicurezza della memoria il codice insicuro - un'opzione convincente in un mondo in cui le basi di codice C e C++ legacy rimangono critiche e vulnerabili.