Po ośmiu miesiącach prac wypuszczono darmowy hypervisor Xen 4.16. W opracowaniu nowej wersji wzięły udział takie firmy jak Amazon, Arm, Bitdefender, Citrix i EPAM Systems. Wydanie aktualizacji dla gałęzi Xen 4.16 potrwa do 2 czerwca 2023 r., a publikacja poprawek luk do 2 grudnia 2024 r.
Kluczowe zmiany w Xen 4.16:
- Menedżer TPM zapewniający działanie wirtualnych chipów do przechowywania kluczy kryptograficznych (vTPM), zaimplementowany w oparciu o wspólny fizyczny moduł TPM (Trusted Platform Module), został poprawiony w celu późniejszej implementacji obsługi specyfikacji TPM 2.0.
- Zwiększona zależność od warstwy PV Shim używanej do uruchamiania niezmodyfikowanych gości parawirtualnych (PV) w środowiskach PVH i HVM. W przyszłości korzystanie z 32-bitowych parawirtualnych gości będzie możliwe tylko w trybie PV Shim, co zmniejszy liczbę miejsc w hiperwizorze, które mogą potencjalnie zawierać luki.
- Dodano możliwość uruchamiania na urządzeniach Intel bez programowalnego timera (PIT, Programmable Interval Timer).
- Wyczyszczono przestarzałe komponenty, zaprzestano budowania domyślnego kodu „qemu-xen-traditional” i PV-Grub (potrzeba tych forków specyficznych dla Xen zniknęła po przeniesieniu zmian z obsługą Xen do głównej struktury QEMU i Gruba).
- Dla gości z architekturą ARM zaimplementowano wstępną obsługę zwirtualizowanych liczników monitorów wydajności.
- Ulepszona obsługa trybu dom0less, która pozwala uniknąć wdrażania środowiska dom0 podczas uruchamiania maszyn wirtualnych na wczesnym etapie uruchamiania serwera. Wprowadzone zmiany umożliwiły zaimplementowanie obsługi 64-bitowych systemów ARM z oprogramowaniem EFI.
- Ulepszona obsługa heterogenicznych 64-bitowych systemów ARM opartych na architekturze big.LITTLE, które łączą w jednym chipie mocne, ale energochłonne rdzenie i mniej wydajne, ale bardziej energooszczędne rdzenie.
Jednocześnie Intel opublikował wydanie hiperwizora Cloud Hypervisor 20.0, zbudowanego w oparciu o komponenty wspólnego projektu Rust-VMM, w którym oprócz Intela uczestniczą także Alibaba, Amazon, Google i Red Hat. Rust-VMM jest napisany w języku Rust i umożliwia tworzenie hiperwizorów dostosowanych do konkretnych zadań. Cloud Hypervisor to jeden z takich hypervisorów, który zapewnia monitor maszyn wirtualnych wysokiego poziomu (VMM) działający na KVM i zoptymalizowany pod kątem zadań natywnych w chmurze. Kod projektu dostępny jest na licencji Apache 2.0.
Cloud Hypervisor koncentruje się na uruchamianiu nowoczesnych dystrybucji Linuksa przy użyciu parawirtualnych urządzeń opartych na virtio. Wśród kluczowych celów wymieniono: wysoką responsywność, niskie zużycie pamięci, wysoką wydajność, uproszczoną konfigurację i redukcję możliwych wektorów ataku. Obsługa emulacji jest ograniczona do minimum, a nacisk położony jest na parawirtualizację. Obecnie obsługiwane są tylko systemy x86_64, ale planowana jest obsługa AArch64. W przypadku systemów gościnnych obsługiwane są obecnie tylko 64-bitowe kompilacje systemu Linux. Procesor, pamięć, PCI i NVDIMM są konfigurowane na etapie montażu. Istnieje możliwość migracji maszyn wirtualnych pomiędzy serwerami.
W nowej wersji:
- W przypadku architektur x86_64 i aarch64 dozwolonych jest teraz do 16 segmentów PCI, co zwiększa całkowitą liczbę dozwolonych urządzeń PCI z 31 do 496.
- Zaimplementowano obsługę wiązania wirtualnych procesorów z fizycznymi rdzeniami procesorów (przypinanie procesora). Dla każdego procesora wirtualnego można teraz zdefiniować ograniczony zestaw procesorów hosta, na których dozwolone jest wykonanie, co może być przydatne podczas bezpośredniego mapowania (1:1) zasobów hosta i gościa lub podczas uruchamiania maszyny wirtualnej w określonym węźle NUMA.
- Ulepszona obsługa wirtualizacji we/wy. Każdy region VFIO można teraz zmapować do pamięci, co zmniejsza liczbę wyjść maszyny wirtualnej i poprawia wydajność przekazywania urządzeń do maszyny wirtualnej.
- W kodzie Rusta wykonano prace mające na celu zastąpienie niebezpiecznych sekcji alternatywnymi implementacjami wykonywanymi w trybie awaryjnym. Do pozostałych niebezpiecznych sekcji dodano szczegółowe komentarze wyjaśniające, dlaczego pozostały niebezpieczny kod można uznać za bezpieczny.
Źródło: opennet.ru