Po roku prac rozwojowych opublikowano wydanie wolnego hiperenizora Xen 4.17. W rozwój nowej wersji zaangażowały się takie firmy jak Amazon, Arm, Bitdefender, Citrix, EPAM Systems i Xilinx (AMD). Tworzenie aktualizacji dla gałęzi Xen 4.17 potrwa do 12 czerwca 2024 roku, a publikacja poprawek zabezpieczeń do 12 grudnia 2025 roku.
Kluczowe zmiany w Xen 4.17:
- Zrealizowano częściowe dostosowanie do wymagań dotyczących tworzenia bezpiecznych i niezawodnych programów w języku C, przedstawionych w specyfikacjach MISRA-C stosowanych przy tworzeniu krytycznych systemów. W Xen oficjalnie wprowadzono 4 dyrektywy i 24 zasady MISRA-C (spośród 143 zasad i 16 dyrektyw), a także zapewniono integrację z procesami budowania statycznego analizatora MISRA-C, który weryfikuje spełnianie wymagań specyfikacji.
- Umożliwiono definiowanie statycznej konfiguracji Xen dla systemów ARM, która z góry sztywno określa wszystkie zasoby niezbędne do uruchomienia systemów gościnnych. Wszystkie zasoby, takie jak pamięć współdzielona, kanały do powiadamiania o zdarzeniach i miejsce w stercie hiperenizora, są przydzielane z góry podczas uruchamiania hiperenizora, a nie przydzielane dynamicznie, co eliminuje potencjalne awarie spowodowane niedoborem zasobów podczas działania.
- Dla systemów wbudowanych opartych na architekturze ARM wprowadzono eksperymentalne (tech preview) wsparcie dla wirtualizacji wejścia/wyjścia z użyciem protokołów VirtIO. Do wymiany danych z wirtualnym urządzeniem wejścia/wyjścia wykorzystano transport virtio-mmio, co umożliwiło zapewnienie kompatybilności z szeroką gamą urządzeń VirtIO. Wsparcie dla frontendu dla Linux, narzędzi (libxl/xl), trybu dom0less oraz backendów uruchamianych w przestrzeni użytkownika (przetestowano backendy virtio-disk, virtio-net, i2c oraz gpio).
- Poprawiono wsparcie dla trybu dom0less, który pozwala na uruchomienie bez rozwoju środowiska dom0 na wczesnym etapie ładowania serwera. Wprowadzone zmiany umożliwiły wsparcie dla 64-bitowych systemów ARM z EFI firmware. maszyn wirtualnych Na wczesnym etapie uruchamiania serwera. Umożliwiono określenie pul CPU (CPUPOOL) na etapie ładowania (poprzez drzewo urządzeń), co pozwala na wykorzystanie pul w konfiguracjach bez dom0, na przykład do przypisywania różnych typów rdzeni CPU w systemach ARM opartych na architekturze big.LITTLE, łączących w jednym chipie mocne, ale energochłonne rdzenie, oraz mniej wydajne, ale bardziej energooszczędne rdzenie. Ponadto, w przypadku dom0less wprowadzono możliwość przypisania front-endu/back-endu parawirtualizacji do systemów gościnnych, co pozwala na uruchamianie systemów gościnnych z potrzebnymi 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 zwiększa efektywność izolacji między systemami gośćmi w przypadku związanych z pamięcią awarii.
- W systemach ARM dodano ochronę przed podatnością Spectre-BHB w mikroarchitektonicznych strukturach procesorów.
- W systemach ARM umożliwiono uruchamianie systemu operacyjnego Zephyr w środowisku domowym Dom0.
- Umożliwiono oddzielne (out-of-tree) kompilowanie hypervisora.
- W systemach x86 zapewniono wsparcie dla dużych stron IOMMU (superpage) dla wszystkich typów systemów gościnnych, co zwiększa przepustowość w przypadku przekazywania urządzeń PCI. Dodano wsparcie dla hostów wyposażonych do 12 TB RAM. W etapie ładowania wprowadzono możliwość ustawienia parametrów cpuid dla dom0. W celu zarządzania w systemach gościnnych wdrożonymi na poziomie hypervisora środkami ochrony przed atakami na CPU zaoferowano parametry VIRT_SSBD i MSR_SPEC_CTRL.
- Oddzielnie rozwija się transport VirtIO-Grant, który różni się od VirtIO-MMIO wyższym poziomem bezpieczeństwa i możliwością uruchamianie obsługi w oddzielnej, izolowanej domenie dla sterowników. W VirtIO-Grant zamiast bezpośredniego mapowania pamięci stosowana jest translacja adresów fizycznych systemu gościnnego w grant-linki, co umożliwia korzystanie z wcześniej uzgodnionych obszarów pamięci dzielonej do wymiany danych między systemem gościnnym a backendem VirtIO, bez przyznawania backendowi praw do mapowania pamięci. Wsparcie dla VirtIO-Grant już zostało wdrożone w jądrze Linux, ale jeszcze nie włączono go do backendów QEMU, w virtio-vhost i w narzędziach (libxl/xl).
- Trwa rozwój inicjatywy Hyperlaunch, mającej na celu dostarczenie elastycznych narzędzi do konfiguracji uruchamiania maszyn wirtualnych podczas rozruchu systemu. Obecnie gotowy jest już pierwszy zestaw łatek, które pozwalają na ustalanie PV-domen i przekazywanie ich obrazów do hipernadzorcy podczas uruchamiania. Zrealizowano również wszystko, co niezbędne do uruchomienia takich parawirtualizowanych. domenów, w tym komponenty Xenstore dla sterowników PV. Po przyjęciu łatek rozpocznie się praca nad włączeniem wsparcia dla urządzeń PVH i HVM, a także realizacją oddzielnej domeny domB (builder domain), nadającej się do organizacji mierzonego rozruchu (measured boot), potwierdzającego autentyczność wszystkich ładowanych komponentów.
- Trwają prace nad stworzeniem portu Xen dla architektury RISC-V.
Źródło: opennet.ru
