Microsoft ha annunciato l'open source del layer per la paravirtualizzazione di OpenHCL e del monitor della macchina virtuale OpenVMM, sviluppato appositamente per organizzare il lavoro di OpenHCL. Il codice OpenVMM e OpenHCL è scritto in Rust ed è distribuito sotto la licenza MIT. OpenVMM si riferisce a hypervisor di secondo livello che funzionano nello stesso anello di sicurezza con il kernel del sistema operativo, in modo simile a prodotti come VirtualBox e VMware Workstation. Supporta il funzionamento 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 fornite dal quadro dei dati del sistema operativo.
Tra le funzionalità supportate in OpenVMM:
- Avvio in modalità UEFI e BIOS, avvio diretto del kernel Linux;
- Supporto per la paravirtualizzazione basato su driver Virtio (virtio-fs, virtio-9p, virtio-net, virtio-pmem)
- Supporto paravirtualizzazione basato su VMBus (storvsp, netvsp, vpci, framebuffer);
- Emulazione di vTPM, NVMe, UART, chipset i440BX + PIIX4, IDE HDD, PCI e VGA;
- Backend per l'inoltro di grafica, dispositivi di input, console, archiviazione e accesso alla rete;
- Gestione tramite interfaccia a riga di comando, console interattiva, gRPC e ttrpc.
OpenHCL è posizionato come un ambiente con componenti di paravirtualizzazione (paravisor) in esecuzione sull'hypervisor OpenVMM. Una caratteristica fondamentale dei sistemi di virtualizzazione basati su OpenVMM e OpenHCL è che i componenti di paravirtualizzazione non vengono eseguiti sul lato del sistema host, ma nella stessa macchina virtuale con il sistema ospite. L'isolamento dello strato di paravirtualizzazione dal sistema operativo guest è assicurato dall'hypervisor di secondo livello OpenVMM. Se utilizzato in questo modo, OpenHCL può essere considerato come un firmware virtuale in esecuzione con un livello di privilegi più elevato rispetto al sistema operativo in esecuzione nell'ambiente guest.
La separazione del sistema ospite e dei componenti OpenHCL viene effettuata utilizzando il concetto di livelli di fiducia virtuale (VTL, Virtual Trust Level), per la cui implementazione 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 eseguire i componenti OpenHCL, viene utilizzata una build ridotta del kernel Linux, che include solo i componenti minimi necessari per eseguire OpenVMM.
OpenHCL può essere eseguito su piattaforme x86-64 e ARM64 e supporta le estensioni Intel TDX, AMD SEV-SNP e ARM CCA per un ulteriore isolamento. OpenHCL include una serie di servizi, driver ed emulatori utilizzati per organizzare l'accesso alle apparecchiature, garantire il funzionamento dei dispositivi virtuali sul lato del sistema ospite ed emulare dispositivi hardware (ad esempio, un chip per la memorizzazione di chiavi crittografiche - vTPM).
Per tradurre l'accesso all'hardware sul lato del sistema guest, vengono utilizzati driver esistenti abilitati alla paravirtualizzazione, oppure i dispositivi possono essere associati direttamente alla macchina virtuale, consentendo la migrazione dei sistemi guest esistenti a un ambiente basato su OpenHCL senza modifiche. OpenHCL include anche componenti di diagnostica e debug. macchine virtuali, eseguito utilizzando estensioni per garantire la riservatezza del calcolo.
A differenza del progetto open source esistente COCONUT-SVSM (Secure VM Service Module), che fornisce servizi e dispositivi emulati per sistemi guest in esecuzione in ambienti riservati macchine virtuali (CVM, Confidential Virtual Machine), OpenHCL consente l'uso di interfacce standard nei sistemi guest, mentre COCONUT-SVSM richiede l'organizzazione di un'interazione speciale con SVSM, apportando modifiche al sistema guest e utilizzando driver separati.
Tra le applicazioni del paravisor OpenHCL vengono menzionati scenari come la transizione dei sistemi esistenti all'utilizzo degli acceleratori hardware Azure Boost senza la necessità di apportare modifiche all'immagine del disco del sistema guest; Eseguire guest esistenti in macchine virtuali che forniscono elaborazione riservata (ad esempio, basata su Intel TDX e AMD SEV-SNP); organizzazione dell'avvio verificato di macchine virtuali utilizzando UEFI Secure Boot e modalità vTPM.
Si noti separatamente che il progetto OpenVMM è focalizzato sull'uso con OpenHCL e non è ancora pronto per l'uso autonomo su sistemi host per implementazioni di produzione da parte degli utenti finali. Tra i problemi di OpenVMM che ne impediscono l'utilizzo in ambienti host in contesto tradizionale, al di fuori di OpenHCL, si citano i seguenti: scarsa documentazione dell'interfaccia di controllo; mancanza di un'adeguata ottimizzazione delle prestazioni di backend per archiviazione, rete e grafica; mancanza di supporto per alcuni driver (ad esempio unità IDE e mouse PS/2); non vi è alcuna garanzia di stabilità e funzionalità dell'API. Allo stesso tempo, la combinazione di OpenVMM e OpenHCL ha già raggiunto il livello di implementazione industriale e viene utilizzata da Microsoft nella piattaforma Azure (Azure Boost SKU) per supportare il funzionamento di oltre 1.5 milioni di macchine virtuali.
Fonte: opennet.ru
