Wcześniej dowiedziałeś się, jak instrukcje można klasyfikować w różnych grupach: nieszkodliwe, wrażliwe itd. Aby zbadać większość funkcjonalności narażonych na hiperwizor, powinniśmy skupić się na instrukcjach, które zostaną uwięzione w VMM; jak już wiemy, większość z nich to instrukcje uprzywilejowane. Oznacza to, że musimy być w stanie wykonać dowolny kod gościa w Ring-0. To jest początkowy poziom dostępu, który przyjmiemy na potrzeby naszych badań. Stos wirtualizacji składa się z wielu komponentów, z których każdy działa na różnych poziomach uprawnień. Wpływ luki w zabezpieczeniach będzie zależał od dotkniętego komponentu. W najlepszym przypadku możemy naruszyć VMM (w trybie root VMX) bezpośrednio z nieuprzywilejowanego gościa. Alternatywnie możemy dążyć do wykonania w trybie jądra w hoście lub uprzywilejowanym gościu (partycja root/dom0), a w najgorszym przypadku nadal mamy stos w trybie użytkownika. Komponenty oddziałują na siebie, więc naruszenie mniej uprzywilejowanego komponentu może poszerzyć powierzchnię ataku, która może być dalej eksploatowana w łańcuchu błędów w bardziej uprzywilejowanych komponentach. Poniższe ilustracje to przegląd powierzchni ataku ujawnianej przez różne komponenty hiperwizora typu 2 i hiperwizora typu 1.
Ogólnie rzecz biorąc (w przypadku nowoczesnych, wspomaganych sprzętowo hiperwizorów) naszym punktem wyjścia do eksploracji powierzchni ataku będzie przyjrzenie się warunkom powodującym różne kody przyczyn wyjścia. Po wyjściu z maszyny wirtualnej procesor wznawia wykonywanie w trybie głównym VMX ze wskaźnika instrukcji przechowywanego w obszarze stanu hosta struktury sterowania maszyną wirtualną (VMCS). Wskazuje to na kod hiperwizora, który (po zapisaniu pewnego stanu) sprawdza pole przyczyny wyjścia VMCS i decyduje, jakie działania podjąć. Listę definicji możliwych przyczyn wyjścia można znaleźć w źródłach jądra Linux: https://github.com/torvalds/linux/blob/master/tools/arch/x86/include/uapi/as m/vmx.h. Niektóre z tych warunków wyjścia są poza naszym zasięgiem (spowodowane zdarzeniami zewnętrznymi lub niedostępne w zależności od konkretnych funkcji procesora lub konfiguracji VMCS), ale wiele z nich można wywołać, wykonując określone instrukcje w gościu.
UWAGA: Pod koniec napiszemy kilka fuzzerów, które badają EXIT_REASON_IO_INSTRUCTION, EXIT_REASON_MSR_READ i EXIT_REASON_MSR_WRITE.
Oprócz warunków wyjścia z maszyny wirtualnej, powierzchnia ataku może być również ujawniona przez mechanizmy komunikacji oparte na pamięci współdzielonej — na przykład bezpośredni dostęp do pamięci (DMA) w emulowanych urządzeniach sprzętowych lub bufory używane przez VMBus1 lub VIRTIO.2 Niestety, nie zajmiemy się tym tematem w tym rozdziale. Wreszcie, hiperwizory nie polegające na wirtualizacji wspomaganej sprzętowo ujawniają większą powierzchnię ataku, ale nie są to obecnie powszechne cele.