Microdroid to mini-system operacyjny Android, który działa w pVM. Nie musisz używać Microdroid, możesz uruchomić maszynę wirtualną z dowolnym systemem operacyjnym. Jednak główne przypadki użycia dotyczące maszyn wirtualnych nie wymagają uruchamiania samodzielnego systemu operacyjnego, a raczej oferują odizolowane środowisko wykonywania części aplikacji z silniejszymi gwarancjami poufności i integralności niż te, które zapewnia Android.
W przypadku tradycyjnych systemów operacyjnych zapewnienie wysokiego poziomu poufności i integralności wymaga sporo pracy (często powtarzającej się), ponieważ tradycyjne systemy operacyjne nie pasują do ogólnej architektury Androida. Na przykład w przypadku standardowej architektury Androida deweloperzy muszą wdrożyć sposób bezpiecznego wczytywania i wykonywania części aplikacji w pVM, a dane są tworzone w oparciu o glibc. Aplikacja na Androida korzysta z Bionic, komunikacja wymaga niestandardowego protokołu przez vsock, a debugowanie za pomocą adb jest trudne.
Microdroid wypełnia te luki, udostępniając gotowy obraz systemu operacyjnego, który wymaga od deweloperów jak najmniejszego wysiłku, aby przekazać część aplikacji do pVM. Kod natywny jest tworzony na podstawie Bionic, komunikacja odbywa się za pomocą Bindera, a interfejs umożliwia importowanie APEX-ów z hosta Androida i wyświetla podzbiór interfejsu API Androida, np. repozytorium kluczy do operacji kryptograficznych z kluczami obsługiwanymi przez sprzęt. Deweloperzy powinni uznać Microdroid za znajome środowisko z narzędziami, do których przywykli w ramach pełnego systemu operacyjnego Android.
Funkcje
Microdroid to okrojona wersja Androida z kilkoma dodatkowymi komponentami przeznaczonymi do pVM. Microdroid obsługuje:
- Podzbiór interfejsów NDK (dostępne są wszystkie interfejsy API implementacji libc i Bionic na Androidzie).
- Funkcje debugowania, takie jak adb, logcat, tombstone i gd.
- Weryfikacja podczas uruchamiania i SELinux
- wczytywanie i wykonywanie binarnych plików z bibliotekami udostępnionymi zawartymi w pliku APK.
- Binder RPC przez vsock i wymiana plików z niejawnymi weryfikacjami integralności
- Wczytywanie APEX-ów
Microdroid nie obsługuje:
interfejsy API na Androida w Javie w pakietach
android.\*;SystemServer i Zygote
Grafika/UI
HAL
Architektura mikrodrodu
Microdroid jest podobny do Cuttlefish, ponieważ oba mają architekturę podobną do standardowego Androida. Microdroid składa się z tych partycji: obrazów zgrupowanych w obraz dyskowy:
bootloader– weryfikuje i uruchamia jądro.boot.img– zawiera jądro i ramdisk init.vendor_boot.img– zawiera moduły jądra dotyczące maszyn wirtualnych, takie jak virtio.super.img– składa się z partycji systemowych i partycji dostawców.vbmeta.img– zawiera metadane weryfikacji podczas uruchamiania.
Obrazy partycji są dostarczane w ramach pakietu Virtualization APEX i są zapakowane w obraz złożonego dysku VirtualizationService. Oprócz głównego obrazu dysku dyskowego z kompozytem systemu operacyjnego VirtualizationService odpowiada za tworzenie tych partycji:
payload– zbiór partycji obsługiwanych przez pliki APEX i pliki APK na Androida;instance– zaszyfrowana partycja do przechowywania danych weryfikacji podczas uruchamiania na poziomie instancji, takich jak sól na poziomie instancji, zaufane klucze publiczne APEX i liczniki cofania
Sekwencja uruchamiania
Sekwencja uruchamiania Microdroid występuje po uruchamianiu urządzenia. Uruchamianie urządzenia jest omawiane w sekcji dotyczącej oprogramowania układowego pVM w dokumencie Architektura. Rysunek 1 przedstawia kroki wykonywane podczas sekwencji uruchamiania Microdroida:
Oto wyjaśnienie tych kroków:
Program rozruchowy jest ładowany do pamięci przez crosvm, a pvmfw zaczyna się wykonywać. Zanim przejdziesz do bootloadera, pvmfw wykona 2 czynności:
- Sprawdza program rozruchowy, aby sprawdzić, czy pochodzi z zaufanego źródła (Google lub producenta OEM).
- Zapewnienie spójnego stosowania tego samego bootloadera podczas wielokrotnego uruchamiania tego samego pVM za pomocą obrazu instancji. W szczególności pVM jest początkowo uruchamiany z pustym obrazem instancji. pvmfw przechowuje tożsamość bootloadera w obrazie instancji i szyfruje go. Gdy następnym razem uruchomisz maszynę wirtualną z tym samym obrazem instancji, pvmfw odszyfruje zapisaną tożsamość z obrazu instancji i sprawdzi, czy jest to ta sama tożsamość, która została zapisana wcześniej. Jeśli tożsamości się różnią, pvmfw nie uruchamia się.
Następnie program rozruchowy uruchamia Microdroida.
Program rozruchowy uzyskuje dostęp do dysku instancji. Podobnie jak w przypadku pvmfw, bootloader ma dysk instancji z informacjami o obrazach partycji używanych w tej instancji podczas poprzednich rozruchów, w tym klucz publiczny.
Program rozruchowy weryfikuje vbmeta i połączone partycje, takie jak
bootisuper, a jeśli wszystko się powiedzie, wyprowadza sekrety pVM następnego etapu. Następnie Microdroid przekazuje kontrolę nad systemem jądra.Super partycja została już zweryfikowana przez program ładujący (krok 3), więc jądro bezwarunkowo ją montuje. Podobnie jak w przypadku pełnego Androida, super partycja składa się z kilku partycji logicznych zamontowanych na dm-verity. Następnie kontrola jest przekazywana procesowi
init, który uruchamia różne natywne usługi. Skryptinit.rcjest podobny do skryptu pełnego Androida, ale dostosowany do potrzeb Microdroida.Proces
inituruchamia menedżera Microdroid, który uzyskuje dostęp do obrazu instancji. Usługa menedżera Microdroida odszyfrowuje obraz za pomocą klucza przekazanego z poprzedniego etapu i odczytuje klucze publiczne oraz liczniki cofania zmian pliku APK klienta i APEX-ów, którym ufa ta pVM. Te informacje są później używane przezzipfuseiapexdpodczas montowania pliku APK klienta i żądanych APEX-ów.Usługa menedżera Microdroid rozpoczyna się
apexd.apexdmontuje APEX-y w katalogach/apex/<name>. Jedyną różnicą między sposobem montowania plików APEX przez Androida i Microdroida jest to, że w Microdroidzie pliki APEX pochodzą z wirtualnych urządzeń blokowych (/dev/vdc1, itp.), a nie z zwykłych plików (/system/apex/*.apex).zipfuseto system plików FUSE Microdroida.zipfusemontuje pakiet APK klienta, który jest w podstawie plikiem Zip jako system plików. Poniżej plik APK jest przekazywany jako urządzenie blokowe przez pVM z dm-verity, tak samo jak APEX. Plik APK zawiera plik konfiguracji z listą APEX, które zostały zażądane przez dewelopera aplikacji w przypadku tego wystąpienia pVM. Lista jest używana przezapexdpodczas aktywowania Apexów.Proces uruchamiania wraca do usługi menedżera Microdroid. Następnie usługa menedżera komunikuje się z
VirtualizationServiceAndroida za pomocą Bindera RPC, aby zgłaszać ważne zdarzenia, takie jak awaria czy wyłączenie, oraz akceptować żądania, takie jak zakończenie procesu pVM. Usługa menedżera odczytuje lokalizację głównego binarnego pliku z pliku konfiguracyjnego APK i go wykona.
Wymiana plików (AuthFS)
Komponenty Androida często używają plików do odczytu, zapisu i przechowywania stanu, a także do przekazywania ich jako deskryptorów plików (ParcelFileDescriptor typ w AIDL), do których dostęp jest kontrolowany przez jądro Androida. AuthFS umożliwia podobną funkcjonalność do wymiany plików między wzajemnie nieufnymi punktami końcowymi w obrębie granic pVM.
AuthFS to przede wszystkim zdalny system plików z przezroczystymi weryfikacjami integralności w przypadku poszczególnych operacji dostępu, podobny do fs-verity. Dzięki tym kontrolom interfejs, np. program do odczytu plików działający w pVM, może wykryć, czy nieufny backend, zwykle Android, nie zmanipulował treści pliku.
Aby wymieniać pliki, backend (fd\_server) jest uruchamiany z konfiguracją na poziomie pliku, która określa, czy jest to wejście (tylko do odczytu) czy wyjście (do odczytu i zapisu). W przypadku danych wejściowych interfejs wymusza, aby zawartość pasowała do znanego hasha na podstawie drzewa Merkle na potrzeby weryfikacji dostępu. W przypadku danych wyjściowych AuthFS wewnętrznie utrzymuje drzewo haszowania treści, które jest obserwowane podczas operacji zapisu, i może wymuszać integralność podczas odczytu danych.
Podstawowy transport jest obecnie oparty na protokole Binder RPC, ale w przyszłości może się to zmienić ze względu na optymalizację skuteczności.
Zarządzanie kluczami
Urządzenia pVM są dostarczane ze stabilnym kluczem pieczętującym, który służy do ochrony danych trwałych, oraz kluczem uwierzytelniającym, który służy do generowania podpisów, które można zweryfikować za pomocą urządzenia pVM.
Binder RPC
Większość interfejsów Androida jest wyrażana w języku AIDL, który jest oparty na jądrowym sterowniku Bindera. Aby obsługiwać interfejsy między pVM, protokół Binder został przepisany tak, aby działał przez gniazda vsock w przypadku pVM. Praca w gniazdach umożliwia korzystanie w tym nowym środowisku z dotychczasowych interfejsów AIDL Androida.
Aby skonfigurować połączenie, jeden punkt końcowy, np. ładunek pVM, tworzy obiekt RpcServer, rejestruje obiekt rdzeniowy i zaczyna nasłuchiwać nowych połączeń. Klienci mogą połączyć się z tym serwerem za pomocą obiektu RpcSession, uzyskać obiekt Binder i używać go dokładnie tak samo jak obiekt Binder z sterownikiem Binder jądra.