Microsoft ha annunciato l'apertura del codice sorgente del layer per la para-virtualizzazione OpenHCL e del monitor delle macchine virtuali OpenVMM, sviluppato specificamente per facilitare il funzionamento di OpenHCL. Il codice di OpenVMM e OpenHCL è scritto in Rust e viene distribuito sotto licenza MIT. OpenVMM è un hypervisor di secondo livello che opera nello stesso ring di protezione del kernel del sistema operativo, similmente a prodotti come VirtualBox e VMware Workstation. Supporta l'operatività su sistemi host basati su Linux (x86_64), Windows (x86_64, Aarch64) e macOS (x86_64, Aarch64), utilizzando le API di virtualizzazione KVM, SHV (Microsoft Hypervisor), WHP (Windows Hypervisor Platform) e Hypervisor.framework fornite da questi OS.
Tra le funzionalità supportate in OpenVMM:
- Avvio in modalità UEFI e BIOS, avvio diretto del kernel Linux;
- Supporto per para-virtualizzazione basata su driver Virtio (virtio-fs, virtio-9p, virtio-net, virtio-pmem);
- Supporto per para-virtualizzazione basata su VMBus (storvsp, netvsp, vpci, framebuffer);
- Emulazione di vTPM, NVMe, UART, chipset i440BX + PIIX4, IDE HDD, PCI e VGA;
- Backend per il pass-through di grafica, dispositivi di input, console, storage e accesso di rete;
- Gestione tramite interfaccia a linea di comando, console interattiva, gRPC e ttrpc.
OpenHCL è posizionato come un ambiente con componenti di paravirtualizzazione (hypervisor), che opera sopra l'hypervisor OpenVMM. Una caratteristica chiave dei sistemi di virtualizzazione basati su OpenVMM e OpenHCL è che i componenti per la paravirtualizzazione vengono eseguiti non sul lato del sistema host, ma all'interno di una macchina virtuale insieme al sistema guest. L'isolamento dello strato di paravirtualizzazione dal sistema operativo guest è garantito dalle funzionalità dell'hypervisor di secondo livello OpenVMM. In questa applicazione, OpenHCL può essere considerato come un firmware virtuale che opera a un livello di privilegi superiore rispetto al sistema operativo in esecuzione nell'ambiente guest.
La separazione del sistema guest e dei componenti OpenHCL avviene utilizzando il concetto di livelli di fiducia virtuali (VTL, Virtual Trust Level), per l'implementazione dei quali possono essere utilizzati sia meccanismi software che tecnologie hardware, come Intel TDX (Trust Domain Extensions), AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) e ARM CCA (Confidential Compute Architecture). Per l'esecuzione dei componenti OpenHCL viene utilizzata una build ridotta del kernel Linux, contenente solo i componenti minimi necessari per il funzionamento di OpenVMM.
OpenHCL può funzionare su piattaforme x86-64 e ARM64 e supporta le estensioni Intel TDX, AMD SEV-SNP e ARM CCA per un'ulteriore isolamento. Il pacchetto OpenHCL include un insieme di servizi, driver ed emulatori utilizzati per organizzare l'accesso all'hardware, garantire il funzionamento dei dispositivi virtuali dal lato del sistema guest e emulare dispositivi hardware (ad esempio, può essere emulato un chip per la memorizzazione delle chiavi crittografiche — vTPM).
Per la trasmissione dell'accesso all'hardware del sistema ospite, vengono utilizzati driver esistenti con supporto per la paravirtualizzazione o può essere effettuato un collegamento diretto dei dispositivi alla macchina virtuale, consentendo il trasferimento di sistemi operativi esistenti in un ambiente basato su OpenHCL senza modifiche. Inoltre, OpenHCL include componenti per la diagnostica e il debug. di macchine virtuali, eseguiti utilizzando estensioni per garantire calcoli riservati.
A differenza del progetto open source esistente COCONUT-SVSM (Secure VM Service Module), che fornisce servizi e dispositivi emulati per sistemi ospiti operanti in modalità riservata, macchine virtuali (CVM, Confidential Virtual Machine), OpenHCL permette l'uso di interfacce standard nei sistemi ospiti, mentre COCONUT-SVSM richiede l'organizzazione di interazioni speciali con SVSM, modifiche nel sistema ospite e l'uso di driver separati.
Tra le applicazioni del paraviso OpenHCL si segnalano scenari come la migrazione di sistemi esistenti all'utilizzo di acceleratori hardware Azure Boost senza la necessità di modificare l'immagine disco del sistema operativo guest; l'esecuzione di sistemi guest esistenti in macchine virtuali che garantiscono calcoli riservati (ad esempio, basate su Intel TDX e AMD SEV-SNP); l'organizzazione di un avvio verificato delle macchine virtuali, utilizzando la modalità UEFI Secure Boot e vTPM.
È importante notare che il progetto OpenVMM è focalizzato sull'uso di OpenHCL e attualmente non è pronto per una applicazione autonoma nei sistemi host per implementazioni da parte degli utenti finali. Tra i problemi di OpenVMM che ostacolano il suo utilizzo in ambienti host nel contesto tradizionale, al di fuori dell'integrazione con OpenHCL, si segnalano: documentazione scarsa dell'interfaccia di gestione; assenza di ottimizzazione adeguata delle prestazioni dei backend per archiviazione, rete e grafica; mancanza di supporto per alcuni driver (ad esempio, dischi IDE e mouse PS/2); nessuna garanzia di stabilità dell'API e della funzionalità. Tuttavia, l'integrazione di OpenVMM con OpenHCL ha già raggiunto un livello di implementazione industriale ed è utilizzata da Microsoft nella piattaforma Azure (Azure Boost SKU) per garantire il funzionamento di oltre 1,5 milioni di macchine virtuali.
Fonte: opennet.ru
