Filip Pizlo ha presentato alla conferenza SPLASH'24 il compilatore open source C\/C++ Fil-C, che offre protezione contro i problemi causati da errori di gestione della memoria. Il progetto mira a garantire la piena compatibilit\u00e0 con il codice esistente in C e C++: per garantire una gestione sicura della memoria \u00e8 sufficiente ricompilare il codice gi\u00e0 esistente. Il compilatore \u00e8 costruito utilizzando componenti del progetto LLVM ed \u00e8 distribuito con licenza Apache 2.0. Il Runtime \u00e8 fornito con licenza BSD. A differenza del recentemente annunciato progetto TrapC, attualmente in fase di progettazione, il compilatore Fil-C \u00e8 gi\u00e0 pronto per la compilazione del codice esistente. <\/p>\n
Il progetto include anche varianti delle librerie standard C (libc) e C++ (libc++) che funzionano in sicurezza con la memoria, basate sulle librerie Musl e LLVM libc++. Tra l'altro, nei programmi compilati possono essere utilizzate funzionalit\u00e0 come il multithreading, la gestione dei segnali, il mapping dei file in memoria (mmap), longjmp\/setjmp e la gestione delle eccezioni in C++. Utilizzando Fil-C, \u00e8 possibile compilare progetti come bzip2, zip, pcre e ncurses senza modifiche. Con lievi modifiche \u00e8 supportata la compilazione di OpenSSH, OpenSSL, CPython, SQLite, Lua, Curl, Lynx, jpeg6b, zsh, xzutils e simdutf. <\/p>\n
La protezione contro i problemi di memoria \u00e8 garantita grazie all'uso di puntatori MonoCaps a 128 bit con metadati per il controllo dei tipi e il monitoraggio dei confini dei buffer, oltre all'implementazione di un garbage collector FUGC, che gestisce tutte le operazioni di allocazione e liberazione della memoria. In caso di errori nella gestione della memoria, l'applicazione si arresta immediatamente, impedendo l'esploatazione di potenziali vulnerabilit\u00e0. <\/p>\n
Si afferma che la combinazione di MonoCaps e FUGC consente di rilevare e bloccare tutti gli errori legati all'overflow del buffer nello stack e nell'heap, all'accesso alla memoria gi\u00e0 liberata, alle condizioni di gara nell'uso dei puntatori, nonch\u00e9 a una gestione errata dei tipi (Type Confusion) nel contesto dell'incrocio tra puntatori e non puntatori, problemi nella composizione dinamica (linking) e uso scorretto di va_lists. Inoltre, Fil-C verifica separatamente i limiti e i tipi nei buffer trasmessi alle chiamate di sistema. <\/p>\n
Il prezzo da pagare per l'utilizzo di Fil-C per proteggere i progetti esistenti, senza la necessit\u00e0 di riscrivere il loro codice o di impiegare costrutti linguistici speciali, \u00e8 una riduzione delle prestazioni. In questa fase di sviluppo, i programmi compilati in Fil-C sono pi\u00f9 lenti di circa 1,5-5 volte rispetto ai compilatori tradizionali. Sono previsti lavori di ottimizzazione. Si stima che, al termine di questa fase, il codice sar\u00e0 eseguito pi\u00f9 lentamente di 1,2 volte nella maggior parte dei casi, mentre nei peggiori scenari il rallentamento non superer\u00e0 una volta e mezzo. Attualmente, il compilatore supporta solo la piattaforma Linux su sistemi X86_64. Le versioni precedenti supportavano macOS e FreeBSD, ma \u00e8 stato deciso di non disperdere gli sforzi e preparare all'inizio un porting di qualit\u00e0 della libc per una sola piattaforma. <\/p>\n
Un altro limite di Fil-C \u00e8 il rifiuto fondamentale di mantenere la compatibilit\u00e0 a livello ABI per il codice C\/C++, il che impedisce il collegamento del codice compilato in Fil-C con le librerie e i file oggetto compilati da altri compilatori. I metodi di chiamata delle funzioni e il modo di collegamento dinamico in Fil-C sono diversi rispetto ai compilatori e linker esistenti. Questa scelta \u00e8 giustificata dal fatto che il collegamento con codice non protetto annulla l'essenza della protezione offerta da Fil-C e crea un'illusione di applicazione protetta: con la compatibilit\u00e0 ABI, gli sviluppatori sarebbero stati tentati di compilare in Fil-C solo singoli file, senza preoccuparsi di portare l'intero progetto. <\/p>\n
Il meccanismo MonoCap utilizzato in Fil-C si basa su puntatori a 16 byte, nei quali oltre all'indirizzo di memoria, c'\u00e8 un riferimento a un oggetto che include informazioni sulle capacit\u00e0 (capability), come i limiti superiori e inferiori del buffer associato al puntatore, cos\u00ec come un array che definisce i tipi di dati memorizzati in ciascun blocco di memoria (1 byte con informazioni sul tipo (unset, int, ptr, free) per ogni blocco di memoria di 16 byte). Ogni accesso alla memoria tramite il puntatore verifica i limiti e il tipo (ad esempio, nella memoria di tipo 'ptr' non possono essere scritti dati di tipo 'int' e viceversa). <\/p>\n
Tutte le operazioni di allocazione e rilascio della memoria sono gestite dal garbage collector FUGC (Fil's Unbelievable Garbage Collector), il quale, quando una memoria viene liberata, segna tutte le informazioni sui tipi associate al buffer liberato come 'free' e poi reindirizza tutti i puntatori agli oggetti liberati verso un oggetto separato che segnala che la memoria \u00e8 gi\u00e0 stata liberata. Qualsiasi successivo accesso a un blocco di dati di tipo 'free' o tramite un puntatore collegato a un oggetto liberato genera un'eccezione, proteggendo cos\u00ec da vulnerabilit\u00e0 di tipo use-after-free. Il garbage collector opera in parallelo e non interrompe l'esecuzione di altri thread. <\/p>\n
L'uso combinato di MonoCaps e FUGC consente di mantenere la consueta operativit\u00e0 con i puntatori e di preservare la semantica delle chiamate malloc e free, garantendo al contempo una protezione sicura. Il codice del programma pu\u00f2 contenere vari errori logici, come cast di tipo errati, operazioni aritmetiche errate con i puntatori, condizioni di race e chiamate non tempestive alla funzione free(), ma indipendentemente da tutto ci\u00f2, Fil-C ricorder\u00e0 i limiti originali e il tipo di dato, interrompendo l'esecuzione qualora venga tentato l'accesso tramite un puntatore a un'area al di fuori dei limiti memorizzati, o la lettura di dati di tipo 'int' come puntatore o viceversa. <\/p>\n
L'autore Fil-C, Filip Pizlo, ricopre in Epic Games il ruolo di direttore responsabile dei progetti legati ai linguaggi di programmazione. Filippo ha una vasta esperienza nello sviluppo di macchine virtuali, linguaggi di programmazione, compilatori e garbage collector. Ad esempio, presso IBM ha sviluppato il linguaggio di programmazione X10, presso Microsoft ha lavorato sui garbage collector Stopless, Clover e Chicken, mentre in Apple si \u00e8 occupato del compilatore JIT e delle ottimizzazioni del motore di rendering del browser WebKit. In Epic Games guida il team di sviluppatori che sta sviluppando il linguaggio di programmazione Verse e la relativa macchina virtuale. Filippo \u00e8 anche uno dei principali sviluppatori di macchine virtuali<\/a> Jikes RVM, Ovm e Fiji VM. \r\n ![\"Riproduci](\"https:\/\/img.youtube.com\/vi\/_VF3pISRYRc\/hqdefault.jpg\")
\r\n