08-Isolation using virtualization in the Secure World_Whitepaper
快速鏈接:
.
👉👉👉 個人博客筆記導讀目錄(全部) 👈👈👈
相關鏈接: (專題：《learn-the-architecture系列》)
- 01-Introducing the Arm architecture
- 02-Armv8-A Instruction Set Architecture
- 03_Introduction_to_AMBA_AXI
- 04-TrustZone for Armv8-A
- 05-Exception model
- 06-GICv3_v4_overview
- 07-Armv8-A virtualization
- 08-Isolation using virtualization in the Secure World_Whitepaper
- 09-LearnTheArchitecture-MemoryManagement
- 10-Armv8-A memory model guide–ongoing
- 11-Memory Management Examples
- 12-Generic Timer
- 13-Introduction to security
- 14-Providing protection for complex software
- 15-Arm-Confidential-Compute-Software-Stack
- 16-Understanding the Armv8.x extensions
目錄
- 1 Introduction
- 2 Background - A brief history of Arm TrustZone
- 3 Today’s challenges in the Secure world
- 3.1. Trusted application ecosystem challenges
- 3.2. Integration of code from multiple vendors in the Secure world
- 3.3. The principle of least privilege
- 3.4. Required solution
- 4 Virtualization in Secure world
- 5 Secure partitions
- 6 Migration of the secure ecosystem to Secure EL2
- 6.1. Impacts on trusted operating systems
- 6.2. Impacts on Normal world software
- 7 Conclusion
- 8 Glossary
1 Introduction
Armv8.4 架構在安全世界中增加了虛擬化支持。 本白皮書介紹了引入此功能的原因，以及它提供的安全性改進。 本文介紹了一種軟件架構來利用這些優勢。 安全 EL2 和此軟件架構為Platform Security Architecture (PSA) Firmware Framework的 A-Profile 處理器版本提供了基礎。
2 Background - A brief history of Arm TrustZone
Arm TrustZone 于 2003 年(竟瞎吹牛逼 )被引入 Arm 架構 A-profile。 TrustZone 方法的核心是硬件分離的安全和正常世界的概念。 只有在安全世界中運行的軟件才能訪問安全硬件資源。 普通世界中的軟件被硬件阻止訪問這些資源。 安全（可信）和正常（非可信）世界的概念擴展到處理器之外，包括 SoC 內的內存、軟件、總線事務、中斷和外設。
TrustZone 的引入為可信操作系統 (OS) 供應商的生態系統鋪平了道路。 最初，可信操作系統提供基本的設備安全服務，例如可信啟動或平臺機密的處理。 今天，可信操作系統已經發展到支持定制應用程序，這些應用程序可能用于許多安全用例，例如安全支付或媒體保護。
最初，可信操作系統占據了與 TrustZone 相關的所有處理器模式，包括專門用于在正常和安全世界之間切換的代碼，以及提供安全服務的代碼。 在基于 Armv7 和以前的架構修訂版的系統中，切換代碼在監控模式下運行，而服務代碼在安全監控模式和安全用戶模式下運行。 在 Armv8 監視器模式中，演變為異常級別 EL3，具有自己的內存轉換機制和中斷向量。 這允許更清晰地分離代碼，更容易為切換和服務提供單獨的二進制圖像。
EL3 的出現為標準化關鍵平臺管理功能提供了新的機會。 在那之前，這些都是在普通世界軟件中實現的，導致碎片化，并且必須為每個操作系統和每個單獨的平臺重復解決方案。 異常級別的添加使得為這些管理功能提供標準固件解決方案成為可能，消除了普通世界操作系統中的碎片化和通用化代碼。 這種服務最普遍的例子是電源管理。 這些標準化工作產生了一些關鍵規范：
(1)、SMC Calling Convention (SMCCC)
本文檔提供了從安全領域請求服務時要遵循的標準方法。它描述了如何將寄存器用于參數和返回值，以及如何調用安全監視器調用 (SMC) 指令。
(2)、Power State Coordination Interface (PSCI)
系統和處理器電源管理標準，涵蓋了許多用例，包括啟動、熱插拔、空閑以及系統關閉和reset。
(3)、Software Delegated Exceptions Interface (SDEI)
該規范主要用于企業系統，提供了與不可屏蔽中斷等效的軟件。
這種標準化的勢頭并沒有止步于規范，它還包括 Trusted Firmware 開源項目，以前稱為 Arm Trusted Firmware 項目。 Trusted Firmware 實現了上述規范，并為可信啟動提供了參考。 今天，該項目為大多數 Arm 供應商提供了 Secure world 固件基礎，并支持許多流行的可信操作系統。 除了上述規范之外，可信固件還可用于提供其他服務，例如勘誤表管理或特定于芯片供應商的服務。
圖 1 顯示了基于 Armv8-A 架構的安全世界在當今系統中提供的服務種類。 該圖還顯示了提供這些服務的軟件代理以及按異常級別進行的廣泛分區。 受信任的操作系統提供安全服務。 這通常跨越安全 EL1 和安全 EL0。 服務通常通過在 Secure EL0 中運行的受信任應用程序提供。 為了支持這些服務，可信操作系統將擁有可信硬件資源的驅動程序，例如安全加密加速器或安全存儲設備。 EL3 除了托管代碼以在正常和安全世界之間轉換之外，還提供平臺服務，例如通過 PSCI 進行核心電源管理。 此代碼由芯片供應商平臺固件提供，通常基于 Trusted Firmware 開源項目的代碼。
3 Today’s challenges in the Secure world
TrustZone 的成功也帶來了一些架構挑戰，將在以下部分進行描述。
3.1. Trusted application ecosystem challenges
TrustZone 的成功催生了許多來自不同供應商的可信操作系統。 盡管這些提供類似的服務，并且有一些圍繞可信操作系統 API 的標準，但可信應用程序是特定于可信操作系統的。 這在上圖中進行了說明，它顯示了正常世界的客戶端應用程序和受信任的應用程序如何需要鏈接到受信任的操作系統供應商特定的庫。 這限制了應用程序從一個受信任的操作系統到另一個的可移植性范圍。 移植的成本意味著應用程序往往會綁定到特定的受信任操作系統。
這給需要提供豐富的應用程序集的 OEM 帶來了一個問題，不同的應用程序綁定到不同的受信任操作系統。 雖然有一些方法可以在 Secure EL1 中托管多個可信操作系統，但這需要可信操作系統修改，以及不同可信操作系統供應商之間的協作。
3.2. Integration of code from multiple vendors in the Secure world
可信操作系統需要訪問可信硬件資源來提供服務。 在某些情況下，這是通過芯片供應商驅動程序提供的，這些驅動程序需要集成到受信任的操作系統中。 在其他情況下，芯片供應商提供自己的可信操作系統，這再次導致 OEM 可能需要集成多個可信操作系統。 這兩種方法都要求 OEM 集成來自不同供應商的資源。
如上所述，除了安全服務外，平臺服務將由 EL3 中的平臺固件提供。 這些服務需要芯片供應商特定代碼來執行功能，例如電源管理。 與這些服務一起運行的是調度程序代碼，它涉及將 SMC 調用調度到一個或多個受信任的操作系統以及芯片供應商固件。 調度代碼包括可信操作系統特定代碼，以及通常源自可信固件項目的通用代碼。
上圖說明了由上述考慮產生的示例軟件堆棧。 可以看出，有許多供應商參與其中。 構成此圖的關鍵 Secure world 軟件組件和供應商是：
- 受信任的操作系統支持應用程序的安全服務。 由一個或多個第三方可信操作系統供應商提供。
- 受信任的操作系統或驅動程序模型，以支持平臺上受信任的硬件資源，例如安全存儲或安全元素。 由芯片供應商提供。
- EL3 固件提供平臺服務，如PSCI。 由芯片供應商提供。
- EL3 固件提供普通世界和適當的安全世界之間的切換，這些可以來自不同的供應商。
3.3. The principle of least privilege
最小特權原則 principle of least privilege要求組件必須只能訪問其正確操作所必需的信息和資源。 這與安全世界軟件的當前方法形成對比，如圖 1 所示。EL3 和安全 EL1 是特權異常級別，在 Armv8.3 或更早版本上，它們都具有對系統地址映射和物理中斷的相同級別的訪問權限。 這意味著無法將運行在 EL3 固件中的組件與運行在安全 EL1 中的組件隔離開來。 特別是：
(1)、Firmware in EL3 cannot be isolated from a trusted OS.
在 EL3 中運行的固件無法限制來自 Secure EL1 中受信任操作系統的安全和非安全系統地址映射的可見性。
(2)、EL3 firmware components cannot be isolated from each other
如圖 1 所示，通用固件組件、芯片供應商或第三方可信操作系統供應商組件可以在 EL3 中合并。 所有這些都來自不同的供應商，但不能相互隔離，因為它們對物理地址映射和物理中斷具有相同的可見性。
(3)、Normal world cannot be protected from trusted OSs in secure EL1
安全 EL1 可以不受限制地訪問整個物理地址映射，包括安全的和非安全的。 對系統地址映射的無限制訪問已被用于對某些受信任操作系統實現的權限提升攻擊。
總的來說，這些限制使得無法對每個軟件組件實施最小特權原則。 這增加了審計和認證的復雜性，因為所有軟件實體都需要相互信任，因此不能單獨審計。 這種方法也使得很難將受信任的硬件資源隔離到特定的軟件實體。 系統 MMU (SMMU) 可以緩解這個問題，但它并不能消除它，因為對 SMMU 進行編程的軟件組件不能與其他安全世界軟件組件隔離。
3.4. Required solution
解決上面列出的挑戰需要一種可以促進組件化和硬件隔離的架構。 該解決方案需要從 TrustZone 提供的安全隔離（僅提供兩個世界之間的隔離）擴展到可以在多個互不信任的軟件映像之間提供隔離的架構。 特別是，該解決方案需要：
(1)、一種在軟件組件之間提供硬件隔離的方法。 這消除了相互信任的需要，并允許組件彼此分開審核。
隔離需要限制對物理地址空間、寄存器的訪問，以便處理器和具有直接內存訪問 (DMA) 功能的可信外設。
(2)、為了使供應商生態系統能夠協同工作，該架構將需要用于公共邊界的標準 API。
標準 API 將使各種軟件映像能夠進行通信并允許代碼的泛化和組件化。 這可以從 EL3 和非安全 EL2 中刪除受信任的操作系統供應商特定代碼。
4 Virtualization in Secure world
Armv8.4 架構引入了 Secure EL2 擴展，在安全世界中增加了對虛擬化的支持。 這將在非安全狀態下可用于虛擬化的功能帶入安全狀態。
虛擬化支持的一個關鍵特性是添加了管理程序控制的第二階段轉換。 這允許管理程序控制哪些物理內存區域可用于虛擬機。 圖 2 說明了基本思想。 來賓操作系統控制轉換的第一階段，該階段在虛擬地址空間 (VA) 和中間物理地址空間 (IPA) 之間進行轉換。 由管理程序控制的第二個轉換階段在 IPA 和物理地址空間 (PA) 之間進行轉換。 這使管理程序能夠控制物理地址空間的哪些部分對給定的虛擬機可見。
安全 EL2 將第 2 階段轉換添加到處理器的安全狀態。 此外，Arm System MMU 架構 3.2 及更高版本支持其他 IO 主設備在安全狀態下的第 2 階段轉換。 這些特性共同為安全領域帶來了虛擬化支持，并提供了滿足上述許多架構要求的硬件基礎。 安全虛擬化支持：
(1)、EL3軟件與Secure EL1軟件的隔離。
(2)、Normal world軟件與Secure EL1軟件的隔離。
(3)、不同的 Secure EL1 軟件組件相互隔離。
Secure EL2 提供的架構擴展能夠隔離來自不同供應商的安全世界軟件。 這種架構還可以隔離具有不同目的的軟件堆棧。
傳統上，受信任的操作系統可以訪問系統地址映射中的任何位置。 由于受信任的操作系統是一個特權實體，因此可以利用其實現中的弱點來訪問系統中的任何內存地址，無論是安全的還是非安全的。 事實上，已經在一些受信任的操作系統實現中報告了這種性質的特權提升攻擊。 安全 EL2 通過限制駐留在安全 EL1 或安全 EL0 中的軟件可訪問的內存區域來防止這種升級。 這是通過使用第 2 階段翻譯實現的。 在系統 MMU 的安全狀態下控制第 2 階段轉換，將這種保護擴展到包括支持 DMA 的可信硬件資源。
5 Secure partitions
安全 EL2 和 SMMU 提供了應對上述挑戰所需的硬件隔離。 本節描述了一種利用這些功能來應對這些挑戰的軟件架構。 該架構還建立了標準 API，支持安全世界軟件供應商之間的協作。
（注Secure Partition Client Interface (SPCI)，就是后來的FF-A）
圖 3 描述了在包含 Secure EL2 的系統中用于 Secure 世界的軟件架構的基本元素。 基本要素是：
(1)、Secure partitions in Secure EL1
安全分區是沙盒環境，具有隔離的地址空間。 其他安全分區無法直接訪問此空間。 借助 Secure EL2，安全分區是通過虛擬化支持實現的，本質上是一個安全世界的虛擬機。 安全分區可用于托管受信任的操作系統，或者可能包含受信任硬件資源的驅動程序堆棧。 圖 3 描繪了一個托管受信任操作系統的安全分區，以及另一個托管芯片供應商提供的平臺驅動程序。
(2)、Secure Partition Manager
EL3 和 Secure EL2 中的通用固件負責管理這些安全分區。 這里的一個關鍵組件是安全分區管理器 (SPM)，它負責將請求定向到正確的安全分區，并負責監管安全分區的訪問。 SPM 可以被認為是一個最小的分區管理程序。
圖 3 說明了一種軟件架構，其中由芯片供應商提供的特定于平臺的固件組件與 Secure EL2 和 EL3 中的固件以及受信任的操作系統隔離。 這是通過將可信操作系統和平臺固件放入單獨的安全分區來實現的。 要啟用此架構，SPM 需要知道每個分區需要哪些資源。 這允許它設置適當的內存映射限制，并在向它們發送消息或中斷時分派分區。 這可以通過使用每個分區的資源描述清單來實現，該清單主要描述：
(1)、它需要的系統資源、內存、中斷的所有權以及對物理系統地址映射中區域的訪問。
(2)、它通過請求的資源和指定屬性的組合實現的安全服務列表。
在啟動時，SPM 使用資源描述來：
(1)、驗證和分配安全分區請求的資源。
(2)、執行安全分區所需的架構和系統設置，例如 維護 vGIC 和第 2 階段翻譯。
(3)、一旦建立了執行環境，就初始化安全分區。
為了保持 EL3 和安全 EL2 代碼的通用性，該軟件架構將需要在各種軟件代理之間的邊界處使用標準 API。 正常世界中安全服務的客戶端和安全分區中的服務提供者之間需要 API。 這種界面所需的功能是：
(1)、啟用普通世界中的客戶端和安全分區中的服務之間的消息傳遞。
(2)、啟用分區中安全服務的發現。
(3)、啟用客戶端和安全分區之間的內存共享。
(4)、 通用接口，在正常世界管理程序和 SPM 中不需要受信任的操作系統特定驅動程序，因此需要 EL3 和安全 EL2。
Arm 對此接口的提議在Secure Partition Client Interface (SPCI) 中有所描述。 Arm 歡迎就此提案進行協作和反饋。
此外，安全分區和安全分區管理器之間需要標準 API。 這為安全分區運行時環境提供了基礎。 此類 API 的基本要求：
(1)、啟用安全分區之間的消息傳遞。
(2)、啟用在安全分區中接收消息和中斷。
(3)、啟用安全分區的初始化。
與資源管理一起，安全分區之間的消息傳遞提供了一種為安全世界客戶端創建服務的方法，以及一種安全共享可信硬件資源的方法。 Arm 提出了 Secure Partition Run Time (SPRT)，作為安全分區運行時 API 的基礎。 這是一個規范，描述了安全分區可以依賴以實現安全服務的運行時模型。 它指定必須包含在安全分區的資源描述中的強制性信息，以及運行時模型和 SPM 的接口。 SPRT 和 SPCI 可以被認為是 A-profile 處理器中平臺安全架構的固件框架。 這兩個規范都涵蓋了適用于有和沒有 Secure EL2 (S-EL2) 的系統的方法。 這使軟件能夠在 S-EL2 硬件可用之前遷移到這些規范。
6 Migration of the secure ecosystem to Secure EL2
上述軟件架構給安全世界軟件的供應商帶來了變化和影響。 這些將在下面討論
6.1. Impacts on trusted operating systems
虛擬化可信操作系統改變了它們與平臺上物理資源交互的方式。 SPM 限制對系統地址映射和物理中斷的訪問。
在沒有安全 EL2 的系統中，安全物理中斷通常路由到安全 EL1。 使用安全 EL2，中斷由安全固件管理，其方式類似于正常世界中的虛擬機管理程序管理非安全物理中斷的方式。 這些首先被定向到管理程序，然后管理程序將其對應的虛擬中斷委托給來賓操作系統 VM。 為了在提議的安全 EL2 架構中啟用這種方法，系統集成商需要為安全分區中的給定可信操作系統指定它將處理哪些安全中斷。 安全分區管理器需要使用此信息，以便它可以將相應的虛擬中斷路由到適當的安全分區。 受信任的 OS 中斷處理代碼不應受此顯著影響。 受信任的操作系統將針對軟件透明的虛擬 GIC (vGIC) 運行，并在中斷向量處接收中斷。
就像在中斷情況下一樣，系統集成商必須指定安全分區可以看到哪些區域或內存。 SPM 需要使用此信息，以便它可以在處理器中放置適當的第 2 階段頁表，如果需要，還可以在系統 MMU 中放置。
將受信任的操作系統放在安全分區中，需要進行一些更改才能使用新的標準 API。
6.2. Impacts on Normal world software
Hypervisor可用于移動設備以提供額外的安全性。 在這種情況下，管理程序可能需要受信任的操作系統特定的修改，以允許客戶端操作系統向受信任的操作系統發送消息。
對于圖 3 中提出的架構，Arm 提出了一個通用的消息傳遞接口，即Secure Partition Client Interface (SPCI)。 這將允許從 EL3 和安全 EL2 固件中刪除受信任的操作系統特定驅動程序。 它將導致 SPM 的通用實現，由 Trusted Firmware 開源項目提供。 遷移到 SPCI 將需要更改客戶端內核中受信任的操作系統驅動程序以遷移到 SPCI，以及在普通世界管理程序中提供通用驅動程序。
7 Conclusion
本白皮書描述了在 Armv8.4 架構的安全世界中引入虛擬化擴展背后的基本原理。 此外，它還提出了一種擴展現有安全世界軟件架構的方法，以利用安全虛擬化的優勢。 這些好處包括改進的安全隔離以及普通和安全世界代碼的泛化。 可以在 SPCI 和 SPRT 規范中找到對該架構的更詳細描述。 這些規范連同在架構中引入的 Secure EL2，為 A-Profile 處理器的平臺安全架構 (PSA) 固件框架提供了基礎。
8 Glossary
總結
以上是生活随笔為你收集整理的08-Isolation using virtualization in the Secure World_Whitepaper的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 07-Armv8-A virtualiz
- 下一篇： 09-LearnTheArchitect