Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby

Questo articolo analizza le insidie specifiche nell'implementazione di macchine virtuali su CHERI, emerse durante il porting di CRuby, evidenziando come le assunzioni sul comportamento indefinito del linguaggio C tipiche delle architetture tradizionali causino fallimenti sotto il modello di sicurezza più rigoroso di CHERI e proponendo soluzioni validate.

L'essenziale

Ecco una spiegazione semplice e creativa di questo articolo, pensata per chiunque, anche senza un background tecnico.

🛡️ Il Viaggio di CRuby nel Regno delle "Chiavi Magiche"

Immagina di vivere in una città molto vecchia e caotica (i computer di oggi). In questa città, le persone usano indirizzi di casa per trovare le cose. Se ti dico "Vai al numero 123", tu vai al numero 123. Ma c'è un problema: se qualcuno ti dà un foglietto con scritto "123", non sai se quel numero è valido, se appartiene davvero a te, o se puoi entrare in quella casa per solo 5 minuti o per sempre. È come se chiunque potesse rubare un indirizzo e usarlo per entrare in case che non gli appartengono, causando disastri (i famosi "bug" di sicurezza).

CHERI è come un nuovo sistema di sicurezza per questa città. Invece di semplici indirizzi, ora usiamo Chiavi Magiche (Capability).
Ogni Chiave Magica non dice solo "Vai al numero 123", ma dice: "Puoi andare al numero 123, ma solo per entrare nella porta principale, solo per 10 minuti, e non puoi toccare il giardino". Se qualcuno prova a usare la chiave per fare qualcosa che non è scritto sopra (come entrare in una stanza chiusa), la chiave si rompe e il sistema ti blocca immediatamente.

🐘 Il Problema: Portare un Elefante in una Casa Nuova

Gli autori dello studio hanno preso CRuby, che è come un enorme elefante (il motore che fa funzionare il linguaggio di programmazione Ruby), e hanno provato a farlo vivere in questa nuova città delle Chiavi Magiche.

Il problema è che l'elefante è cresciuto nella città vecchia. Ha abitudini radicate. Ad esempio, l'elefante pensa: "Se ho un numero 123, posso usarlo per aprire qualsiasi porta che ho visto prima". Ma nella città delle Chiavi Magiche, questo comportamento è vietato e pericoloso.

L'articolo racconta le trappole (i "pitfalls") che hanno incontrato e come le hanno superate.

🕵️‍♂️ Le 6 Trappole Principali (e come le hanno risolte)

Ecco le situazioni più strane che hanno trovato, spiegate con metafore:

1. La Trappola del "Foglio Strappato" (Invalid Derived Pointer)

• La situazione: L'elefante prende un foglio con un indirizzo, lo strappa in due e usa la metà per cercare qualcos'altro. Nella città vecchia funziona. Nella città delle Chiavi, la metà del foglio non è più una chiave valida perché ha perso i suoi "bordi di sicurezza".
• La soluzione: Invece di strappare il foglio, l'elefante tiene sempre una Chiave Maestra (una chiave con bordi molto ampi) che copre tutta la zona. Quando deve cercare qualcosa, usa la Chiave Maestra per creare una nuova chiave temporanea sicura.
• Il rischio: Avere una chiave che apre troppe porte può essere rischioso, quindi bisogna stare attenti a non lasciarla incustodita.

2. La Trappola del "Finto Indirizzario" (Dereferencing Ambiguous Pointers)

• La situazione: Il sistema di sicurezza dell'elefante (il Garbage Collector) guarda i numeri sulla scrivania e dice: "Quello sembra un indirizzo! Proviamo ad aprirlo!". A volte, però, quel numero è solo un numero casuale (come un numero di telefono scritto su un post-it) e non una vera chiave. Nella città vecchia, l'elefante provava ad aprirlo e si faceva male. Nella città delle Chiavi, il sistema gli urla: "Ehi! Quella non è una chiave vera!" e lo blocca.
• La soluzione: Prima di provare ad aprire la porta, l'elefante controlla se c'è il sigillo di validità sulla chiave. Se il sigillo manca, non prova nemmeno ad aprirla.
• Il vantaggio: In realtà, questo rende l'elefante più veloce perché non perde tempo a cercare di aprire porte che non esistono.

3. La Trappola del "Ristrutturatore di Casa" (In-Place Reallocation)

• La situazione: L'elefante ha un magazzino. Quando ha bisogno di più spazio, chiama un muratore che allarga il magazzino senza spostarlo. L'elefante pensa: "Ok, il magazzino è più grande, ma la mia chiave vecchia va ancora bene perché è sempre allo stesso posto".
• Il problema: Nella città delle Chiavi, quando il muratore allarga il magazzino, la chiave vecchia dice ancora "Posso arrivare fino al muro vecchio". Se l'elefante prova a mettere un oggetto nella nuova parte del magazzino, la chiave si rompe perché dice "Non puoi andare oltre il muro vecchio!".
• La soluzione: L'elefante deve smettere di fidarsi che il magazzino rimanga nello stesso posto. Ogni volta che il muratore allarga la stanza, l'elefante deve cambiare la chiave con una nuova che copre l'intera nuova stanza.

4. La Trappola dei "Bit di Riempimento" (Using Padding Bits)

• La situazione: L'elefante usa dei cassetti per mettere piccoli oggetti (bit). Nella città vecchia, il cassetto era pieno di oggetti. Nella città delle Chiavi, il cassetto è più grande e ha dei spazi vuoti (padding) pieni di polvere o informazioni segrete che non dovresti toccare.
• Il problema: L'elefante cerca di scrivere in tutti gli spazi del cassetto, inclusi quelli vuoti. Questo rovina le informazioni segrete o causa errori.
• La soluzione: L'elefante deve usare cassette di dimensioni esatte (esattamente 64 bit) che non hanno spazi vuoti, così sa esattamente dove può scrivere.

5. La Trappola del "Foglio Sigillato" (Modifying Temporary Capabilities)

• La situazione: Alcune chiavi sono sigillate (come un contratto legale). Non puoi modificarle, altrimenti si rompono. L'elefante, però, prende una chiave sigillata, la piega un po' per fare un calcolo matematico e poi la rimette a posto.
• Il problema: Appena piega la chiave sigillata, questa si rompe e il sistema si blocca.
• La soluzione: Prima di piegare la chiave per fare calcoli, l'elefante la copia su un foglio di carta normale (un numero intero), fa i calcoli sulla carta, e poi usa il risultato. Non tocca mai la chiave originale.

6. La Trappola del "Trucco Matematico" (Pointer Arithmetic on Non-Capability Type)

• La situazione: L'elefante fa un trucco: prende una chiave, la trasforma in un numero, fa una somma, e la rimette a posto sperando che torni una chiave valida.
• Il problema: Se usa il tipo sbagliato di numero (come un numero generico invece di una "Chiave-Numero"), quando rimette tutto insieme, la chiave risultante è rotta o falsa.
• La soluzione: Usa sempre il tipo di numero giusto (quello che sa trasformarsi di nuovo in una chiave valida) per fare i calcoli.

📊 Risultati: L'Elefante è diventato più lento?

Gli autori hanno fatto delle prove. Hanno scoperto che, dopo aver corretto tutti questi errori:

• L'elefante (CRuby) funziona quasi alla stessa velocità di prima (circa il 98% della velocità originale).
• In alcuni casi molto specifici (come quando l'elefante deve saltare su e giù velocemente), è stato un po' più lento perché ha dovuto usare metodi più sicuri e meno "truccati".
• Ma il guadagno in sicurezza è enorme: l'elefante ora è molto più difficile da hackerare o da far crollare.

💡 La Lezione Finale

Questo studio ci insegna che quando portiamo software vecchio (come i motori delle lingue di programmazione) su nuove tecnologie di sicurezza (come CHERI), non basta dire "funziona". Dobbiamo cambiare il modo in cui pensiamo agli indirizzi e alla memoria.

Le vecchie abitudini di "fai da te" e di assumere che "se funziona ora, funzionerà sempre" sono pericolose. Dobbiamo essere più precisi, usare le chiavi giuste e non fidarci dei numeri a caso. È un lavoro difficile, ma è l'unico modo per costruire un futuro digitale più sicuro.

Sommario tecnico

Ecco una sintesi tecnica dettagliata del paper "Pitfalls in VM Implementation on CHERI: Lessons from Porting CRuby", presentata in italiano.

Titolo: Insidie nell'implementazione di VM su CHERI: Lezioni dal porting di CRuby

1. Il Problema

La sicurezza del software, in particolare la sicurezza della memoria, è una sfida critica. CHERI (Capability Hardware Enhanced RISC Instructions) è un'architettura hardware innovativa che risolve i problemi di sicurezza della memoria sostituendo i puntatori tradizionali con capability (token di autorità non falsificabili e con limiti di accesso).

Tuttavia, migrare le Virtual Machine (VM) dei linguaggi di programmazione su CHERI non è banale. Le VM sono sistemi complessi scritti spesso in C che fanno affidamento su comportamenti non definiti (undefined behavior) del linguaggio C o su assunzioni specifiche delle architetture tradizionali (es. x86, ARM). Queste assunzioni entrano in conflitto con il modello di sicurezza rigoroso di CHERI, causando fallimenti imprevisti.
Mentre esistono guide generali per la programmazione su CHERI, manca una guida specifica per le problematiche intrinseche all'implementazione delle VM. Il paper si pone l'obiettivo di identificare, categorizzare e risolvere queste insidie specifiche.

2. Metodologia

Gli autori hanno adottato un approccio basato su un caso di studio empirico e un'analisi comparativa:

• Caso di Studio: Porting di CRuby (l'implementazione di riferimento del linguaggio Ruby, scritta interamente in C) su architettura CHERI (modalità purecap).
  • Hanno modificato il runtime e l'interprete, escludendo il compilatore JIT e l'interfaccia FFI (Foreign Function Interface).
  • Il porting ha coinvolto la modifica di circa 464 righe di codice su 40 file (circa lo 0,077% del codice totale).
• Analisi Comparativa: Hanno esaminato tre precedenti casi di studio di porting su CHERI: MicroPython, JavaScriptCore e il porting del compilatore Rust.
• Categorizzazione: Hanno classificato i problemi riscontrati in base alle loro cause radice, distinguendo tra errori specifici delle VM e problemi generali.
• Valutazione delle Prestazioni: Hanno confrontato le prestazioni della VM portata su CHERI (eseguita su CPU x86 per simulazione/benchmark) con la VM originale, utilizzando 894 micro-benchmark ufficiali di Ruby.

3. Contributi Chiave e Categorie di Insidie

Il paper identifica sei categorie principali di problemi ("pitfalls") che sorgono quando si implementano VM su CHERI, derivanti principalmente da comportamenti non definiti del C e da idiomi di programmazione specifici delle VM:

1. Puntatori Derivati Invalidi (Invalid Derived Pointer):

   • Problema: Le VM spesso derivano un puntatore da un altro creato per scopi diversi (es. prendere l'indirizzo di una variabile locale per scandire lo stack). Su CHERI, l'operatore & restituisce una capability con limiti (bounds) ristretti alla sola variabile. Derivare un puntatore per lo stack intero da questa capability causa un errore di "bounds fault".
   • Soluzione: Mantenere una "super-capability" con limiti ampi (es. l'intero stack) da cui derivare i puntatori temporanei.

2. Dereferenziazione di Puntatori Ambigui (Dereferencing Ambiguous Pointers):

   • Problema: I Garbage Collector (GC) conservativi trattano i valori sullo stack che sembrano puntatori come radici potenziali. Su CHERI, convertire un intero in un puntatore non imposta il tag di validità. Se il GC tenta di dereferenziare un intero che ha lo stesso pattern di bit di un indirizzo valido, si verifica un "tag fault".
   • Soluzione: Prima di dereferenziare, verificare esplicitamente il tag di validità della capability. Questo permette anche di evitare di marcare oggetti morti che sono solo "interi puntatore-simili", migliorando potenzialmente le prestazioni.

3. Riallocazione in-Place (In-Place Reallocation):

   • Problema: Molti allocatori personalizzati delle VM assumono che realloc possa restituire lo stesso puntatore con nuovi limiti se la riallocazione avviene in-place. Su CHERI, realloc può restituire una nuova capability con limiti diversi, rendendo invalido l'uso del vecchio puntatore per accedere alla nuova area espansa.
   • Soluzione: Evitare di dipendere dalla riallocazione in-place. Aggiornare sempre tutti i puntatori che fanno riferimento all'area riallocata con il nuovo puntatore restituito.

4. Uso dei Bit di Padding dei Tipi Interi (Using Padding Bits of Integer Types):

   • Problema: Le VM usano spesso interi per impacchettare dati (bitmap, flag) assumendo che tutti i bit siano utilizzabili. Su CHERI, i tipi (u)intptr_t sono implementati come capability: i bit superiori (64 bit su 128) contengono metadati (limiti, permessi) e non sono utilizzabili per dati interi. Operazioni come shift o mascheratura su questi bit producono risultati indefiniti o errati.
   • Soluzione: Utilizzare tipi interi a larghezza esatta (es. uint64_t) per le operazioni bitwise e le bitmap, evitando (u)intptr_t quando non si tratta di puntatori.

5. Modifica di Capability Temporanee Introdotte dal Compilatore:

   • Problema: Il compilatore CHERI può introdurre capability temporanee durante operazioni binarie su (u)intptr_t. Se l'operando è una capability sigillata (es. indirizzi di ritorno), tentare di modificarla (anche solo per calcolare un offset) causa un "sealed fault".
   • Soluzione: Castare gli operandi (u)intptr_t a tipi non-capability (es. uint64_t) prima di eseguire operazioni aritmetiche o bitwise che non devono produrre un puntatore valido.

6. Aritmetica dei Puntatori su Tipi Non-Capability:

   • Problema: L'uso di tipi come size_t per l'aritmetica dei puntatori (es. downcasting tramite offsetof) è comune. Su CHERI, convertire un puntatore in size_t e poi indietro non ripristina la capability valida se il tipo intermedio non è (u)intptr_t.
   • Soluzione: Utilizzare esclusivamente (u)intptr_t per l'aritmetica dei puntatori.

4. Risultati

• Successo del Porting: La versione portata di CRuby su CHERI passa 29.609 su 34.046 test case. I fallimenti residui sono attribuiti principalmente alla mancanza di librerie esterne (libyaml) o a un singolo test che crasha l'harness, non a difetti fondamentali del porting.
• Prestazioni: L'analisi delle prestazioni mostra che la VM portata su CHERI raggiunge in media il 98,2% della throughput della VM originale su x86 (deviazione standard 0,038).
  • La maggior parte dei benchmark mostra un rapporto vicino a 1.
  • Alcuni outlier (operazioni su fiber) mostrano un calo significativo (fino a 10x), dovuto all'uso di un'implementazione generica in C invece di assembly ottimizzato per x86, non a un difetto intrinseco di CHERI.
• Impatto delle Soluzioni: Le soluzioni proposte (workaround) non introducono un sovraccarico significativo e, in alcuni casi (come il controllo del tag di validità nel GC), possono migliorare l'efficienza permettendo un garbage collection più preciso senza bisogno di "pinning" degli oggetti.

5. Significato e Impatto

Questo lavoro è fondamentale per l'adozione di CHERI nell'ecosistema dei linguaggi di programmazione:

• Guida Pratica: Fornisce una mappa dettagliata delle trappole specifiche per le VM, colmando il divario tra la documentazione generale di CHERI e le esigenze reali dei runtime complessi.
• Sicurezza Migliorata: Dimostra che è possibile costruire VM sicure su CHERI, sfruttando i vantaggi hardware per prevenire vulnerabilità di memoria che affliggono le VM tradizionali.
• Riduzione del Rischio: Identificando che la maggior parte dei problemi deriva da comportamenti non definiti del C, il paper incoraggia gli sviluppatori a scrivere codice più portabile e conforme agli standard, riducendo la superficie di attacco.
• Fondamento Futuro: Il lavoro getta le basi per futuri miglioramenti, come l'applicazione di limiti stretti (tight bounds) su ogni oggetto heap all'interno della VM, un passo successivo per massimizzare la sicurezza offerta da CHERI.

In sintesi, il paper dimostra che, nonostante le sfide iniziali legate alle assunzioni di progettazione delle VM, l'implementazione di runtime sicuri su CHERI è fattibile e le soluzioni individuate sono efficaci con un impatto minimo sulle prestazioni.