Microdroid

Microdroid 是執行在 pVM 中的迷你 Android 作業系統。您不必使用 Microdroid，也可以使用任何作業系統啟動 VM。不過，pVM 的主要用途並非執行獨立的作業系統，而是提供隔離的執行環境，用於執行應用程式的部分內容，並提供比 Android 更強的機密性和完整性保證。

傳統的作業系統不符合整體的 Android 架構，因此需要大量複製工作，才能提供強大的機密性和完整性。舉例來說，在標準 Android 架構中，開發人員需要實作一種方法，以便在 pVM 中安全地載入及執行部分應用程式，而酬載則是根據 glibc 建構。Android 應用程式使用 Bionic，因此需要透過 VSock 使用自訂通訊協定，而使用 ADB 偵錯並不容易。

為填補這些缺口，Microdroid 藉由提供現成的 OS 映像檔，讓開發人員以最輕鬆的方式將部分應用程式卸載至 pVM。原生程式碼是以 Bionic 建構而成，透過 Binder 進行通訊，且可從主機 Android 匯入 APEX，並公開 Android API 的子集，例如透過 KeyStore 使用硬體支援金鑰執行加密編譯作業。總體而言，開發人員應該會發現 Microdroid 是熟悉的環境，因為其中提供的工具與他們在完整 Android 作業系統中使用的工具相同。

功能

Microdroid 是精簡版 Android，其中包含一些專屬於 pVM 的額外元件。Microdroid 支援：

  • NDK API 的子集 (提供用於 Android 實作 libc 和 Bionic 的所有 API)
  • 偵錯功能，例如 adb、logcat、tombstone 和 gdb
  • 驗證開機程序和 SELinux
  • 載入及執行嵌入 APK 的二進位檔和共用程式庫
  • 透過 vsock 進行 Binder RPC，並透過隱含完整性檢查交換檔案
  • 載入 APEX

Microdroid 不支援以下項目：

  • android.\* 套件中的 Android Java API

  • SystemServer 和 Zygote

  • 圖像/使用者介面

  • HAL

Microdroid 架構

Microdroid 與 Cuttlefish 相似，兩者都具有與標準 Android 相似的架構。Microdroid 包含下列分區映像檔，這些映像檔會在複合磁碟映像檔中分組：

  • bootloader：驗證並啟動核心。
  • boot.img：包含核心和初始化 RAM 磁碟。
  • vendor_boot.img：包含特定 VM 的核心模組，例如 virtio。
  • super.img - 包含系統和供應商邏輯磁碟區。
  • vbmeta.img：包含驗證開機程序中繼資料。

分割區映像檔會在 Virtualization APEX 中出貨，並由 VirtualizationService 封裝為複合磁碟映像檔。除了主要 OS 複合磁碟映像檔外，VirtualizationService 也負責建立下列其他分區：

  • payload - 由 Android 的 APEX 和 APK 支援的一組分割區
  • instance：用於保存每個執行個體已驗證的啟動資料 (例如每個執行個體的鹽值、信任的 APEX 公開金鑰和復原計數器) 的加密分割區

開機順序

Microdroid 啟動序列會在裝置啟動後發生。請參閱「架構」文件中的 pVM 韌體一節，瞭解裝置啟動程序。圖 1 顯示 Microdroid 啟動序列期間的步驟：

MicroDroid 執行個體的安全啟動流程

圖 1. MicroDroid 例項的安全啟動流程

以下說明這些步驟：

  1. 系統會透過 crosvm 將引導程式載入記憶體，並開始執行 pvmfw。在跳轉至啟動載入程式之前，pvmfw 會執行兩項工作：

    • 驗證啟動載入器，檢查是否來自可信任的來源 (Google 或 OEM)。
    • 透過使用執行個體映像檔，確保在同一個 pVM 的多個啟動作業中，一律使用相同的啟動載入程式。具體來說，pVM 最初會使用空白的執行個體映像檔啟動。pvmfw 會在執行個體映像檔中儲存啟動載入程式的身分，並對其進行加密。因此，下次以相同執行個體映像檔啟動 pVM 時，pvmfw 會從執行個體映像檔解密已儲存的 ID，並驗證該 ID 是否與先前儲存的 ID 相同。如果身分不同，pvmfw 就會拒絕啟動。

    接著，系統啟動載入程式會啟動 Microdroid。

  2. 開機載入程式會存取執行個體磁碟。與 pvmfw 類似，系統啟動載入程式具有一個執行個體磁碟機，其中包含此執行個體先前啟動期間使用的分區映像檔相關資訊，包括公開金鑰。

  3. 啟動載入程式會驗證 vbmeta 和鏈結分區 (例如 boot 和 super)，如果驗證成功，就會衍生下階段的 pVM 機密資料。接著，Microdroid 會將控制權交給核心。

  4. 由於超級分區已由引導程式驗證 (步驟 3)，核心會無條件掛載超級分區。和完整的 Android 一樣，超分區是由多個在 dm-verity 掛接的邏輯分區組成。接著，控制權會傳遞至 init 程序，啟動各種原生服務。init.rc 指令碼與完整 Android 指令碼類似，但會根據 Microdroid 的需求進行調整。

  5. init 程序會啟動 Microdroid 管理工具，以便存取例項映像檔。Microdroid 管理員服務會使用從前一個階段傳遞的金鑰解密映像檔，並讀取這個 pVM 信任的用戶端 APK 和 APEX 的公開金鑰和復原計數器。zipfuse 和 apexd 分別掛載用戶端 APK 和要求的 APEX 時，會在稍後使用這項資訊。

  6. Microdroid 管理員服務會啟動 apexd。

  7. apexd 會在 /apex/<name> 目錄中掛接 APEX。Android 和 Microdroid 掛接 APEX 唯一的差別在於，在 Microdroid 中，APEX 檔案來自虛擬區塊裝置 (/dev/vdc1 ...)，而不是一般檔案 (/system/apex/*.apex)。

  8. zipfuse 是 Microdroid 的 FUSE 檔案系統。zipfuse 會掛接用戶端 APK，而 APK 本質上是做為檔案系統的 ZIP 檔案。在底下，APK 檔案會以虛擬區塊裝置的形式，由使用 dm-verity 的 pVM 傳遞，這與 APEX 相同。APK 包含設定檔，其中列出應用程式開發人員為此 pVM 例項要求的 APEX 清單。apexd 會在啟用 APEX 時使用這份清單。

  9. 啟動流程會傳回至 Microdroid 管理員服務。接著，管理員服務會使用 Binder RPC 與 Android 的 VirtualizationService 通訊，以便回報當機或關閉等重要事件，以及接受終止 pVM 等要求。管理服務會從 APK 的設定檔讀取主要二進位檔的位置，然後執行該檔案。

檔案交換 (AuthFS)

Android 元件通常會使用檔案做為輸入、輸出和狀態，並將這些檔案傳遞為檔案描述項 (AIDL 中的 ParcelFileDescriptor 類型)，並由 Android 核心控制存取權。AuthFS 有利於在 pVM 邊界間交換互不信任端點之間的檔案。

從根本上來說，AuthFS 是遠端檔案系統，可針對個別存取作業執行透明完整性檢查，類似於 fs-verity。這些檢查可讓前端 (例如在 pVM 中執行的檔案讀取程式) 偵測不受信任的後端 (通常是 Android) 是否竄改檔案內容。

如要交換檔案，後端 (fd\_server) 會啟動每個檔案設定，指定檔案是用於輸入 (唯讀) 還是輸出 (讀寫)。對輸入而言，前端會強制要求內容與 Merkle 樹上方的已知雜湊相符，以進行存取驗證。就輸出而言，AuthFS 會在內部維護從寫入作業觀察到的內容雜湊樹狀結構，並在資料讀取回條時強制執行完整性。

基礎傳輸目前以 Binder RPC 為基礎，但未來可能會改變以改善效能。

金鑰管理

pVM 會提供穩定的封印金鑰，可用於保護持續性資料，以及認證金鑰，可用於產生可由 pVM 驗證的簽章。

Binder RPC

大多數 Android 介面都是以 AIDL 表示，而 AIDL 是建構在 Binder Linux 核心驅動程式之上。為了支援 pVM 之間的介面，Binder 通訊協定已重寫，以便透過通訊端 (例如 pVM) 使用 vsock。透過 Socket 運作可讓 Android 現有的 AIDL 介面在這個新環境中使用。

如要設定連線，一個端點 (例如 pVM 酬載) 會建立 RpcServer 物件、註冊根物件，並開始監聽新的連線。用戶端可以使用 RpcSession 物件連線至此伺服器，取得 Binder 物件，然後如同使用核心繫結器驅動程式中的 Binder 物件一樣使用。