Dopo otto mesi di sviluppo è stato rilasciato l'hypervisor gratuito Xen 4.16. Allo sviluppo della nuova versione hanno preso parte aziende come Amazon, Arm, Bitdefender, Citrix ed EPAM Systems. Il rilascio degli aggiornamenti per il ramo Xen 4.16 durerà fino al 2 giugno 2023 e la pubblicazione delle correzioni delle vulnerabilità fino al 2 dicembre 2024.
Modifiche principali in Xen 4.16:
- Il TPM Manager, che garantisce il funzionamento dei chip virtuali per la memorizzazione delle chiavi crittografiche (vTPM), implementato sulla base di un comune TPM fisico (Trusted Platform Module), è stato corretto per implementare successivamente il supporto alla specifica TPM 2.0.
- Maggiore dipendenza dal layer PV Shim utilizzato per eseguire guest paravirtualizzati (PV) non modificati in ambienti PVH e HVM. In futuro, l'uso di guest paravirtualizzati a 32 bit sarà possibile solo in modalità PV Shim, il che ridurrà il numero di posti nell'hypervisor che potrebbero potenzialmente contenere vulnerabilità.
- Aggiunta la possibilità di eseguire l'avvio su dispositivi Intel senza timer programmabile (PIT, Programmable Interval Timer).
- Ripuliti i componenti obsoleti, interrotta la creazione del codice predefinito "qemu-xen-traditional" e PV-Grub (la necessità di questi fork specifici di Xen è scomparsa dopo che le modifiche con il supporto Xen sono state trasferite alla struttura principale di QEMU e Grub).
- Per i guest con architettura ARM è stato implementato il supporto iniziale per i contatori di monitoraggio delle prestazioni virtualizzati.
- Supporto migliorato per la modalità dom0less, che consente di evitare la distribuzione dell'ambiente dom0 quando si avviano le macchine virtuali in una fase iniziale dell'avvio del server. Le modifiche apportate hanno consentito di implementare il supporto per i sistemi ARM a 64 bit con firmware EFI.
- Supporto migliorato per sistemi ARM eterogenei a 64 bit basati sull'architettura big.LITTLE, che combinano core potenti ma assetati di energia e core a prestazioni inferiori ma più efficienti dal punto di vista energetico in un unico chip.
Allo stesso tempo, Intel ha pubblicato il rilascio dell'hypervisor Cloud Hypervisor 20.0, costruito sulla base di componenti del progetto congiunto Rust-VMM, al quale partecipano, oltre a Intel, anche Alibaba, Amazon, Google e Red Hat. Rust-VMM è scritto nel linguaggio Rust e consente di creare hypervisor specifici per attività. Cloud Hypervisor è uno di questi hypervisor che fornisce un monitor di macchina virtuale (VMM) di alto livello in esecuzione su KVM e ottimizzato per attività native del cloud. Il codice del progetto è disponibile con la licenza Apache 2.0.
Cloud Hypervisor si concentra sull'esecuzione di moderne distribuzioni Linux utilizzando dispositivi paravirtualizzati basati su virtio. Tra gli obiettivi chiave citati ci sono: alta reattività, basso consumo di memoria, alte prestazioni, configurazione semplificata e riduzione dei possibili vettori di attacco. Il supporto dell'emulazione è ridotto al minimo e l'attenzione è rivolta alla paravirtualizzazione. Attualmente sono supportati solo i sistemi x86_64, ma è previsto il supporto AArch64. Per i sistemi guest, attualmente sono supportate solo le build Linux a 64 bit. La CPU, la memoria, il PCI e gli NVDIMM vengono configurati in fase di assemblaggio. È possibile migrare macchine virtuali tra server.
Nella nuova versione:
- Per le architetture x86_64 e aarch64, ora sono consentiti fino a 16 segmenti PCI, il che aumenta il numero totale di dispositivi PCI consentiti da 31 a 496.
- È stato implementato il supporto per il collegamento delle CPU virtuali ai core fisici della CPU (blocco CPU). Per ogni vCPU, è ora possibile definire un set limitato di CPU host su cui è consentita l'esecuzione, il che può essere utile quando si esegue la mappatura diretta (1:1) delle risorse host e guest o quando si esegue una macchina virtuale su uno specifico nodo NUMA.
- Supporto migliorato per la virtualizzazione I/O. Ogni regione VFIO può ora essere mappata in memoria, riducendo così il numero di uscite della macchina virtuale e migliorando le prestazioni di inoltro del dispositivo alla macchina virtuale.
- Nel codice Rust è stato fatto del lavoro per sostituire le sezioni non sicure con implementazioni alternative eseguite in modalità sicura. Per le restanti sezioni non sicure sono stati aggiunti commenti dettagliati che spiegano perché il restante codice non sicuro può essere considerato sicuro.
Fonte: opennet.ru