Po roku prac opublikowano wersję darmowego hypervisora Xen 4.17. Firmy takie jak Amazon, Arm, Bitdefender, Citrix, EPAM Systems i Xilinx (AMD) przyczyniły się do opracowania nowej wersji. Tworzenie aktualizacji dla gałęzi Xen 4.17 potrwa do 12 czerwca 2024 r., a publikacja poprawek luk do 12 grudnia 2025 r.
Kluczowe zmiany w Xen 4.17:
- Zapewniona jest częściowa zgodność z wymaganiami dotyczącymi tworzenia bezpiecznych i niezawodnych programów w języku C, sformułowanymi w specyfikacjach MISRA-C stosowanych przy tworzeniu systemów krytycznych. Xen oficjalnie wdraża 4 dyrektywy i 24 zasady MISRA-C (spośród 143 zasad i 16 dyrektyw), a także integrację z procesami montażowymi analizatora statycznego MISRA-C, który sprawdza zgodność z wymaganiami specyfikacji.
- Zapewniono możliwość zdefiniowania statycznej konfiguracji Xen dla systemów ARM, która z wyprzedzeniem koduje na stałe wszystkie zasoby potrzebne do uruchamiania systemów-gości. Wszystkie zasoby, takie jak pamięć współdzielona, kanały powiadamiania o zdarzeniach i przestrzeń na stercie hypervisora, są wstępnie przydzielane podczas uruchamiania hypervisora, a nie przydzielane dynamicznie, co eliminuje potencjalne wąskie gardła w zasobach podczas działania.
- Dla systemów wbudowanych opartych na architekturze ARM zaimplementowano eksperymentalną (tech Preview) obsługę wirtualizacji I/O z wykorzystaniem protokołów VirtIO. Do komunikacji z wirtualnym urządzeniem I/O wykorzystywany jest transport virtio-mmio, co pozwoliło zapewnić kompatybilność z szeroką gamą urządzeń VirtIO. Zaimplementowano obsługę frontendu systemu Linux, zestawu narzędzi (libxl/xl), trybu dom0less i backendów przestrzeni użytkownika (testowane backendy virtio-disk, virtio-net, i2c i gpio).
- Ulepszona obsługa trybu dom0less, która pozwala uniknąć wdrażania środowiska dom0 podczas uruchamiania maszyn wirtualnych na wczesnym etapie uruchamiania serwera. Zapewniona jest możliwość definiowania pul procesorów (CPUPOOL) na etapie rozruchu (poprzez drzewo urządzeń), co pozwala na wykorzystanie pul w konfiguracjach bez dom0, np. do wiązania różnych typów rdzeni procesorów w systemach ARM opartych na architekturze big.LITTLE , łącząc mocne, ale energochłonne rdzenie i mniej produktywne, ale bardziej energooszczędne rdzenie. Dodatkowo dom0less zapewnia możliwość powiązania frontendu/backendu parawirtualizacji z gośćmi, co pozwala na uruchomienie gości z niezbędnymi parawirtualizowanymi urządzeniami.
- W systemach ARM struktury wirtualizacji pamięci (P2M, Physical to Machine) są teraz przydzielane z puli pamięci utworzonej podczas tworzenia domeny, co pozwala na lepszą izolację między gośćmi w przypadku wystąpienia awarii związanych z pamięcią.
- Dodano ochronę przed luką Spectre-BHB w strukturach mikroarchitektury procesorów dla systemów ARM.
- W systemach ARM zapewniona jest możliwość uruchomienia systemu operacyjnego Zephyr w środowisku root Dom0.
- Zapewniona jest możliwość oddzielnego (poza drzewem) montażu hypervisora.
- W systemach x86 obsługiwane są duże strony IOMMU (superpage) dla wszystkich typów systemów-gości, co pozwala zwiększyć przepustowość podczas przekazywania urządzeń PCI. Dodano obsługę hostów z maksymalnie 12 TB pamięci RAM. Na etapie rozruchu zaimplementowano możliwość ustawienia parametrów procesora dla dom0. Parametry VIRT_SSBD i MSR_SPEC_CTRL są proponowane do kontrolowania środków ochrony na poziomie hypervisora przed atakami na procesor w systemach-gościach.
- Osobno rozwijany jest transport VirtIO-Grant, który różni się od VirtIO-MMIO wyższym poziomem bezpieczeństwa i możliwością uruchamiania procedur obsługi w osobnej izolowanej domenie dla sterowników. W VirtIO-Grant zamiast bezpośredniego mapowania pamięci wykorzystywana jest translacja adresów fizycznych gościa na łącza grantowe, co pozwala na wykorzystanie wcześniej uzgodnionych obszarów pamięci współdzielonej do wymiany danych pomiędzy systemem gościa a backendem VirtIO, bez konieczności udzielania backendu uprawnienia do wykonywania mapowania pamięci. Obsługa VirtIO-Grant jest już zaimplementowana w jądrze Linuksa, ale nie jest jeszcze uwzględniona w backendach QEMU, virtio-vhost i zestawie narzędzi (libxl/xl).
- Inicjatywa Hyperlaunch jest nadal rozwijana w celu zapewnienia elastycznych narzędzi umożliwiających dostosowywanie uruchamiania maszyn wirtualnych w czasie uruchamiania systemu. W chwili obecnej gotowy jest już pierwszy zestaw poprawek pozwalających na zdefiniowanie domen PV i przesyłanie ich obrazów do hypervisora podczas ładowania. Zaimplementowano również wszystko, co potrzebne do uruchomienia takich parawirtualnych domen, w tym komponenty Xenstore do sterowników PV. Po zaakceptowaniu poprawek rozpoczną się prace nad umożliwieniem obsługi urządzeń PVH i HVM, a także wdrożeniem osobnej domeny domB (domena builder) odpowiedniej do organizacji mierzonego rozruchu (measured boot), potwierdzającego ważność wszystkich załadowanych komponentów.
- Trwają prace nad portem Xen dla architektury RISC-V.
Źródło: opennet.ru