Sicurezza

Per impedire l'esecuzione di payload arbitrari all'interno di una pVM, Android Virtualization Framework (AVF) utilizza un approccio di sicurezza a più livelli in cui ogni livello aggiunge ulteriori misure di applicazione. Di seguito è riportato un elenco dei livelli di sicurezza di AVF:

• Android garantisce che solo le app con autorizzazioni pVM siano autorizzate a creare o ispezionare le pVM.

• Bootloader: il bootloader garantisce che sia consentito l'avvio solo delle immagini pVM firmate da Google o dai fornitori di dispositivi e rispetta la procedura di Android Verified Boot. Questa architettura implica che le app che eseguono pVM non possono raggruppare i propri kernel.

• pVM fornisce una difesa in profondità, ad esempio con SELinux, per i payload eseguiti nella pVM. La difesa in profondità non consente di mappare i dati come eseguibili (neverallow execmem) e garantisce che W^X valga per tutti i tipi di file.

Modello di sicurezza

Riservatezza, integrità e disponibilità (triade CIA) costituiscono un modello progettato per guidare le norme di sicurezza delle informazioni:

• La riservatezza è un insieme di regole che limita l'accesso alle informazioni.
• Integrità è la garanzia che le informazioni siano attendibili e accurate.
• La disponibilità è una garanzia di accesso affidabile alle informazioni da parte di entità autorizzate.

Riservatezza e integrità

La riservatezza deriva dalle proprietà di isolamento della memoria applicate dall'hypervisor pKVM. pKVM tiene traccia della proprietà della memoria delle singole pagine di memoria fisica e di eventuali richieste di condivisione delle pagine da parte dei proprietari. pKVM garantisce che solo le pVM autorizzate (host e ospiti) abbiano la pagina specificata mappata nelle tabelle delle pagine di secondo livello controllate dall'hypervisor. Questa architettura prevede che i contenuti della memoria di proprietà di una pVM rimangano privati, a meno che il proprietario non li condivida esplicitamente con un'altra pVM.

Le limitazioni per il mantenimento della riservatezza si estendono anche a qualsiasi entità del sistema che esegue accessi alla memoria per conto delle VM protette, ovvero dispositivi compatibili con DMA e servizi in esecuzione in livelli più privilegiati. I fornitori di System-on-Chip (SoC) devono soddisfare un nuovo insieme di requisiti prima di poter supportare pKVM. In caso contrario, non è possibile garantire la riservatezza.

L'integrità si applica ai dati in memoria e al calcolo. Le pVM non possono:

• Modificare i ricordi degli altri senza il loro consenso.
• Influenzano lo stato della CPU l'uno dell'altro.

Questi requisiti vengono applicati dall'hypervisor. Tuttavia, i problemi relativi all'integrità dei dati si presentano anche con l'archiviazione virtuale dei dati quando devono essere applicate altre soluzioni, come dm-verity o AuthFS.

Questi principi non sono diversi dall'isolamento dei processi offerto da Linux, in cui l'accesso alle pagine di memoria è controllato con tabelle di pagine di primo livello e il kernel cambia contesto tra i processi. Tuttavia, la parte EL2 di pKVM, che applica queste proprietà, ha una superficie di attacco tre ordini di grandezza inferiore rispetto all'intero kernel Linux (circa 10.000 contro 20 milioni di righe di codice) e pertanto offre una maggiore garanzia per i casi d'uso troppo sensibili per fare affidamento sull'isolamento dei processi.

Data la sua dimensione, pKVM si presta alla verifica formale. Stiamo supportando attivamente la ricerca accademica, che mira a dimostrare formalmente queste proprietà sul binario pKVM effettivo.

Il resto di questa pagina tratta le garanzie di riservatezza e integrità fornite da ogni componente intorno a pKVM.

Hypervisor

pKVM è un hypervisor basato su KVM che isola le pVM e Android in ambienti di esecuzione reciprocamente non attendibili. Queste proprietà sono valide in caso di compromissione all'interno di qualsiasi pVM, incluso l'host. Gli hypervisor alternativi conformi ad AVF devono fornire proprietà simili.

• Una VM partizionata non può accedere a una pagina appartenente a un'altra entità, ad esempio una VM partizionata o un hypervisor, a meno che non sia condivisa esplicitamente dal proprietario della pagina. Questa regola include la pVM host e si applica sia agli accessi CPU che DMA.

• Prima che una pagina utilizzata da una pVM venga restituita all'host, ad esempio quando la pVM viene eliminata, viene cancellata.

• La memoria di tutte le pVM e il firmware pVM di un avvio del dispositivo vengono cancellati prima che il bootloader del sistema operativo venga eseguito nell'avvio successivo del dispositivo.

• Quando è collegato un debugger hardware, ad esempio SJTAG, una pVM non può accedere alle chiavi create in precedenza.

• Il firmware pVM non viene avviato se non è in grado di verificare l'immagine iniziale.

• Il firmware pVM non viene avviato se l'integrità di instance.img è compromessa.

• La catena di certificati DICE e gli identificatori di dispositivo compositi (CDI) forniti a un'istanza pVM possono essere derivati solo da quella particolare istanza.

Sistema operativo guest

Microdroid è un esempio di sistema operativo in esecuzione all'interno di una pVM. Microdroid è costituito da un bootloader basato su U-boot, GKI, un sottoinsieme di userspace Android e un launcher di payload. Queste proprietà sono valide in caso di compromissione all'interno di qualsiasi pVM, incluso l'host. I sistemi operativi alternativi in esecuzione in una pVM devono fornire proprietà simili.

• Microdroid non si avvierà se non è possibile verificare boot.img, super.img, vbmeta.img o vbmeta\_system.img.

• Microdroid non si avvierà se la verifica dell'APK non va a buon fine.

• La stessa istanza di Microdroid non verrà avviata anche se l'APK è stato aggiornato.

• Microdroid non verrà avviato se la verifica di uno degli APEX non va a buon fine.

• Microdroid non si avvia (o si avvia con uno stato iniziale pulito) se instance.img viene modificato al di fuori della pVM guest.

• Microdroid fornisce l'attestazione alla catena di avvio.

• Qualsiasi modifica (non firmata) alle immagini disco condivise con la pVM guest causa un errore I/O sul lato pVM.

• La catena di certificati DICE e i CDI forniti a un'istanza pVM possono essere derivati solo da quella particolare istanza.

• Le scritture in un volume di archiviazione criptato sono riservate, ma non esiste protezione dal rollback alla granularità di un blocco di crittografia. Inoltre, altre manomissioni esterne arbitrarie di un blocco di dati fanno sì che questo venga visualizzato come spazzatura da Microdroid, anziché essere rilevato esplicitamente come errore di I/O.

Android

Queste sono proprietà gestite da Android come host, ma non sono valide in caso di compromissione dell'host:

• Una pVM ospite non può interagire direttamente con altre pVM ospiti (ad esempio per stabilire una connessione vsock).

• Solo il VirtualizationService nella pVM host può creare un canale di comunicazione con una pVM.

• Solo le app firmate con la chiave della piattaforma possono richiedere l'autorizzazione per creare, possedere o interagire con le pVM.

• L'identificatore, chiamato identificatore di contesto (CID), utilizzato per configurare le connessioni vsock tra l'host e la pVM non viene riutilizzato quando la pVM host è in esecuzione. Ad esempio, non puoi sostituire una pVM in esecuzione con un'altra.

Disponibilità

Nel contesto delle pVM, la disponibilità si riferisce all'allocazione da parte dell'host di risorse sufficienti agli ospiti in modo che questi possano svolgere le attività per cui sono progettati.

Le responsabilità dell'host includono la pianificazione delle CPU virtuali della pVM. KVM, a differenza degli hypervisor di tipo 1 convenzionali (come Xen), prende la decisione di progettazione esplicita di delegare la pianificazione del workload al kernel host. Date le dimensioni e la complessità degli scheduler attuali, questa decisione di progettazione riduce significativamente le dimensioni della base di calcolo attendibile (TCB) e consente all'host di prendere decisioni di pianificazione più informate per ottimizzare le prestazioni. Tuttavia, un host malintenzionato può scegliere di non programmare mai un ospite.

Allo stesso modo, pKVM delega la gestione degli interrupt fisici al kernel host per ridurre la complessità dell'hypervisor e lasciare all'host l'incarico di pianificazione. Viene fatto il possibile per garantire che l'inoltro degli interrupt guest comporti solo un attacco Denial of Service (interrupt troppo pochi, troppi o instradati in modo errato).

Infine, il processo del monitor delle macchine virtuali (VMM) dell'host è responsabile dell'allocazione della memoria e della fornitura di dispositivi virtuali, come una scheda di rete. Una VMM dannosa può negare risorse al guest.

Sebbene pKVM non fornisca disponibilità agli ospiti, la progettazione protegge la disponibilità dell'host da ospiti dannosi perché l'host può sempre interrompere o terminare un ospite e recuperare le sue risorse.

Avvio protetto

I dati sono associati alle istanze di una pVM e l'avvio protetto garantisce che l'accesso ai dati di un'istanza possa essere controllato. Il primo avvio di un'istanza la esegue generando in modo casuale un sale segreto per la pVM ed estraendo dettagli, ad esempio hash e chiavi pubbliche di verifica, dalle immagini caricate. Queste informazioni vengono utilizzate per verificare gli avvii successivi dell'istanza pVM e garantire che i secret dell'istanza vengano rilasciati solo alle immagini che superano la verifica. Questo processo si verifica per ogni fase di caricamento all'interno della pVM: firmware pVM, pVM ABL, Microdroid e così via.

DICE fornisce a ogni fase di caricamento una coppia di chiavi di attestazione, la cui parte pubblica è certificata nel certificato DICE per quella fase. Questa coppia di chiavi può cambiare tra gli avvii, quindi viene derivato anche un secret di sigillatura stabile per l'istanza VM tra i riavvii e, in quanto tale, è adatto a proteggere lo stato permanente. Il secret di sigillatura è molto importante per la VM, pertanto non deve essere utilizzato direttamente. Le chiavi di sigillatura devono invece essere derivate dal secret di sigillatura e quest'ultimo deve essere eliminato il prima possibile.

Ogni fase passa un oggetto CBOR codificato in modo deterministico alla fase successiva. Questo oggetto contiene i secret e la catena di certificati DICE, che contiene informazioni sullo stato accumulate, ad esempio se l'ultima fase è stata caricata in modo sicuro.

Dispositivi sbloccati

Quando un dispositivo viene sbloccato con fastboot oem unlock, i dati utente vengono cancellati. Questa procedura protegge i dati degli utenti da accessi non autorizzati. Anche i dati privati di una VM protetta vengono invalidati quando si verifica lo sblocco del dispositivo.

Una volta sbloccate, il proprietario del dispositivo è libero di eseguire il reflashing delle partizioni solitamente protette dall'avvio verificato, incluse le partizioni che contengono pvmfw e l'implementazione di pKVM. Pertanto, un dispositivo sbloccato non è considerato attendibile per rispettare il modello di sicurezza di una pVM.

Le parti remote possono osservare questo stato potenzialmente non sicuro ispezionando lo stato di avvio verificato del dispositivo in un certificato di attestazione di chiavi.