Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)

Questo lavoro presenta un'architettura di capacità innovativa e un'implementazione FPGA che, disaggregando il sistema operativo Zephyr in componenti isolati, garantisce la sicurezza dei dispositivi embedded senza richiedere modifiche hardware alle periferiche e rendendo tutti i componenti software a runtime non attendibili.

L'essenziale

Immagina il tuo dispositivo embedded (come un router Wi-Fi, un termostato intelligente o un sistema di controllo industriale) come una casa molto complessa.

In una casa tradizionale (i sistemi operativi attuali), c'è un padrone di casa (il kernel del sistema operativo) che ha le chiavi di tutte le stanze. Se il padrone di casa è onesto, la casa è sicura. Ma se un ladro (un bug software o un hacker) riesce a corrompere il padrone di casa, allora il ladro ha le chiavi di tutto: può rubare i tuoi dati, distruggere i mobili o bloccare le porte. Inoltre, spesso la casa ha delle finestre aperte verso l'esterno (i dispositivi periferici come schede di rete o controller DMA) che, se non sorvegliate, permettono a chiunque di entrare e fare danni.

Questo articolo presenta una soluzione rivoluzionaria chiamata Skadi (il sistema operativo) e Bredi (l'hardware su cui gira), basata su un concetto chiamato Northcape.

Ecco come funziona, spiegato con metafore semplici:

1. La Fine del "Padrone di Casa" Onnipotente

Invece di avere un unico padrone di casa che controlla tutto, Skadi divide la casa in centinaia di stanze separate, ognuna con la sua porta blindata.

• Nessun TCB (Trusted Computing Base) in esecuzione: In parole povere, non c'è più un "super-utente" che gira per la casa mentre lavori. Il vero "padrone" (il caricatore iniziale) apre le porte, distribuisce le chiavi alle stanze e poi scompare per sempre. Una volta che la casa è aperta, non c'è nessuno che possa riaprire le porte dall'interno se non chi ha ricevuto la chiave specifica.

2. Le Chiavi Magiche (Le "Capability")

Invece di usare chiavi fisiche che aprono intere stanze, il sistema usa biglietti d'accesso magici (chiamati capability tokens).

• Analogo: Immagina di avere un biglietto per il cinema. Quel biglietto non ti permette di entrare in qualsiasi cinema, né di sederti su qualsiasi poltrona. Ti permette di entrare solo in quel cinema, solo in quella sala, e solo su quel posto specifico.
• Se un ladro ruba il tuo biglietto, non può usare quello per entrare nella banca o nel tuo armadio. Può usare quel biglietto solo per il cinema.
• Inoltre, questi biglietti sono impossibili da falsificare. Sono come biglietti con un codice a barre che cambia ogni secondo e che il sistema di sicurezza legge direttamente dal muro, non dal tuo portafoglio. Se provi a inventare un codice, il sistema ti blocca immediatamente.

3. I Dispositivi Esterni (I "Ladri Potenziali")

Spesso, i dispositivi esterni (come una scheda di rete o una stampante) sono visti come "amici" che possono accedere alla memoria. Ma se questi dispositivi vengono compromessi (diventano dei "cavalli di Troia"), possono leggere tutto.

• La soluzione di Bredi: In questo nuovo sistema, anche i dispositivi esterni devono mostrare il loro biglietto d'accesso. Se una scheda di rete vuole scrivere dati nella memoria, deve mostrare un biglietto valido per quella specifica area di memoria. Se prova a toccare un'altra stanza, il sistema hardware (il guardiano del muro) la blocca istantaneamente, anche se il dispositivo è "pazzo" o corrotto. Non serve che il software sia sveglio per controllare; è il muro stesso a controllare i biglietti.

4. La Sicurezza in Tempo Reale (Il "Sistema di Allarme")

Uno dei problemi dei sistemi sicuri è che diventano lenti. Se controlli ogni singola mossa, la casa diventa un labirinto.

• Il trucco di Skadi: Il sistema è progettato per essere veloce. Usa delle "scorciatoie" (come le cache) per controllare i biglietti in un batter d'occhio. Inoltre, se un programma (una stanza) inizia a comportarsi male e blocca tutto (un "loop infinito"), il sistema ha un allarme non disattivabile (interrupt non mascherabili). È come avere un vigile del fuoco che può entrare in casa e spegnere il fuoco anche se il proprietario ha bloccato tutte le porte. Questo garantisce che il sistema rimanga sempre disponibile, anche sotto attacco.

5. Come si Comunicano le Stanze (Le "Chiamate di Sottosistema")

Se la stanza della "Cucina" ha bisogno di un ingrediente dalla stanza del "Dispensa", non possono semplicemente entrare. Devono passare un biglietto d'accesso attraverso un passaggio sicuro.

• Questo passaggio è chiamato subsystem call. È come un tubo pneumatico sicuro: la Cucina passa un biglietto che dice "Prendi un uovo dal Dispensa". Il Dispensa controlla il biglietto, prende l'uovo e lo passa indietro. La Cucina non può mai vedere cosa c'è nel resto del Dispensa, e il Dispensa non può mai vedere cosa c'è nella Cucina.

In Sintesi: Perché è Importante?

Attualmente, se un hacker trova un buco in un'app, nel sistema operativo o in un dispositivo, spesso prende il controllo totale del dispositivo.
Con Skadi e Bredi:

1. Non c'è un "Re" da uccidere: Non c'è un software privilegiato in esecuzione che, se compromesso, distrugge tutto.
2. Isolamento Totale: Ogni componente è una stanza blindata. Se un componente viene hackerato, l'attacco si ferma lì. Non può saltare alle altre stanze.
3. Hardware come Guardiano: La sicurezza non dipende solo dal software (che può avere bug), ma è costruita nel "muro" stesso (l'hardware).

L'analogia finale:
Immagina un vecchio castello con un unico re (il kernel). Se il re viene avvelenato, il castello cade.
Skadi e Bredi trasformano il castello in una fortezza di cellule di prigione. Ogni cella è isolata. Non c'è un re che gira per il corridoio. C'è solo un meccanismo automatico che controlla i biglietti d'ingresso. Se un prigioniero (un componente software) diventa pazzo o viene corrotto, rimane intrappolato nella sua cella e non può toccare gli altri. E se la cella stessa viene attaccata dall'esterno (dispositivi DMA), le pareti sono fatte di un materiale che rifiuta qualsiasi biglietto non valido.

È un approccio "Non fidarti di nulla" (Trust Nothing), dove la sicurezza è garantita dalla struttura stessa della casa, non dalla bontà dei suoi abitanti.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper "Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)", presentato da Eric Ackermann e Sven Bugiel del CISPA Helmholtz Center for Information Security.

1. Il Problema

I dispositivi embedded moderni affrontano un panorama delle minacce in continua espansione. Le vulnerabilità possono risiedere in tre vettori principali:

1. Software applicativo: Bug nel codice dell'applicazione.
2. Kernel del sistema operativo: Vulnerabilità nel kernel (es. Zephyr, Linux).
3. Dispositivi periferici: Attacchi tramite DMA (Direct Memory Access) da periferiche compromesse o malevole.

Le difese architetturali esistenti riescono a proteggere al massimo due di questi vettori simultaneamente. Ad esempio, i sistemi basati su MMU (Memory Management Unit) proteggono le applicazioni dai dispositivi, ma richiedono di fidarsi del kernel per configurare l'MMU correttamente, lasciando il kernel come parte del Trusted Computing Base (TCB) a runtime. Allo stesso modo, le architetture a capacità (capability-based) moderne spesso escludono i dispositivi dal modello di minaccia, richiedendo driver fidati o modifiche hardware alle periferiche. Non esiste attualmente un'architettura che garantisca sicurezza contro software non fidato, kernel non fidati e dispositivi non fidati simultaneamente, mantenendo al contempo garanzie di soft real-time.

2. Metodologia

Gli autori propongono una soluzione basata su un co-design hardware-software che combina due componenti principali:

• Bredi (SoC): Una nuova implementazione hardware dell'architettura a capacità "Northcape".
• Skadi (RTOS): Un sistema operativo real-time basato su Zephyr, riprogettato per sfruttare Bredi.

L'approccio fondamentale è l'uso di un'architettura a capacità basata su token implementata a livello di bus di sistema (tramite un "Northbridge" abilitato alle capacità), piuttosto che solo all'interno della CPU. Questo permette di controllare l'accesso alla memoria sia per le CPU che per le periferiche DMA senza richiedere modifiche hardware alle periferiche stesse.

Componenti Chiave:

• Northcape (Architettura): Utilizza token di capacità che separano l'offset, un identificatore (numero) e un nonce casuale. Questi token vengono risolti in indirizzi fisici dal Northbridge, che verifica i metadati in una Capability Metadata Table (CMT).
• Bredi (Hardware): Un SoC basato su FPGA che integra una CPU RISC-V (cva6), un MMU per le periferiche DMA (AXI MMU), un risolutore di capacità e un modulo di operazioni. Include meccanismi per la gestione delle interruzioni non fidate e la preemption.
• Skadi (Software): Un RTOS che scompone il kernel tradizionale in piccoli sottosistemi mutualmente isolati. Non esiste un kernel privilegiato a runtime; tutte le funzioni (scheduler, allocator, driver) sono sottosistemi non fidati che comunicano tramite chiamate di sottosistema (subsystem calls).

3. Contributi Chiave

A. Implementazione Hardware (Bredi)

• Prima implementazione fisica di Northcape: Realizzata su FPGA attorno alla CPU cva6 RISC-V.
• Gestione delle Interruzioni Non Fidate: Risolve il problema storico delle ISR (Interrupt Service Routines) che devono accedere ai registri. Bredi implementa un registro stacking (due set di registri: uno per il regime di interruzione e uno normale) e un vettorializzazione delle interruzioni che garantisce l'isolamento dell'ID del sottosistema.
• Preemption e Disponibilità: Utilizza interruzioni non mascherabili (NMI) e timer stub per garantire che i servizi critici siano eseguiti anche in presenza di attaccanti che tentano di disabilitare le interruzioni.
• Gerarchia di Cache: Implementa due livelli di TLB per capacità (NTLB L1 e L2) per nascondere l'overhead della risoluzione ricorsiva delle capacità, mantenendo le prestazioni elevate.

B. Implementazione Software (Skadi)

• Nessun TCB Software a Runtime: Il loader Skadi è l'unica componente fidata. Dopo l'avvio, il loader si autodistrugge (tramite un sottosistema "trapdoor"), eliminando completamente il TCB software a runtime.
• Isolamento Completo: Tutti i componenti (scheduler, allocator, driver DMA, stack di rete) sono isolati in sottosistemi separati. I driver DMA non hanno accesso diretto alla memoria; devono ricevere capacità delegate tramite chiamate di sottosistema.
• Chiamate di Sottosistema (Subsystem Calls): Un meccanismo atomico che cambia sia il flusso di controllo che l'ID del sottosistema attivo, garantendo che il chiamante non possa accedere ai dati del chiamato e viceversa, senza intermediari fidati.
• Compatibilità con Zephyr: Skadi mantiene la compatibilità con il modello di build e le API di Zephyr, permettendo il riutilizzo di componenti esistenti, sebbene richieda una ricompilazione per l'uso di macro generative per i trampolini di chiamata.

C. Miglioramenti alla Sicurezza

• Protezione contro Guessing: Introduzione di restrizioni basate sull'ID del sottosistema (subsystem-ID bound) per prevenire attacchi di indovinamento dei nonce delle capacità.
• Accesso Esclusivo: Meccanismi di lock per garantire l'accesso esclusivo a risorse condivise, prevenendo attacchi Time-of-Check to Time-of-Use (TOCTOU).

4. Risultati Sperimentali

Gli autori hanno valutato il prototipo su una scheda FPGA Digilent Genesys 2.

• Sicurezza: Il sistema garantisce confidenzialità (C), integrità (I) e disponibilità (A) anche con kernel, applicazioni e periferiche non fidate. Non esiste un TCB software a runtime.
• Prestazioni di Calcolo: In benchmark di calcolo puro (Coremark, Stream), Skadi su Bredi ha prestazioni quasi identiche a Zephyr su Bredi e comparabili a Linux, grazie all'alta hit-rate della cache L1 delle capacità.
• Prestazioni di I/O e Rete:
  • Si osserva un overhead significativo nelle operazioni di I/O e nella rete (es. Ping, TCP throughput) a causa dell'elevato numero di chiamate di sottosistema necessarie per l'isolamento fine-granulare.
  • Tuttavia, i valori assoluti rimangono pratici per la maggior parte delle applicazioni embedded. Ad esempio, la latenza di rete è circa 3-4 volte superiore a Zephyr, ma ancora nell'ordine dei millisecondi.
• Tempo Reale: Skadi soddisfa i requisiti di soft real-time. La latenza di risposta alle interruzioni è nell'ordine di decine di microsecondi, con una deviazione standard gestibile.
• Overhead di Area: L'implementazione su FPGA ha un overhead di area ragionevole (circa il 31% in più rispetto alla CPU cva6 originale), principalmente dovuto alla L2 TLB e al risolutore di capacità.

5. Significato e Impatto

Questo lavoro rappresenta un passo fondamentale verso la sicurezza "by-design" nei dispositivi embedded critici.

• Riduzione del TCB: Elimina la necessità di fidarsi del kernel a runtime, un problema irrisolto da decenni nelle architetture tradizionali.
• Protezione Olistica: È la prima soluzione che protegge simultaneamente da vulnerabilità software, kernel e dispositivi hardware (DMA) senza richiedere modifiche alle periferiche.
• Fondamento per il Futuro: Offre una base solida per dispositivi di infrastruttura di rete ad alta sicurezza (es. stazioni base 5G, router industriali) dove la compromissione di un singolo componente non deve portare al collasso dell'intero sistema.
• Scalabilità: Dimostra che l'approccio basato su capacità è fattibile su hardware reale (FPGA) e può essere integrato in ecosistemi software esistenti come Zephyr.

In sintesi, "Trust Nothing" dimostra che è possibile costruire sistemi embedded sicuri, isolati e in tempo reale senza dover affidare la sicurezza a un kernel privilegiato, spostando la fiducia esclusivamente sull'hardware e su un loader di avvio effimero.