OP-TEE (開放式行動式可信執行環境)¶
OP-TEE 驅動程式處理基於 OP-TEE [1] 的 TEE。目前僅支援基於 ARM TrustZone 的 OP-TEE 解決方案。
與 OP-TEE 通訊的最低層基於 ARM SMC 呼叫約定 (SMCCC) [2],這是驅動程式內部使用的 OP-TEE SMC 介面 [3] 的基礎。在此之上是 OP-TEE 訊息協議 [4]。
OP-TEE SMC 介面提供了 SMCCC 所需的基本功能以及一些 OP-TEE 特有的附加功能。最值得關注的功能是:
OPTEE_SMC_FUNCID_CALLS_UID (SMCCC 的一部分) 返回版本資訊,該資訊隨後由 TEE_IOC_VERSION 返回。
OPTEE_SMC_CALL_GET_OS_UUID 返回特定的 OP-TEE 實現,例如,用於區分 TrustZone OP-TEE 和在單獨安全協處理器上執行的 OP-TEE。
OPTEE_SMC_CALL_WITH_ARG 驅動 OP-TEE 訊息協議。
OPTEE_SMC_GET_SHM_CONFIG 允許驅動程式和 OP-TEE 協商 Linux 和 OP-TEE 之間共享記憶體所使用的記憶體範圍。
GlobalPlatform TEE 客戶端 API [5] 是在通用 TEE API 之上實現的。
OP-TEE 架構中不同元件之間關係的圖示
User space Kernel Secure world
~~~~~~~~~~ ~~~~~~ ~~~~~~~~~~~~
+--------+ +-------------+
| Client | | Trusted |
+--------+ | Application |
/\ +-------------+
|| +----------+ /\
|| |tee- | ||
|| |supplicant| \/
|| +----------+ +-------------+
\/ /\ | TEE Internal|
+-------+ || | API |
+ TEE | || +--------+--------+ +-------------+
| Client| || | TEE | OP-TEE | | OP-TEE |
| API | \/ | subsys | driver | | Trusted OS |
+-------+----------------+----+-------+----+-----------+-------------+
| Generic TEE API | | OP-TEE MSG |
| IOCTL (TEE_IOC_*) | | SMCCC (OPTEE_SMC_CALL_*) |
+-----------------------------+ +------------------------------+
RPC (遠端過程呼叫) 是從安全世界向核心驅動程式或 tee-supplicant 發出的請求。RPC 透過 OPTEE_SMC_CALL_WITH_ARG 返回的 SMCCC 返回值中的一個特殊範圍來標識。用於核心的 RPC 訊息由核心驅動程式處理。其他 RPC 訊息將轉發到 tee-supplicant,驅動程式不再進一步介入,除了切換共享記憶體緩衝區表示。
OP-TEE 裝置列舉¶
OP-TEE 提供了一個偽可信應用程式:drivers/tee/optee/device.c,以支援裝置列舉。換句話說,OP-TEE 驅動程式呼叫此應用程式來檢索可在 TEE 總線上註冊為裝置的受信任應用程式列表。
OP-TEE 通知¶
安全世界可以使用兩種通知方式來讓普通世界知曉某些事件。
使用
OPTEE_RPC_NOTIFICATION_SEND引數透過OPTEE_RPC_CMD_NOTIFICATION傳遞同步通知。非同步通知透過非安全邊沿觸發中斷和非安全中斷處理程式中的快速呼叫相結合的方式傳遞。
同步通知受限於依賴 RPC 進行傳遞,這僅在透過 OPTEE_SMC_CALL_WITH_ARG 進行可讓出呼叫進入安全世界時才可用。這排除了此類通知來自安全世界中斷處理程式。
非同步通知透過非安全邊沿觸發中斷傳遞到 OP-TEE 驅動程式中註冊的中斷處理程式。實際的通知值透過快速呼叫 OPTEE_SMC_GET_ASYNC_NOTIF_VALUE 獲取。請注意,一箇中斷可以表示多個通知。
通知值 OPTEE_SMC_ASYNC_NOTIF_VALUE_DO_BOTTOM_HALF 具有特殊含義。當接收到此值時,表示普通世界應該進行一個可讓出呼叫 OPTEE_MSG_CMD_DO_BOTTOM_HALF。此呼叫由協助中斷處理程式的執行緒執行。這是安全世界中 OP-TEE OS 實現裝置驅動程式“上半部分和下半部分”風格的構建塊。
OPTEE_INSECURE_LOAD_IMAGE Kconfig 選項¶
OPTEE_INSECURE_LOAD_IMAGE Kconfig 選項支援在核心啟動後從核心載入 BL32 OP-TEE 映象,而不是在核心啟動前從韌體載入。這還需要在 Trusted Firmware for Arm 中啟用相應的選項。Trusted Firmware for Arm 文件 [6] 解釋了啟用此功能相關的安全威脅以及在韌體和平臺層面的緩解措施。
使用此選項時,還有一些針對核心的額外攻擊向量/緩解措施需要解決。
啟動鏈安全。
攻擊向量:替換 rootfs 中的 OP-TEE OS 映象以獲得系統控制權。
緩解:必須有啟動鏈安全機制來驗證核心和 rootfs,否則攻擊者可以透過修改 rootfs 中的 OP-TEE 二進位制檔案來修改已載入的 OP-TEE。
備用啟動模式。
攻擊向量:使用備用啟動模式(即恢復模式)時,OP-TEE 驅動程式未載入,導致 SMC 漏洞開放。
緩解:如果存在啟動裝置的其他方法(例如恢復模式),應確保在該模式下應用相同的緩解措施。
SMC 呼叫之前的攻擊。
攻擊向量:在發出載入 OP-TEE 的 SMC 呼叫之前執行的程式碼可能被利用,從而載入備用 OS 映象。
緩解:OP-TEE 驅動程式必須在任何潛在攻擊向量開放之前載入。這應包括掛載任何可修改的檔案系統、開放網路埠或與外部裝置(例如 USB)通訊。
阻塞載入 OP-TEE 的 SMC 呼叫。
攻擊向量:阻止驅動程式探測,從而在需要時無法執行載入 OP-TEE 的 SMC 呼叫,使其可在稍後執行並載入修改後的 OS。
緩解:建議將 OP-TEE 驅動程式構建為內建驅動程式而不是模組,以防止可能導致模組無法載入的漏洞利用。
參考資料¶
[1] https://github.com/OP-TEE/optee_os
[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
[3] drivers/tee/optee/optee_smc.h
[4] drivers/tee/optee/optee_msg.h
- [5] http://www.globalplatform.org/specificationsdevice.asp 查詢
“TEE 客戶端 API 規範 v1.0” 並點選下載。
[6] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html