Dopo un anno di sviluppo è stato rilasciato l'hypervisor gratuito Xen 4.17. Allo sviluppo della nuova versione hanno preso parte aziende come Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD). La generazione degli aggiornamenti per il ramo Xen 4.17 durerà fino al 12 giugno 2024 e la pubblicazione delle correzioni delle vulnerabilità fino al 12 dicembre 2025.
Modifiche principali in Xen 4.17:
- Viene fornita una parziale conformità ai requisiti per lo sviluppo di programmi sicuri e affidabili in linguaggio C, formulati nelle specifiche MISRA-C utilizzate nella creazione di sistemi mission-critical. Xen implementa ufficialmente 4 direttive e 24 regole MISRA-C (su 143 regole e 16 direttive) e integra anche l'analizzatore statico MISRA-C nei processi di assemblaggio, che verifica la conformità ai requisiti delle specifiche.
- Fornisce la possibilità di definire una configurazione Xen statica per i sistemi ARM, che codifica in anticipo tutte le risorse necessarie per avviare i guest. Tutte le risorse, come la memoria condivisa, i canali di notifica degli eventi e lo spazio heap dell'hypervisor, vengono pre-allocate all'avvio dell'hypervisor anziché allocate dinamicamente, eliminando possibili errori dovuti alla carenza di risorse durante il funzionamento.
- Per i sistemi embedded basati su architettura ARM è stato implementato il supporto sperimentale (tech anteprima) per la virtualizzazione I/O utilizzando i protocolli VirtIO. Il trasporto virtio-mmio viene utilizzato per scambiare dati con un dispositivo I/O virtuale, che garantisce la compatibilità con un'ampia gamma di dispositivi VirtIO. È stato implementato il supporto per frontend Linux, toolkit (libxl/xl), modalità dom0less e backend in esecuzione nello spazio utente (sono stati testati i backend virtio-disk, virtio-net, i2c e gpio).
- 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. È possibile definire pool di CPU (CPUPOOL) in fase di avvio (tramite albero dei dispositivi), che consente di utilizzare pool in configurazioni senza dom0, ad esempio, per associare diversi tipi di core CPU su sistemi ARM basati su big.LITTLE architettura, che combina core potenti ma che consumano energia e core meno produttivi ma più efficienti dal punto di vista energetico. Inoltre, dom0less offre la possibilità di associare il frontend/backend di paravirtualizzazione ai sistemi guest, consentendo di avviare i sistemi guest con i dispositivi paravirtualizzati necessari.
- Sui sistemi ARM, le strutture di virtualizzazione della memoria (P2M, Physical to Machine) vengono ora allocate dal pool di memoria creato al momento della creazione del dominio, il che consente un migliore isolamento tra gli ospiti quando si verificano errori relativi alla memoria.
- Per i sistemi ARM è stata aggiunta la protezione contro la vulnerabilità Spectre-BHB nelle strutture microarchitettoniche del processore.
- Sui sistemi ARM è possibile eseguire il sistema operativo Zephyr nell'ambiente root Dom0.
- Viene fornita la possibilità di un assieme hypervisor separato (fuori dall'albero).
- Sui sistemi x86, sono supportate pagine IOMMU di grandi dimensioni (superpage) per tutti i tipi di sistemi guest, il che consente di aumentare il throughput durante l'inoltro dei dispositivi PCI. Aggiunto supporto per host dotati di un massimo di 12 TB di RAM. In fase di boot è stata implementata la possibilità di impostare i parametri cpuid per dom0. Per controllare le misure di protezione implementate a livello di hypervisor contro gli attacchi alla CPU nei sistemi ospiti, vengono proposti i parametri VIRT_SSBD e MSR_SPEC_CTRL.
- Il trasporto VirtIO-Grant è stato sviluppato separatamente, differendo da VirtIO-MMIO per un livello di sicurezza più elevato e la capacità di eseguire gestori in un dominio isolato separato per i conducenti. VirtIO-Grant, invece della mappatura diretta della memoria, utilizza la traduzione degli indirizzi fisici del sistema ospite in collegamenti di concessione, che consente l'uso di aree preconcordate di memoria condivisa per lo scambio di dati tra il sistema ospite e il backend VirtIO, senza concedere i diritti di backend per eseguire la mappatura della memoria. Il supporto VirtIO-Grant è già implementato nel kernel Linux, ma non è ancora incluso nei backend QEMU, in virtio-vhost e nel toolkit (libxl/xl).
- Continua lo sviluppo dell'iniziativa Hyperlaunch, volta a fornire strumenti flessibili per configurare l'avvio di macchine virtuali durante l'avvio del sistema. Attualmente è già stato preparato il primo set di patch che consente di rilevare i domini PV e trasferirne le immagini sull'hypervisor durante il caricamento. È stato inoltre implementato tutto il necessario per eseguire tali domini paravirtualizzati, compresi i componenti Xenstore per i driver PV. Una volta accettate le patch, inizieranno i lavori per abilitare il supporto per i dispositivi PVH e HVM, nonché l'implementazione di un dominio domB separato (dominio del builder), adatto ad organizzare un avvio misurato, confermando la validità di tutti i componenti caricati.
- Proseguono i lavori per la creazione di un port di Xen per l'architettura RISC-V.
Fonte: opennet.ru