為了防止在 pVM 內運行任意負載,Android 虛擬化框架 (AVF) 使用分層安全方法,其中每一層都添加了額外的強制措施。以下是 AVF 安全層列表:
Android – Android 確保僅允許具有 pVM 權限的應用程序創建或檢查 pVM。
引導加載程序——引導加載程序確保僅允許由 Google 或設備供應商簽名的 pVM 映像引導並遵守Android 驗證引導程序。這種架構意味著運行 pVM 的應用程序不能捆綁自己的內核。
pVM – pVM 為在 pVM 中運行的有效負載提供深度防禦,例如SELinux 。縱深防禦不允許將映射數據作為可執行文件 (
neverallow execmem
) 並確保W^X適用於所有文件類型。
安全模型
機密性、完整性和可用性,也稱為 CIA 三元組,是一種旨在指導信息安全策略的模型:
- 機密性是一組限制信息訪問的規則。
- 完整性是信息可信和準確的保證。
- 可用性是授權實體可靠訪問信息的保證。
請注意,pKVM 旨在維護來賓的機密性和完整性,而不是可用性。這些原則影響跨越架構所有方面的設計決策,從管理程序到用戶空間組件。
保密性和完整性
機密性源於 pKVM 管理程序強制執行的內存隔離屬性。 pKVM 跟踪各個物理內存頁面的內存所有權以及所有者對共享頁面的任何請求。 pKVM 確保只有授權的 pVM(主機和來賓)將給定的頁面映射到由管理程序控制的階段 2 頁表中。這種架構維護 pVM 擁有的內存內容保持私有,除非所有者明確與另一個 pVM 共享它。
維護機密性的限制還擴展到系統中代表 pVM 執行內存訪問的任何實體,即具有 DMA 能力的設備和在更多特權層中運行的服務。 SoC 供應商必須滿足一組新要求才能支持 pKVM,否則無法提供機密性。
完整性適用於內存和計算中的數據:
- pVM 不能在未經同意的情況下修改彼此的內存。
- pVM 不能影響彼此的 CPU 狀態。
這些要求由管理程序強制執行。但是,在必須應用其他解決方案(例如 dm-verity 或 AuthFS)的虛擬數據存儲中,也會出現有關數據完整性的問題。
這些原則與 Linux 提供的進程隔離沒有什麼不同,Linux 提供的對內存頁面的訪問由階段 1 頁表和進程之間的內核上下文切換控制。然而,執行這些屬性的 pKVM 的 EL2 部分與整個 Linux 內核相比大約有一半的攻擊面(大約 10000 行代碼對 2000 萬行代碼),因此為過於敏感而無法依賴的用例提供更強的保證關於進程隔離。
鑑於它的大小,pKVM 適合於形式驗證。我們正在積極支持學術研究,旨在在實際 pKVM 二進製文件上正式證明這些屬性。
本文檔的其餘部分涵蓋了 pKVM 周圍的每個組件提供的機密性和完整性保證。
管理程序
pKVM 是一個基於 KVM 的管理程序,它將 pVM 和 Android 隔離到相互不信任的執行環境中。這些屬性在任何 pVM (包括主機)內發生妥協的情況下仍然有效。符合 AVF 的替代管理程序需要提供類似的屬性。
- 除非頁面所有者明確共享,否則 pVM 無法訪問屬於另一個實體(例如 pVM 或管理程序)的頁面。此規則包括主機 pVM 並適用於 CPU 和 DMA 訪問。
- 在 pVM 使用的頁面返回到主機之前,例如當 pVM 被銷毀時,它會被擦除。
- 在 OS 引導加載程序在後續設備引導中運行之前,所有 pVM 的內存和一次設備引導中的 pVM 固件都會被擦除。
- 當連接了硬件調試器(例如 SJTAG)時,pVM 無法訪問其先前生成的密鑰。
- 如果 pVM 固件無法驗證初始映像,則不會啟動。
- 如果
instance.img
的完整性受到損害,pVM 固件將不會啟動。 - 提供給 pVM 實例的引導證書鏈 (BCC) 和復合設備標識符 (CDI) 只能由該特定實例派生。
來賓操作系統
Microdroid是在 pVM 中運行的操作系統的一個示例。 Microdroid 由基於 U-boot 的引導加載程序、GKI、Android 用戶空間子集和有效負載啟動器組成。這些屬性在任何 pVM (包括主機)內發生妥協的情況下仍然有效。在 pVM 中運行的替代操作系統應該提供類似的屬性。
- 如果
boot.img
、super.img
、vbmeta.img
或vbmeta\_system.img
無法驗證,Microdroid 將無法啟動。 - 如果 APK 驗證失敗,Microdroid 將無法啟動。
- 即使更新了 APK,同一個 Microdroid 實例也不會啟動。
- 如果任何 APEX 未能通過驗證,Microdroid 將無法啟動。
- 如果在來賓 pVM 之外修改了
instance.img
,Microdroid 將無法啟動(或以乾淨的初始狀態啟動)。 - Microdroid 為引導鏈提供證明。
- 對共享給來賓 pVM 的磁盤映像的任何(未簽名)修改都會導致 pVM 端出現 I/O 錯誤。
- 提供給 pVM 實例的 BCC 和 CDI 只能由該特定實例派生。
安卓
這些是由 Android 作為主機維護的屬性,但在主機受損的情況下不適用:
- 來賓 pVM 不能直接與其他來賓 pVM 交互(例如,建立 vsock 連接)。
- 只有宿主 pVM 中的
VirtualizationService
才能與 pVM 建立通信通道(注意:它可以將已建立的通道傳遞給其他人)。 - 只有使用平台密鑰簽名的應用程序才能請求創建、擁有或與 pVM 交互的權限。
- 用於在主機和 pVM 之間建立vsock連接的標識符稱為上下文標識符 (CID) ,在主機 pVM 運行時不會重用。例如,不可能用另一個 pVM 替換正在運行的 pVM。
可用性
在 pVM 的上下文中,可用性是指主機為來賓分配足夠的資源,以便來賓可以執行他們設計的任務。
主機的職責包括調度 pVM 的虛擬 CPU。與 Xen 等傳統的 Type-1 管理程序不同,KVM 做出明確的設計決策,將工作負載調度委託給主機內核。鑑於當今調度程序的規模和復雜性,此設計決策顯著減小了可信計算庫 (TCB) 的規模,並使主機能夠做出更明智的調度決策以優化性能。但是,惡意主機可以選擇從不安排來賓。
類似地,pKVM 還將物理中斷處理委託給主機內核,以降低管理程序的複雜性並讓主機負責調度。努力確保訪客中斷的轉發只會導致拒絕服務(太少、太多或錯誤路由的中斷)。
最後,主機的虛擬機監視器(VMM)進程負責分配內存並提供虛擬設備,例如網卡。惡意 VMM 可以扣留來賓的資源。
儘管 pKVM 不向來賓提供可用性,但該設計保護主機的可用性免受惡意來賓的影響,因為主機始終可以搶占或終止來賓並回收其資源。
安全啟動
數據與 pVM 的實例相關聯,安全啟動確保可以控制對實例數據的訪問。實例的第一次啟動通過為 pVM 隨機生成一個秘密鹽並從加載的圖像中提取詳細信息(例如驗證公鑰和哈希)來配置它。此信息用於驗證 pVM 實例的後續啟動,並確保實例的機密僅發布給通過驗證的映像。這個過程發生在 pVM 中的每個加載階段:pVM 固件、pVM ABL、Microdroid 等等。
DICE 為每個加載階段提供一個證明密鑰對,其公共部分在該階段的 BCC 條目中得到認證。此密鑰對可以在引導之間更改,因此還派生了一個密封密鑰,該密鑰對 VM 實例在重新引導期間是穩定的,因此適用於保護持久狀態。密封機密對 VM 非常有價值,因此不應直接使用。相反,封印密鑰應該從封印秘密中衍生出來,並且應該儘早銷毀封印秘密。
每個階段將確定性編碼的CBOR對像傳遞給下一個階段。該對象包含秘密和 BCC,其中包含累積的狀態信息,例如最後階段是否安全加載。
解鎖設備
當使用fastboot oem unlock
設備時,用戶數據將被擦除。此過程可保護用戶數據免受未經授權的訪問。當設備解鎖時,pVM 的私有數據也會失效。
解鎖後,設備所有者可以自由刷新通常受驗證啟動保護的分區,包括包含 pKVM 實現的分區。因此,解鎖設備上的 pKVM 不會被信任來維護安全模型。
遠程方可以通過在密鑰證明證書中檢查設備的已驗證啟動狀態來觀察這種潛在的不安全狀態。