AVF を使用する理由

モバイル コンピューティング デバイスが処理する個人の機密データはますます増加しています。加えてこうした機密データは外界と絶え間なくやり取りされるため、脆弱性を悪用して目的を遂げようと図る悪意のある行為者が投資を増やす事態を招いています。

オペレーティング システムは、ハードウェア メモリ管理ユニット（MMU）の助けを借りて、相互に関連のないプロセスを分離するための抽象化を提供します。このような MMU を直接プログラミングできるのは、トラステッド コンピューティング ベース（TCB）に属するコンポーネントだけです。

このモデルは、Unix 系オペレーティング システムの登場以来、プライバシーとセキュリティの実装方法の基礎となってきました。しかし、最近の TCB が大きすぎることから、この要件は問題を生じさせています。この問題には、ほとんどのデバイスとバスのドライバ、複雑なスケジューラ、ファイル システム、ネットワークのスタックとプロトコル、キャッシュ、実行可能なパーサーとローダ、ソケットが関係しています。この複雑化したシステムのあらゆる部分の安全性を確保することは、非常に困難になっています。

Linux カーネルには 2,000 万行を超えるコードがあり、驚異的なペースで変更と書き換えが行われています。この成長は、Android と Google のエコシステムにとって大きな助けになっています。一方で、TCB が大きいため、悪用可能な脆弱性がないことを保証するのは困難になります。

ハードウェア ベンダーは、プロセッサをセキュアモードで実行し、メモリ トランザクションに「セキュア」または「非セキュア」というタグを付けられるソリューション（Arm の TrustZone など）を開発してきました。このようなシステムでは、機密データはセキュア環境に保存され、セキュア環境でのみ直接使用できます。非セキュア環境には、オンデマンドでサービスが提供されます。

この種のソリューションの主な制限は、ドメインの分類が大まかすぎる（セキュアと非セキュアしかない）ことです。オペレーティング システムからの分離が必要なユースケースが増加すると、攻撃対象領域が拡大し、脆弱性がデバイス全体の侵害を招くおそれがあります。

今日のソリューションの別の制限は、それらが比較的静的な環境向けに設計されていることです。静的な環境では、すべてのユースケース リソースが事前に考慮されて割り当てられます。このようなソリューションは、リソースがオンデマンドで割り当てられる動的なユースケースでは十分に機能しません。

さらに、Android オペレーティング システムの外部で使用される API は断片化しており、Android の規模のユースケース（Keymint や Gatekeeper のような基本的なケースを含む）をデプロイする Google の能力に制限を課しています。

これらの制限に対処し、Android が次世代のユースケース用に強固な基盤を提供できるようにするため、Android 13 ではセキュアな仮想化の仕組みとして Android 仮想化フレームワーク（AVF）を導入しました。

AVF の主な目標は、次世代のユースケース用にセキュアでプライベートな実行環境を提供することです。