Dopo un anno di sviluppo, è stato pubblicato il rilascio del hypervisor libero Xen 4.17. Hanno partecipato allo sviluppo di questa nuova versione aziende come Amazon, Arm, Bitdefender, Citrix, EPAM Systems e Xilinx (AMD). La formazione degli aggiornamenti per la serie Xen 4.17 continuerà fino al 12 giugno 2024, mentre la pubblicazione delle correzioni di vulnerabilità sarà fino al 12 dicembre 2025.
Principali modifiche in Xen 4.17:
- È stato garantito un parziale rispetto dei requisiti per lo sviluppo di software sicuro e affidabile in linguaggio C, come delineato nelle specifiche MISRA-C, utilizzate nella creazione di sistemi critici. In Xen sono state ufficialmente implementate 4 direttive e 24 regole di MISRA-C (su 143 regole e 16 direttive), e inoltre è stata assicurata l'integrazione nel processo di build dell'analizzatore statico MISRA-C, che verifica l'osservanza dei requisiti della specifica.
- È stata introdotta la possibilità di definire una configurazione statica di Xen per i sistemi ARM, che determina in anticipo tutte le risorse necessarie per l'avvio delle macchine virtuali. Tutte le risorse, come la memoria condivisa, i canali per le notifiche di eventi e lo spazio nella heap del hypervisor, vengono allocate in anticipo durante l'avvio dell'hypervisor e non assegnate dinamicamente, eliminando possibili fallimenti dovuti a 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 il dispositivo virtuale di input/output viene utilizzato il trasporto virtio-mmio, il quale ha permesso di garantire la compatibilità con un'ampia gamma di dispositivi VirtIO. È stato implementato il supporto per il frontend di Linux, gli strumenti (libxl/xl), la modalità dom0less e i backend che vengono eseguiti nello spazio utente (sono stati testati i backend virtio-disk, virtio-net, i2c e gpio).
- Migliorato il supporto per la modalità dom0less, che consente di avviare senza dover implementare un ambiente dom0. di macchine virtuali nella fase iniziale di avvio del server. È stata fornita la possibilità di definire pool di CPU (CPUPOOL) durante il caricamento (attraverso il device tree), consentendo l'uso dei pool in configurazioni senza dom0, ad esempio, per l'associazione di diversi tipi di core CPU su sistemi ARM basati sull'architettura big.LITTLE, che combinano in un unico chip core potenti ma ad alta energia e core meno performanti ma più efficienti dal punto di vista energetico. Inoltre, in dom0less è stata fornita la possibilità di associare il frontend/backend della paravirtualizzazione ai sistemi guest, consentendo di avviare i sistemi guest con i dispositivi paravirtualizzati necessari.
- Nei sistemi ARM, le strutture di virtualizzazione della memoria (P2M, Physical to Machine) vengono ora allocate da un pool di memoria creato durante la creazione del dominio, migliorando l'efficienza dell'isolamento tra i sistemi guest in caso di guasti legati alla memoria.
- Per i sistemi ARM è stata aggiunta la protezione contro la vulnerabilità Spectre-BHB nelle strutture microarchitetturali dei processori.
- Nei sistemi ARM, è possibile avviare il sistema operativo Zephyr nell'ambiente root di Dom0.
- È stata fornita la possibilità di una configurazione separata (out-of-tree) dell'iperlibero.
- Nei sistemi x86 è supportata la gestione di grandi pagine IOMMU (superpage) per tutti i tipi di sistemi guest, il che consente di aumentare la larghezza di banda per il passthrough delle periferiche PCI. È stata aggiunta la supporto per host con fino a 12 TB di RAM. Durante la fase di avvio è possibile configurare i parametri cpuid per il dom0. Per la gestione delle misure di protezione contro gli attacchi alla CPU implementate a livello di ipervisor nei sistemi guest, sono stati proposti i parametri VIRT_SSBD e MSR_SPEC_CTRL.
- Si sviluppa separatamente il trasporto VirtIO-Grant, che si distingue 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 della mappatura diretta della memoria, si utilizza la traduzione degli indirizzi fisici del sistema ospite in grant-link, il che consente di utilizzare aree di memoria condivisa pre-accordate per lo scambio di dati tra il sistema ospite e il backend VirtIO, senza concedere al backend diritti di esecuzione sulla 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 dell'avvio delle macchine virtuali durante il caricamento del sistema. Attualmente è pronto il primo insieme di patch che consente di definire i domini PV e trasferire le loro immagini al caricatore del hypervisor all'avvio. È stato implementato anche tutto il necessario per l'avvio di tali ambienti paravirtualizzati. domini, inclusi i componenti Xenstore per i driver PV. Dopo l'accettazione delle patch, inizierà il lavoro per l'inclusione del supporto per dispositivi PVH e HVM, oltre all'implementazione di un dominio separato domB (dominio builder), adatto per l'organizzazione di un avvio misurato (measured boot), che convalida l'accuratezza di tutti i componenti di avvio.
- Continua il lavoro per la creazione di una porta Xen per l'architettura RISC-V.
Fonte: opennet.ru
