Dopo un anno di sviluppo è stata pubblicata la versione del hypervisor open source Xen 4.17. Aziende come Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD) hanno partecipato allo sviluppo della nuova release. La formazione degli aggiornamenti per la branch Xen 4.17 continuerà fino al 12 giugno 2024, mentre la pubblicazione delle correzioni delle vulnerabilità è prevista fino al 12 dicembre 2025.
Modifiche chiave in Xen 4.17:
- È stata garantita la conformità parziale ai requisiti per lo sviluppo di software sicuri e affidabili in linguaggio C, formulati nelle specifiche MISRA-C, utilizzate per la creazione di sistemi critici. In Xen sono state ufficialmente implementate 4 direttive e 24 regole MISRA-C (su 143 regole e 16 direttive), e è stata prevista l'integrazione nel processo di compilazione del analizzatore statico MISRA-C, che verifica il rispetto dei requisiti della specifica.
- È stata fornita la possibilità di definire una configurazione statica di Xen per i sistemi ARM, che stabilisce in anticipo tutte le risorse necessarie per avviare i sistemi guest. Tutte le risorse, come la memoria condivisa, i canali per la notifica di eventi e lo spazio nel heap dell'hypervisor, vengono allocate in anticipo all'avvio dell'hypervisor, invece di essere allocate dinamicamente, il che esclude possibili malfunzionamenti dovuti alla mancanza di risorse durante l'esecuzione.
- Per i sistemi embedded basati sull'architettura ARM è stata implementata un supporto sperimentale (tech preview) per la virtualizzazione dell'input/output utilizzando i protocolli VirtIO. Per lo scambio di dati con un dispositivo virtuale di input/output viene utilizzato il trasporto virtio-mmio, il che ha permesso di garantire la compatibilità con un'ampia gamma di dispositivi VirtIO. È stato implementato il supporto per il front-end di Linux, gli strumenti (libxl/xl), la modalità dom0less e i backend eseguiti nello spazio utente (sono stati testati i backend virtio-disk, virtio-net, i2c e gpio).
- È stato migliorato il supporto per la modalità dom0less, che consente di avviare senza distribuire un ambiente dom0. macchine virtuali nella fase iniziale di caricamento del server. È stata fornita la possibilità di definire i pool CPU (CPUPOOL) durante il caricamento (tramite device tree), consentendo l'utilizzo di pool in configurazioni senza dom0, ad esempio, per associare diversi tipi di core CPU sui sistemi ARM basati sull'architettura big.LITTLE, che combinano in un unico chip core potenti ma ad alto consumo energetico e core meno performanti ma più efficienti dal punto di vista energetico. Inoltre, nel dom0less è stata fornita la possibilità di associare il frontend/backend della paravirtualizzazione ai sistemi ospiti, consentendo di avviare i sistemi ospiti con i dispositivi paravirtualizzati necessari.
- Nei sistemi ARM le strutture di virtualizzazione della memoria (P2M, Physical to Machine) ora vengono allocate da un pool di memoria creato durante la creazione del dominio, migliorando così l'efficacia dell'isolamento tra i sistemi ospiti in caso di guasti legati alla memoria.
- Per i sistemi ARM è stata aggiunta la protezione contro la vulnerabilità Spectre-BHB nelle strutture microarchitettoniche dei processori.
- Nei sistemi ARM è stata fornita la possibilità di eseguire il sistema operativo Zephyr nell'ambiente root del Dom0.
- È stata fornita la possibilità di una compilazione separata (out-of-tree) del hypervisor.
- Nei sistemi x86 è stata garantita la supporto delle grandi pagine IOMMU (superpage) per tutti i tipi di sistemi ospiti, consentendo di aumentare la larghezza di banda durante il passthrough dei dispositivi PCI. È stata aggiunta la supporto per host dotati di fino a 12 TB di RAM. Durante il caricamento è stata implementata la possibilità di specificare i parametri cpuid per il dom0. Sono stati proposti i parametri VIRT_SSBD e MSR_SPEC_CTRL per la protezione dei sistemi ospiti implementati a livello di hypervisor contro gli attacchi alla CPU.
- Si sta sviluppando separatamente il trasporto VirtIO-Grant, che si differenzia da VirtIO-MMIO per un livello di sicurezza superiore e la possibilità di eseguire gestori in un dominio isolato separato per i driver. In VirtIO-Grant, invece di un mappatura diretta della memoria, viene utilizzata la traduzione degli indirizzi fisici del sistema ospite in grant-link, consentendo di utilizzare aree di memoria condivisa pre-approvate per lo scambio di dati tra il sistema ospite e il backend VirtIO, senza concedere al backend diritti di eseguire la mappatura della memoria. Il supporto per VirtIO-Grant è già stato implementato nel kernel Linux, ma non è ancora incluso nei backend QEMU, in virtio-vhost e negli strumenti (libxl/xl).
- Continua lo sviluppo dell'iniziativa Hyperlaunch, mirata a fornire strumenti flessibili per la configurazione del lancio delle macchine virtuali durante il caricamento del sistema. Attualmente, è già pronta la prima serie di patch che consentono di identificare i domini PV e trasferire le loro immagini al hypervisor durante il caricamento. È stato anche implementato tutto il necessario per avviare simili soluzioni paravirtualizzate dei domini, inclusi i componenti Xenstore per i driver PV. Dopo l'approvazione delle patch, inizierà il lavoro per includere il supporto per i dispositivi PVH e HVM, oltre alla realizzazione di un dominio separato domB (dominio builder), idoneo a organizzare un avvio misurato (measured boot), che attesti l'autenticità di tutti i componenti caricati.
- Continua il lavoro per creare un porto Xen per l'architettura RISC-V.
Fonte: opennet.ru
