Nyolc hónapos fejlesztés után megjelent az ingyenes Xen 4.16 hypervisor. Az új kiadás fejlesztésében olyan cégek vettek részt, mint az Amazon, az Arm, a Bitdefender, a Citrix és az EPAM Systems. A Xen 4.16 ág frissítéseinek kiadása 2. június 2023-ig, a sebezhetőségi javítások közzététele pedig 2. december 2024-ig tart.
Főbb változások a Xen 4.16-ben:
- A kriptográfiai kulcsok (vTPM) tárolására szolgáló virtuális chipek működését biztosító TPM Manager egy közös fizikai TPM (Trusted Platform Module) alapján került megvalósításra, és a későbbiekben a TPM 2.0 specifikáció támogatását valósítja meg.
- Megnövelt függőség a PV Shim rétegtől, amelyet a módosítatlan paravirtualizált (PV) vendégek futtatására használnak PVH és HVM környezetben. A továbbiakban a 32 bites paravirtualizált vendégek használata csak PV Shim módban lesz lehetséges, ami csökkenti a hypervisor azon helyek számát, amelyek potenciálisan sebezhetőséget tartalmazhatnak.
- Programozható időzítő (PIT, Programmable Interval Timer) nélküli Intel-eszközökön való rendszerindítás lehetősége.
- Megtisztította az elavult komponenseket, leállította a "qemu-xen-traditional" és a PV-Grub alapértelmezett kódjának építését (a Xen-specifikus villák iránti igény megszűnt, miután a Xen támogatással végzett változtatások átkerültek a QEMU és a Grub fő struktúrájába).
- Az ARM architektúrával rendelkező vendégek számára a virtualizált teljesítményfigyelő számlálók kezdeti támogatása megtörtént.
- Továbbfejlesztett támogatás a dom0less módhoz, amely lehetővé teszi, hogy elkerülje a dom0 környezet üzembe helyezését a virtuális gépek elindításakor a szerver indításának korai szakaszában. A változtatások lehetővé tették a 64 bites ARM rendszerek támogatását EFI firmware-rel.
- A big.LITTLE architektúrán alapuló heterogén 64 bites ARM rendszerek továbbfejlesztett támogatása, amelyek egyetlen chipben egyesítik az erős, de energiaéhes magokat és a kisebb teljesítményű, de energiahatékonyabb magokat.
Ezzel egy időben az Intel közzétette a közös Rust-VMM projekt összetevőire épülő Cloud Hypervisor 20.0 hypervisor kiadását, amelyben az Intel mellett az Alibaba, az Amazon, a Google és a Red Hat is részt vesz. A Rust-VMM Rust nyelven íródott, és lehetővé teszi feladatspecifikus hipervizorok létrehozását. A Cloud Hypervisor egy ilyen hipervizor, amely magas szintű virtuális gép-figyelőt (VMM) biztosít, amely a KVM tetején fut, és a felhőalapú feladatokra optimalizálva van. A projekt kódja az Apache 2.0 licenc alatt érhető el.
A Cloud Hypervisor a modern Linux disztribúciók virtio-alapú paravirtualizált eszközökkel történő futtatására összpontosít. Az említett kulcsfontosságú célok között szerepel: nagy válaszkészség, alacsony memóriafogyasztás, nagy teljesítmény, egyszerűsített konfiguráció és a lehetséges támadási vektorok csökkentése. Az emuláció támogatása minimálisra csökken, és a hangsúly a paravirtualizáción van. Jelenleg csak x86_64 rendszerek támogatottak, de az AArch64 támogatást tervezik. Vendégrendszereknél jelenleg csak a 64 bites Linux buildek támogatottak. A CPU, a memória, a PCI és az NVDIMM konfigurálása az összeszerelési szakaszban történik. Lehetőség van a virtuális gépek kiszolgálók közötti migrációjára.
Az új verzióban:
- Az x86_64 és az aarch64 architektúrák esetében immár legfeljebb 16 PCI szegmens engedélyezett, ami 31-ről 496-ra növeli az engedélyezett PCI-eszközök teljes számát.
- A virtuális CPU-k fizikai CPU-magokhoz kötésének támogatása (CPU rögzítés) megvalósult. Mostantól minden egyes vCPU-hoz meg lehet határozni a gazda-CPU-k korlátozott készletét, amelyeken a végrehajtás engedélyezett, ami hasznos lehet a hoszt- és vendégerőforrások közvetlen leképezésekor (1:1), vagy amikor virtuális gépet futtat egy adott NUMA-csomóponton.
- Továbbfejlesztett támogatás az I/O virtualizációhoz. Mostantól minden VFIO-régió hozzárendelhető a memóriához, ami csökkenti a virtuális gépből való kilépések számát, és javítja az eszköz virtuális gépre történő továbbításának teljesítményét.
- A Rust kódban a nem biztonságos szakaszokat csökkentett módban végrehajtott alternatív megvalósításokkal helyettesítették. A fennmaradó nem biztonságos szakaszokhoz részletes megjegyzéseket adtunk, amelyek elmagyarázzák, hogy a fennmaradó nem biztonságos kód miért tekinthető biztonságosnak.
Forrás: opennet.ru