Zabezpieczenia

Aby zapobiec uruchamianiu dowolnych ładunków wewnątrz pVM, platforma wirtualizacji systemu Android (AVF) wykorzystuje warstwowe podejście do zabezpieczeń, w którym każda warstwa dodaje dodatkowe wymuszenia. Poniżej znajduje się lista warstw zabezpieczeń AVF:

  • Android — system Android zapewnia, że ​​tylko aplikacje z uprawnieniami pVM mogą tworzyć lub sprawdzać pVM.

  • Bootloader — bootloader zapewnia, że ​​tylko obrazy pVM podpisane przez Google lub dostawców urządzeń mogą się uruchamiać i przestrzega procedury Android Verified Boot . Ta architektura oznacza, że ​​aplikacje z pVM nie mogą łączyć własnych jąder.

  • pVM — pVM zapewnia dogłębną obronę, taką jak SELinux , dla ładunków uruchamianych w pVM. Dogłębna ochrona nie zezwala na mapowanie danych jako wykonywalnych ( neverallow execmem ) i zapewnia, że ​​W^X zachowuje się dla wszystkich typów plików.

Model bezpieczeństwa

Poufność, integralność i dostępność, znana również jako triada CIA, to model zaprojektowany do kierowania polityką bezpieczeństwa informacji:

  • Poufność to zestaw reguł, które ograniczają dostęp do informacji.
  • Uczciwość to pewność, że informacje są wiarygodne i dokładne.
  • Dostępność jest gwarancją niezawodnego dostępu do informacji przez uprawnione podmioty.

Należy pamiętać, że pKVM został zaprojektowany w celu zachowania poufności i integralności, ale nie dostępności gości. Zasady te wpływają na decyzje projektowe dotyczące wszystkich aspektów architektury, od hiperwizora po komponenty przestrzeni użytkownika.

Poufność i integralność

Poufność wynika z właściwości izolacji pamięci wymuszonych przez hiperwizor pKVM. pKVM śledzi własność pamięci poszczególnych stron pamięci fizycznej i wszelkie żądania właścicieli dotyczące udostępniania stron. pKVM zapewnia, że ​​tylko uprawnione pVM (host i goście) mają zmapowaną daną stronę w swoich tabelach stron etapu 2, które są kontrolowane przez hipernadzorcę. Ta architektura utrzymuje, że zawartość pamięci należąca do pVM pozostaje prywatna, chyba że właściciel jawnie udostępnia ją innej pVM.

Ograniczenia dotyczące zachowania poufności obejmują również wszelkie jednostki w systemie, które wykonują dostęp do pamięci w imieniu pVM, a mianowicie urządzenia i usługi obsługujące DMA działające w bardziej uprzywilejowanych warstwach . Dostawcy SoC muszą spełnić nowy zestaw wymagań, zanim będą mogli obsługiwać pKVM, w przeciwnym razie nie można zapewnić poufności.

Integralność dotyczy zarówno danych w pamięci, jak i obliczeń:

  • pVM nie mogą wzajemnie modyfikować pamięci bez zgody.
  • pVM nie mogą wpływać na stan procesora nawzajem.

Te wymagania są wymuszane przez hipernadzorcę. Ale problemy dotyczące integralności danych pojawiają się również w przypadku wirtualnego przechowywania danych, gdzie należy zastosować inne rozwiązania, takie jak dm-verity lub AuthFS.

Zasady te nie różnią się od izolacji procesów oferowanej przez Linuksa, w której dostęp do stron pamięci jest kontrolowany za pomocą tabel stron etapu 1 i przełączników kontekstu jądra między procesami. Jednak część EL2 pKVM, która wymusza te właściwości, ma mniej więcej połowę powierzchni ataku w porównaniu z całym jądrem Linuksa (około 10 tys. w sprawie izolacji procesu.

Biorąc pod uwagę jego rozmiar, pKVM nadaje się do formalnej weryfikacji. Aktywnie wspieramy badania akademickie, których celem jest formalne udowodnienie tych właściwości na rzeczywistym pliku binarnym pKVM.

Pozostała część tego dokumentu obejmuje gwarancje poufności i integralności, jakie zapewnia każdy komponent wokół pKVM.

Nadzorca

pKVM to hiperwizor oparty na KVM, który izoluje pVM i Androida we wzajemnie niezaufanych środowiskach wykonawczych. Te właściwości zachowują się w przypadku naruszenia bezpieczeństwa w dowolnej pVM, w tym na hoście. Alternatywne hipernadzorcy zgodne z AVF muszą zapewniać podobne właściwości.

  • PVM nie może uzyskać dostępu do strony należącej do innej jednostki, takiej jak pVM lub hipernadzorca, chyba że jest to jawnie udostępnione przez właściciela strony. Ta reguła obejmuje hosta pVM i dotyczy zarówno dostępu do procesora, jak i DMA.
  • Zanim strona używana przez pVM zostanie zwrócona do hosta, na przykład gdy pVM zostanie zniszczona, zostanie wyczyszczona.
  • Pamięć wszystkich maszyn pVM i oprogramowania układowego pVM z jednego rozruchu urządzenia jest czyszczona przed uruchomieniem bootloadera systemu operacyjnego w kolejnym rozruchu urządzenia.
  • Gdy dołączony jest sprzętowy debugger, taki jak SJTAG, pVM nie może uzyskać dostępu do swoich wcześniej wybitych kluczy.
  • Oprogramowanie układowe pVM nie uruchamia się, jeśli nie może zweryfikować obrazu początkowego.
  • Oprogramowanie układowe pVM nie uruchamia się, jeśli zostanie naruszona integralność pliku instance.img .
  • Łańcuch certyfikatów rozruchowych (BCC) i złożone identyfikatory urządzeń (CDI) dostarczone do wystąpienia pVM mogą być wyprowadzone tylko przez to konkretne wystąpienie.

System operacyjny gościa

Microdroid to przykład systemu operacyjnego działającego w ramach pVM. Microdroid składa się z bootloadera opartego na U-boot, GKI i podzbioru przestrzeni użytkownika Androida oraz programu uruchamiającego ładunek. Te właściwości zachowują się w przypadku naruszenia bezpieczeństwa w dowolnej pVM, w tym na hoście. Alternatywne systemy operacyjne działające w pVM powinny zapewniać podobne właściwości.

  • Microdroid nie uruchomi się, jeśli nie można zweryfikować vbmeta.img boot.img super.img vbmeta\_system.img .
  • Microdroid nie uruchomi się, jeśli weryfikacja APK nie powiedzie się.
  • Ta sama instancja Microdroid nie uruchomi się, nawet jeśli plik APK został zaktualizowany.
  • Microdroid nie uruchomi się, jeśli którykolwiek z APEX-ów nie przejdzie weryfikacji.
  • Microdroid nie uruchomi się (lub nie uruchomi się z czystym stanem początkowym), jeśli plik instance.img zostanie zmodyfikowany poza pVM gościa.
  • Microdroid zapewnia atest łańcucha rozruchowego.
  • Każda (niepodpisana) modyfikacja obrazów dysków udostępnionych gościowi pVM powoduje błąd we/wy po stronie pVM.
  • BCC i CDI dostarczone do instancji pVM mogą być wyprowadzone tylko przez tę konkretną instancję.

Android

Oto właściwości utrzymywane przez Androida jako hosta, ale nie są one prawdziwe w przypadku włamania do hosta:

  • PVM gościa nie może bezpośrednio wchodzić w interakcję z (na przykład nawiązać połączenie vsock) z innymi maszynami pVM gościa.
  • Tylko VirtualizationService w hosta pVM może utworzyć kanał komunikacyjny do pVM (Uwaga: może przekazać ustanowiony kanał innym).
  • Tylko aplikacje podpisane za pomocą klucza platformy mogą żądać uprawnień do tworzenia, posiadania lub interakcji z pVM.
  • Identyfikator, zwany identyfikatorem kontekstu (CID) , używany do konfigurowania połączeń vsock między hostem a pVM, nie jest ponownie używany, gdy host pVM jest uruchomiony. Na przykład zastąpienie działającej pVM innym nie jest możliwe.

Dostępność

W kontekście maszyn wirtualnych dostępność odnosi się do hosta przydzielającego wystarczające zasoby gościom, aby goście mogli wykonywać zadania, do których zostały zaprojektowane.

Do obowiązków hosta należy planowanie wirtualnych procesorów pVM. KVM, w przeciwieństwie do tradycyjnych hipernadzorców typu 1, takich jak Xen, podejmuje jednoznaczną decyzję projektową o delegowaniu planowania obciążenia do jądra hosta. Biorąc pod uwagę rozmiar i złożoność dzisiejszych programów planujących, ta decyzja projektowa znacznie zmniejsza rozmiar zaufanej bazy obliczeniowej (TCB) i umożliwia hostowi podejmowanie bardziej świadomych decyzji dotyczących planowania w celu optymalizacji wydajności. Jednak złośliwy host może zdecydować, że nigdy nie planuje gościa.

Podobnie, pKVM deleguje również obsługę przerwań fizycznych do jądra hosta, aby zmniejszyć złożoność hipernadzorcy i pozostawić hostowi za planowanie. Podejmowane są wysiłki, aby zapewnić, że przekazywanie przerwań gościa skutkuje tylko odmową usługi (za mało, za dużo lub błędnie przekierowywanych przerwań).

Wreszcie proces monitora maszyny wirtualnej (VMM) hosta odpowiada za przydzielanie pamięci i udostępnianie urządzeń wirtualnych, takich jak karta sieciowa. Złośliwy program VMM może blokować zasoby gościowi.

Chociaż pKVM nie zapewnia dostępności dla gości, projekt chroni dostępność hosta przed złośliwymi gośćmi, ponieważ host może zawsze zapobiegać lub zakończyć gościa i odzyskać jego zasoby.

Bezpieczny rozruch

Dane są powiązane z instancjami pVM, a bezpieczny rozruch zapewnia kontrolę dostępu do danych instancji. Pierwsze uruchomienie instancji zapewnia ją poprzez losowe wygenerowanie tajnej soli dla pVM i wyodrębnienie szczegółów, takich jak weryfikacyjne klucze publiczne i skróty, z załadowanych obrazów. Te informacje są używane do weryfikacji kolejnych rozruchów wystąpienia pVM i upewnienia się, że klucze tajne wystąpienia są udostępniane tylko do obrazów, które przejdą weryfikację. Ten proces występuje na każdym etapie ładowania w pVM: oprogramowanie układowe pVM, pVM ABL, Microdroid i tak dalej.

DICE zapewnia każdemu etapowi ładowania parę kluczy atestacyjnych, których część publiczna jest certyfikowana we wpisie BCC dla tego etapu. Ta para kluczy może się zmieniać między rozruchami, więc wyprowadzany jest również tajny klucz uszczelniający , który jest stabilny dla instancji maszyny wirtualnej podczas ponownych rozruchów i jako taki nadaje się do ochrony trwałego stanu. Sekret pieczętowania jest bardzo cenny dla maszyny wirtualnej, więc nie powinien być używany bezpośrednio. Zamiast tego klucze pieczętowania powinny pochodzić z tajemnicy pieczętowania, a tajemnica pieczętowania powinna zostać zniszczona tak szybko, jak to możliwe.

Każdy etap przekazuje deterministycznie zakodowany obiekt CBOR do następnego etapu. Ten obiekt zawiera wpisy tajne i BCC, które zawierają skumulowane informacje o stanie, takie jak to, czy ostatni etap został załadowany bezpiecznie.

Odblokowane urządzenia

Gdy urządzenie zostanie odblokowane za pomocą fastboot oem unlock , dane użytkownika zostaną wyczyszczone. Proces ten chroni dane użytkownika przed nieautoryzowanym dostępem. Dane, które są prywatne dla pVM, są również unieważniane po odblokowaniu urządzenia.

Po odblokowaniu właściciel urządzenia może przeflashować partycje, które są zwykle chronione przez zweryfikowany rozruch, w tym partycje zawierające implementację pKVM. W związku z tym pKVM na odblokowanym urządzeniu nie będzie zaufany w zakresie utrzymania modelu zabezpieczeń.

Strony zdalne mogą obserwować ten potencjalnie niebezpieczny stan, sprawdzając zweryfikowany stan rozruchu urządzenia w certyfikacie atestacji klucza.