SynIC MSR

https://chacker.pl/

Syntic Interrupt Controller (SynIC) jest rozszerzeniem wirtualizowanego kontrolera przerwań (wirtualnego LAPIC). SynIC nie tylko zapewnia wydajne dostarczanie przerwań, ale jest również używany do komunikacji między partycjami. Partycje mogą komunikować się ze sobą za pomocą dwóch mechanizmów: wiadomości i zdarzeń. Gdy partycja docelowa otrzymuje wiadomość lub zdarzenie, odbywa się to za pośrednictwem SynIC. SynIC CONTROL MSR Każdy procesor wirtualny ma SynIC, który jest domyślnie wyłączony. Aby włączyć SynIC dla bieżącego procesora wirtualnego, musimy zapisać do rejestru HV_X64_MSR_SCONTROL (0x40000080), ustawiając jego pole „enable”. Układ rejestru HV_X64_MSR_SCONTROL jest następujący:

  • Bity 63–1 Bity zarezerwowane.
  • Bit 0 Włącz/wyłącz SynIC dla bieżącego procesora wirtualnego.

Rejestry SINT MSR SynIC udostępnia 16 kolejnych rejestrów „źródła przerwań syntetycznych” (SINTx): HV_X64_MSR_SINT0 (0x40000090) do HV_X64_MSR_SINT15 (0x4000009F). Źródła przerwań mogą być selektywnie demaskowane, a następnie przypisywane do określonego wektora przerwań. W ten sposób gość może być powiadamiany o zdarzeniach za pośrednictwem przerwań (jeśli przerwania są włączone), które są obsługiwane przez odpowiednią procedurę serwisową z IDT (Interrupt Descriptor Table) gościa. Układ rejestru SINT jest następujący:

  • Bity 63–19 Zarezerwowane bity.
  • Bit 18 Pole „Polling”. Jeśli ten bit jest włączony, źródło przerwań jest demaskowane bez generowania przerwań.
  • Bit 17 Pole „AutoEOI”. Jeśli ten bit jest włączony, po dostarczeniu przerwania wykonywany jest niejawny End Of Interrupt (EOI).
  • Pole „Masked” bitu 16. Wszystkie rejestry SINT zaczynają się od tego bitu ustawionego domyślnie. Gość może odmaskować źródło przerwania, czyszcząc ten bit.
  • Bity 15–8 Zarezerwowane bity.
  • Bity 7–0 Wektor przerwania. Gość może ustawić tę wartość na dowolny wektor w zakresie 16–255.

Docelowy SINTx wiadomości lub zdarzenia może być następujący:

  • Niejawny (na przykład SINT0 jest zarezerwowany dla wiadomości pochodzących z hiperwizora).
  • Jawny (na przykład pole SINTx rejestrów Synthetic Timer Configuration).
  • Przypisany do portu przydzielonego przez hiperwywołanie HvCallCreatePort.

Wywołujący musi określić typ portu: HvPortTypeMessage, HvPortTypeEvent lub HvPortTypeMonitor. W przypadku pierwszych dwóch typów należy określić docelowy SINTx. To hiperwywołanie jest używane przez partycję główną do tworzenia portów używanych przez VMBus. SIMP MSR Rejestr HV_X64_MSR_SIMP (0x40000083) jest używany do włączania i przypisywania adresu bazowego strony wiadomości syntetycznego przerwania (SIMP). Ta strona zawiera zestaw gniazd wiadomości do odbierania wiadomości z hiperwizora lub innych partycji (nadawcy używają hiperwywołania HvCallPostMessage). Gniazda są ułożone jako tablica struktur danych HV_MESSAGE, z jednym gniazdem na SINTx (16). Po skopiowaniu nowej wiadomości do gniazda hiperwizor spróbuje dostarczyć przerwanie wyzwalane krawędzią do odpowiedniego SINTx (jeśli nie jest w trybie sondowania). Struktura HV_MESSAGE jest zdefiniowana w następujący sposób:

HV_MESSAGE składa się z nagłówka i ładunku zawierającego faktyczną wiadomość. Nagłówek wiadomości zaczyna się od 32-bitowego identyfikatora (1). Wiadomości pochodzące z hiperwizora mają ustawiony bit

HV_MESSAGE_TYPE_HYPERVISOR_MASK (0x80000000),

podczas gdy wiadomości pochodzące z partycji mogą używać dowolnej innej wartości, o ile nie ustawią tego bitu. Wartość HvMessageTypeNone (0x00000000) oznacza, że ​​slot jest pusty. Po otrzymaniu wiadomości gość powinien ustawić MessageType na HvMessageTypeNone, a następnie potwierdzić koniec wiadomości (EOM). Na koniec nagłówek zawiera albo identyfikator partycji (2) (na przykład wiadomości przechwytujące zawierają identyfikator dziecka) albo identyfikator portu (3) (skojarzony z identyfikatorem połączenia), gdy wiadomość została wysłana za pośrednictwem HvCallPostMessage. Układ HV_X64_MSR_SIMP jest następujący:

  • Bity 63–12 GPFN, gdzie mapowany jest SIMP.
  • Bity 11–1 Zarezerwowane.
  • Bit 0 Włącz/wyłącz SIMP.EOM MSR Po przetworzeniu wiadomości dostarczonej do gniazda SIMP i ustawieniu jej na HvMessageTypeNone możemy zapisać zero w HV_X64_MSR_EOM (0x40000084), aby hiperwizor wiedział, że może usunąć z kolejki i dostarczyć następną wiadomość.

    SIEFP MSR HV_X64_MSR_SIEFP (0x40000082) służy do włączania i

    przypisywania adresu bazowego strony Synthetic Interrupt Event Flags Page (SIEFP). Ta strona zawiera 16-elementową tablicę HV_SYNIC_EVENT_FLAGS; każdy element jest bitmapą o stałym rozmiarze i pojemności 2048 flag:

Gdy port HvPortTypeEvent jest przydzielany za pomocą HvCallCreatePort, należy podać następujące informacje:

Oprócz docelowego SINTx (1) i docelowego procesora wirtualnego (2), port zdarzeń ma numer flagi bazowej (3) i liczbę flag (4). Partycja może użyć HvCallSignalEvent do ustawienia określonej flagi w partycji docelowej, przekazując dwa parametry: parametr identyfikatora połączenia (skojarzony z portem zdarzeń) i numer flagi (ten numer musi być niższy od FlagCount portu zdarzeń). Wartość BaseFlagNumber jest dodawana do numeru flagi, a wynikiem jest bezwzględna pozycja bitowa, która zostanie ustawiona w mapie bitowej HV_SYNIC_EVENT_FLAGS gniazda odpowiadającego docelowemu SINTx. Po ustawieniu flagi hiperwizor spróbuje dostarczyć przerwanie wyzwalane krawędzią do odpowiadającego mu SINTx (jeśli nie jest w trybie sondowania). Gość odbierający zdarzenia powinien użyć atomowej instrukcji Compare and Swap (CAS), aby wyczyścić flagi, a następnie potwierdzić EOI (za pośrednictwem APIC). Układ HV_X64_MSR_SIEFP jest następujący:

  • Bity 63–12 GPFN, gdzie mapowany jest SIEFP.
  • Bity 11–1 Zarezerwowane.
  • Bit 0 Włącz/wyłącz SIEFP.

Konfigurowanie strony Hypercall i zrzucanie jej zawartości

https://chacker.pl/

Jeśli wywołamy moduł GHHv6/ch25/labs/hypercall.py bezpośrednio, zrzuci on zawartość strony Hypercall po jej zmapowaniu. Możemy go użyć, aby zaobserwować, jaka instrukcja implementuje mechanizm Hypercall dla naszego bieżącego procesora:

W tym przypadku instrukcją jest VMCALL (1), po której następuje instrukcja RET (2). Gość może wydać hiperwywołanie, wykonując instrukcję CALL na adres strony hiperwywołania (w tym przypadku 0x1011000). Możemy również zobaczyć kod używany do wykonywania wywołań VTL. W punkcie (3) rejestr EAX jest ustawiony na 0x11, co odpowiada kodowi wywołania HvCallVtlCall (jest to 32-bitowy ABI). W punkcie (4) mamy 64-bitową wersję tego samego wywołania. Wywołanie w punkcie (5) odpowiada 32-bitowemu HvCallVtlReturn, a w punkcie (6) mamy wersję 64-bitową. Reszta strony hiperwywołania jest wypełniona wzorcem NOP.

Strona hiperwywołania MSR

https://chacker.pl/

Dostawcy procesorów używają różnych instrukcji hiperwywołania; Hyper-V zapewnia ogólny interfejs, mapując „stronę hiperwywołania” zawierającą właściwą instrukcję dla bieżącego procesora. Gość nie musi wiedzieć, której instrukcji hiperwywołania użyć, i nie powinien próbować używać instrukcji, takich jak VMCALL bezpośrednio. Zamiast tego hiperwywołania powinny być używane za pośrednictwem strony hiperwywołania.

WSKAZÓWKA :  Jeśli znasz strony VSYSCALL/VDSO systemu Linux, ta sama koncepcja jest stosowana w stronie hiperwywołania.  Napiszemy GPA do HV_X64_MSR_HYPERCALL (0x40000001), gdzie chcemy, aby strona hiperwywołania została zmapowana. Układ tego MSR jest następujący:

  • Bity 63–12 Zawierają numer strony fizycznej gościa (GPFN), gdzie jest zmapowana strona hiperwywołania.
  • ​​Bity 11–2 Zarezerwowane bity (ignorowane).
  • Bit 1 Jeśli ten bit jest ustawiony, MSR staje się niezmienny. Po tym, GPFN nie może zostać zmodyfikowany, dopóki gość nie zostanie ponownie uruchomiony.

• Bit 0 Włącz/wyłącz stronę hiperwywołania

Tożsamość gościnnego systemu operacyjnego MSR

https://chacker.pl/

Zanim będziemy mogli korzystać z funkcji, takich jak hiperwywołania, musimy zarejestrować naszą tożsamość gościnnego systemu operacyjnego w Hyper-V. Można to osiągnąć, zapisując informacje o dostawcy i wersji systemu operacyjnego w rejestrze HV_X64_MSR_GUEST_OS_ID (0x40000000). W module GHHv6/ch25/labs/hypercall.py dostarczonym z kodem tego rozdziału ustawiamy ten MSR na identyfikator, który fałszuje gościa systemu Windows 10.

Syntetyczne MSR

https://chacker.pl/

Hyper-V udostępnia zestaw syntetycznych MSR, do których można uzyskać dostęp za pomocą instrukcji RDMSR/WRMSR. Listę tych MSR można znaleźć w specyfikacji funkcjonalnej najwyższego poziomu hiperwizora (TLFS). Skupimy się na MSR używanych do mapowania „strony hiperwywołań” i tych używanych do zarządzania SynIC.

Interfejs syntetyczny Hyper-V

https://chacker.pl/

Hyper-V udostępnia interfejs dla funkcji parawirtualizacji, które zwiększają wydajność maszyn wirtualnych i zapewniają obsługę komunikacji między partycjami. VMM udostępnia ten interfejs syntetyczny poprzez rozszerzenia do rejestrów specyficznych dla modelu (MSR), kontrolera przerwań syntetycznych (SynIC) i hiperwywołań. Oprócz interfejsu komunikacji między partycjami udostępnianego przez VMM partycja główna implementuje VMBus, który jest używany przez VSP i IC.

Skanowanie urządzeń PCI w maszynie wirtualnej generacji 2

https://chacker.pl/

Zobaczmy, co się stanie, jeśli spróbujemy przeskanować magistralę PCI w maszynie wirtualnej generacji 2:

W tym przypadku nie ma żadnego wyjścia — nie tylko emulowane urządzenia znikają, ale cała magistrala PCI również! W rzeczywistości kilka emulowanych urządzeń (na przykład wideo) nadal pozostaje; po prostu nie możemy ich znaleźć za pomocą magistrali PCI. Nadal można je znaleźć za pomocą tabel ACPI udostępnionych gościowi.

Maszyny wirtualne generacji 2

https://chacker.pl/

Nowsze maszyny wirtualne „Generacji 2” mogą obsługiwać wyłącznie gości świadomych wirtualizacji („oświeconych”). Poza kilkoma emulowanymi urządzeniami większość została zastąpiona przez urządzenia syntetyczne. Zapewniają one „oświecone wejście/wyjście” za pośrednictwem wydajnego mechanizmu komunikacji między partycjami znanego jako VMBus. Urządzenia syntetyczne są zwykle oparte na istniejących protokołach (takich jak SCSI, RNDIS lub HID), ale używają VMBus jako podstawowej warstwy transportowej. Później w tym rozdziale omówimy VMBus bardziej szczegółowo. Maszyny wirtualne generacji 2 są oparte na architekturze Unified Extensible Firmware Interface (UEFI), która umożliwia funkcje takie jak Secure Boot, a także umożliwia maszynom wirtualnym uruchamianie się z urządzeń parawirtualizowanych.

Skanowanie urządzeń PCI w maszynie wirtualnej pierwszej generacji

https://chacker.pl/

Nasze ramy obejmują moduł GHHv6/ch25/labs/pci.py, który można wykorzystać do wstrzykiwania i wykonywania kodu skanującego magistralę PCI gościa. Użyjmy tego modułu, aby zobaczyć, jaki sprzęt jest obecny w maszynie wirtualnej pierwszej generacji. Aby to zrobić, otworzymy powłokę Pythona na naszym polu „klient” (uruchomimy wszystkie laboratoria  z naszego pola „klient”):

Na wyjściu możemy zobaczyć informacje o emulowanych urządzeniach obecnych na maszynie wirtualnej pierwszej generacji utworzonej przy użyciu domyślnej konfiguracji.

UWAGA : Nasza nowa klasa bazowa nazywa się teraz Session i jest uogólnieniem klasy Fuzzer, którą zaimplementowaliśmy wcześniej.

Maszyny wirtualne generacji 1

https://chacker.pl/

Istnieją dwie „generacje” maszyn wirtualnych w Hyper-V. Stare maszyny wirtualne znane jako „Generacja 1” zapewniają pełną emulację urządzenia (zaimplementowaną w procesie roboczym) w celu uruchamiania niezmodyfikowanych systemów operacyjnych gości. To emulowane środowisko jest architekturą opartą na systemie BIOS ze starszymi urządzeniami. Urządzenia parawirtualizowane („syntetyczne”) są również dostępne dla gości obsługujących wirtualizację; jednak goście generacji 1 mogą uruchamiać się tylko z emulowanych urządzeń.