Microdroid

Microdroid は pVM で動作する小型の Android OS です。Microdroid を使用する必要はなく、VM は任意の OS で起動できます。しかし、pVM の主なユースケースはスタンドアロン OS を実行することではなく、Android が提供するよりも優れた機密性と整合性が確保された、アプリの一部を実行するための分離された実行環境を提供することです。

従来のオペレーティング システムでは、優れた機密性と整合性を確保するためにかなりの作業が必要になります（多くの場合、重複します）。なぜなら、従来型オペレーティング システムは包括的な Android アーキテクチャに適していないためです。たとえば、標準の Android アーキテクチャでは、デベロッパーはアプリの一部を pVM で安全に読み込んで実行する手段を実装する必要があり、ペイロードは glibc に対してビルドされます。Android アプリは Bionic を使用し、通信には vsock にカスタム プロトコルが必要で、adb を使用してデバッグするのは困難です。

Microdroid は、こうしたギャップを埋めるために、デベロッパーがアプリの一部を pVM にオフロードするための最小労力で設計された既製の OS イメージを提供しています。ネイティブ コードは Bionic に対してビルドされ、Binder で通信が行われます。また、ホストの Android から APEX をインポートし、ハードウェア格納型鍵を使用する暗号オペレーションのキーストアなど、Android API のサブセットを公開できます。全体的に、デベロッパーにとって Microdroid は完全な Android OS と似通った環境のツールであると言えます。

機能

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

  • グラフィック / UI

  • HAL

Microdroid アーキテクチャ

Microdroid は Cuttlefish と類似しており、どちらも標準の Android に似たアーキテクチャを備えています。Microdroid は、以下のパーティション イメージから構成され、複合ディスク イメージにグループ化されています。

  • bootloader - カーネルを検証して起動します。
  • boot.img - カーネルと init RAM ディスクが含まれます。
  • vendor_boot.img - virtio などの VM 固有のカーネル モジュールが含まれます。
  • super.img - システムとベンダーの論理パーティションで構成されます。
  • vbmeta.img - 確認付きブートのメタデータが含まれます。

パーティション イメージは Virtualization APEX で提供され、VirtualizationService によって複合ディスク イメージにパッケージ化されます。VirtualizationService は、メインの OS 複合ディスク イメージだけでなく、次のパーティションも作成します。

  • payload - Android の APEX と APK に基づくパーティションのセット
  • instance - インスタンスごとのソルト、信頼できる APEX 公開鍵、ロールバック カウンタなど、インスタンスごとの確認付きブートデータを保持するための暗号化されたパーティション

起動シーケンス

Microdroid の起動シーケンスは、デバイスの起動の後に行われます。デバイスの起動については、アーキテクチャのドキュメントの pVM ファームウェア セクションをご覧ください。図 1 は、Microdroid の起動シーケンスで発生する手順を示しています。

microdroid インスタンスの安全なブートフロー

図 1. microdroid インスタンスの安全なブートフロー

以下に手順を説明します。

  1. ブートローダーが crosvm によってメモリに読み込まれ、pvmfw が実行を開始します。pvmfw は、ブートローダーにアクセスする前に次の 2 つのタスクを実行します。

    • ブートローダーが信頼できるソース（Google または OEM）からのものかどうかを確認します。
    • インスタンス イメージを使用して、同じ pVM の複数回のブートにわたって同じブートローダーを一貫して使用するようにします。具体的には、pVM は最初に空のインスタンス イメージで起動します。pvmfw は、ブートローダーの ID をインスタンス イメージに格納し、暗号化します。このため、次回同じインスタンス イメージを使用して 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 を /apex/<name> ディレクトリにマウントします。Android と Microdroid による APEX のマウントの唯一の違いは、Microdroid では APEX ファイルが通常のファイル（/system/apex/*.apex）ではなく、仮想ブロック デバイス（/dev/vdc1, …）から取得される点です。

  8. zipfuse は Microdroid の FUSE ファイル システムです。zipfuse は、基本的には ZIP ファイルをファイル システムとするクライアント APK をマウントします。この APK ファイルは、APEX と同様、dm-verity を使用した pVM によって仮想ブロック デバイスとして渡されます。この APK には、アプリ デベロッパーがこの pVM インスタンスについてリクエストした APEX のリストを含む構成ファイルが含まれています。このリストは、APEX を有効にするときに apexd によって使用されます。

  9. 起動フローは Microdroid マネージャー サービスに戻ります。マネージャー サービスは、Binder RPC を使用して Android の VirtualizationService と通信し、クラッシュやシャットダウンなどの重要なイベントをレポートしたり、pVM の終了などのリクエストを承認したりできるようにします。マネージャー サービスが APK の構成ファイルからメインバイナリの場所を読み取って実行します。

ファイル交換（AuthFS）

Android コンポーネントでは、入力、出力、状態のファイルを使用し、これらをファイル記述子（AIDL では ParcelFileDescriptor 型）として渡し、Android カーネルでアクセスを制御するのが一般的です。AuthFS を使用すると、pVM の境界を越えて相互に信頼していないエンドポイント間でファイルを交換する際に、同様の機能を実現できます。

基本的に、AuthFS はリモート ファイル システムで fs-verity と同様に、個々のアクセス オペレーションの透明性の高い整合性チェックを行います。このチェックにより、pVM で実行されるファイル読み取りプログラムなどのフロントエンドは、信頼できないバックエンド（通常は Android）がファイルの内容を改ざんしたかどうかを検出できます。

ファイルを交換するために、バックエンド（fd\_server）は入力用（読み取り専用）か出力用（読み取りと書き込み）かを指定するファイルごとの構成で開始されます。入力の場合、アクセス時の検証用のマークルツリーに加え、フロントエンドはコンテンツを既知のハッシュと一致させます。出力の場合、AuthFS は書き込みオペレーションから観測されたコンテンツのハッシュツリーを内部的に維持し、データが読み取られるときに整合性を適用します。

基盤となるトランスポートは現在 Binder RPC に基づいていますが、将来的にはパフォーマンスを最適化するために変更される可能性があります。

鍵の管理

pVM は、保護対象の永続データに適している安定したシーリングキーや、pVM によって検証可能な方法で生成された署名を生成するのに適している証明書鍵によって提供されます。

Binder リモート プロシージャ コール

Android のインターフェースの大部分は AIDL で表現されており、Binder Linux カーネル ドライバ上に構築されています。pVM 間のインターフェースをサポートするため、Binder プロトコルは、ソケット（vsock、pVM の場合）で動作するように書き換えられました。ソケットを介して操作すると、Android の既存の AIDL インターフェースをこの新しい環境で使用できます。

接続を設定するために、pVM ペイロードなどの 1 つのエンドポイントが RpcServer オブジェクトを作成し、ルート オブジェクトを登録して、新しい接続をリッスンします。クライアントは、RpcSession オブジェクトを使用してこのサーバーに接続し、Binder オブジェクトを取得します。カーネル Binder ドライバで Binder オブジェクトを使用する場合と同じように使用できます。