利用TrustZone保護可信程序免受惡意操作系統攻擊

文/管樂

利用TrustZone保護可信程序免受惡意操作系統攻擊

文/管樂

IoT（物聯網）設備正在瘋狂滲透人們的生活。從IP攝像頭，外科手術機器人， 語音智能輔助系統，到邊緣計算（如智能路由器），人們的生活工作環境已經由上億個IoT設備互聯。不如此，這些設備需要有足夠的智能來協助我們來處理事務，比如，Amazon的Echo語音智能系統可以學習用戶的習慣，從而制定個性化的語音服務。設備生產商為了快速進入市場，通常會在已有的成熟平臺搭建自己的系統，很顯然，ARM加Linux的組合統治了目前智能IoT市場。

然而，Linux內核作為統治互聯網的開源軟件，無時不刻遭受著黑客的攻擊，2017年短短幾個月（截至7月8日），已有346個安全漏洞被曝出【1】。操作系統內核作為計算機的大管家，通常被認為是系統的可信計算基（TCB）。顯然，惡意的Linux內核給運行在其上的敏感用戶程序帶來嚴重的威脅。如何在操作系統不可信的情況下，保護敏感應用程序的機密性、隔離性和可信性是非常有挑戰但卻很重要的研究課題。

在x86平臺，已有基于虛擬化的方案來解決這一問題【2，3】。其總體思想是利用影子頁表來給應用程序兩個視圖。如圖1所示，在用戶態，進程可以正常訪問它的數據；但是一旦進入內核，如果處理器要訪問用戶數據，該數據對應的頁會被hypervisor透明的加密。

圖1 基于虛擬化的解決方案

對基于ARM的IoT平臺，這一思路卻行不通。其原因有以下三點：第一，ARM的虛擬化硬件擴展直到2010年才發布【4】，因此很多現有ARM設備不支持該擴展；第二，虛擬機不能提供native的性能，這對于本來就資源受限的ARM IoT移動設備，無疑是很難接受的（當然，ARM的硬件虛擬化技術在服務器市場仍然被廣泛使用）【5】；第三，這類方案需要依賴hypervisor，然而，實現一個hypervisor本身需要相當大的TCB， 近年來hypervisor的安全性已經受到嚴峻的挑戰【6】。

相比硬件虛擬化擴展，TrustZone安全擴展【7】已經得到廣泛應用，自從在ARMv6上第一次被引入，TrustZone已被部署在其后絕大多數應用處理器上（比如，手機上廣泛使用的cotex-a系列）上。簡單來講，具有TrustZone安全擴展的處理器，有兩個邏輯core，它們共用一套處理器運算資源。兩個core分別運行在安全世界和普通世界中，它們分時復用處理器。每個core有自己獨立的安全運行級和系統控制寄存器、內存管理單元（MMU）等，因此，他們可以獨立運行自己的操作系統。兩個core的不同，體現在對系統資源的訪問上，對應兩個邏輯core，系統的硬件資源被劃分為安全和非安全的。運行在安全世界的core，可以訪問所有的硬件資源；而運行在普通世界的core，則只能訪問非安全的資源。這些訪問控制的配置，儲存在只有安全世界才能訪問的寄存器中。一般來講，普通世界的core運行commodity的操作系統，比如Linux；安全世界的core運行輕量級的可信操作系統，從而提供一個可信運行環境（TEE）。ARM的這種架構， 被Android、iOS等移動操作系統廣泛利用。比如，在指紋識別技術中，為了保護用戶指紋的原始信息，移動操作系統沒有權限獲取指紋識別器的數據，相反，在安全世界，TEE里的服務進程進行指紋采集和比對等工作，而僅僅只把結果傳送給普通世界的移動操作系統。

已有的基于TrustZone的安全技術，其安全服務的API和普通操作系統完全不同，并且相對獨立，甚至不能和普通世界交互，僅構成一個自包含的程序邏輯（Pieces of Application Logic， PAL） 。TrustShadow則首次利用TrustZone，來安全的運行未更改的應用程序。一方面，TrustShadow支持已有的代碼；另一方面，支持TrustZone的設備非常廣泛。因此，TrustShadow可以立即部署在現實世界，并保護已有的、不需要修改的代碼。

TrustShadow的基本思想是，可信的進程仍然由普通世界的Linux內核來創建和管理，但是，其運行必須在安全世界中。顯然，可信進程所使用的物理內存必須是安全資源，這樣可以防止Linux內核對其進行訪問。可信進程在安全世界的運行環境，比如頁表的創建、系統服務由安全世界的一個輕量級運行時來維護。為了減小其TCB，安全運行時并不直接參與這些服務，而是把他們轉發到普通世界的Linux內核，然后，驗證其行為是否可信。顯然，驗證一個行為正確性的復雜性遠遠低于實現它，因此，安全運行時可以保持很小的TCB。通過這些驗證機制，我們確保可信進程的以下安全特性：

1.在運行過程中，可信進程和普通操作系統隔離，普通操作系統不能訪問可信進程的數據和代碼；

2.載入階段，保證可信進程的代碼的完整性；

3.驗證系統調用的返回值，來抵抗Iago攻擊【8】；

4.加密文件操作，使得寫入磁盤的數據是密文，防止不可信操作系統的訪問。

圖2展示了TrustShadow如何通過缺頁處理（page fault handler）來保證可信進程地址空間的隔離，以及確保代碼的完整性。其他技術細節，請參考MobiSys 2017的論文《TrustShadow：Secure Execution of Unmodified Applications with ARM TrustZone》。

圖2 代碼段缺頁處理

如圖2所示，當進程由于訪問代碼而發生缺頁，安全運行時把該異常轉發給普通世界的Linux內核，Linux找到對應的文件緩存頁N-page，安裝頁表，同時給可信進程分配一個安全的物理頁S-page。安全運行時接管后，首先驗證S-page是否真的安全資源，其次驗證S-page是否和別的物理內存存在doublemapping，只有在安全驗證都通過以后，安全運行時才安裝可信的頁表，并把N-page的代碼復制到S-page。最后，使用儲存在安全世界的元數據來驗證該代碼頁是否經過篡改，如果沒有，則返回可信進程繼續執行。至此，普通Linux不能對改代碼頁進行任何修改。

當然，把進程運行在安全世界，如果有漏洞，則可能被攻擊者利用，反過來攻擊普通世界的Linux內核，因為安全世界的權限大于普通世界。在TrustShadow的設計中，我們利用以下幾點來防止這一隱患：第一，TrustShadow支持未經修改的程序，并不意味著所有程序都可以在安全世界運行。我們需要對可信進程進行嚴格審查，通過審查的程序，需要綁定一個簽名的manifest，安全運行時檢查該manifest的有效性來判斷是否允許其在安全世界運行；第二，由于可信進程運行在用戶空間，即使其有漏洞，也需要進一步exploit安全運行時，才能構成有效攻擊；第三，安全運行時進行了極簡的設計，其對可信進程暴露的接口很少（僅僅轉發異常和檢查系統服務返回值），并且5000+的代碼量也使得形式化驗證成為可能。

我們在NXP的i.MX6q開發版上實現了以上設計，并成功運行了50多個Linux的核心utility，以及Apache、Nginx等大型程序。

【1】 CVEdetails.com. Linux： Vulnerability statistics. https：//www.cvedetails.com/product/47/Linux-Linux-Kernel.html？vendor_id=33

【2】 Chen， Xiaoxin， et al. “Overshadow： a virtualization-based approach to retrofitting protection in commodity operating systems.” ACM SIGARCH Computer Architecture News. Vol. 36. No. 1. ACM， 2008.

【3】 Hofmann， Owen S.， et al. “Inktag： Secure applications on an untrusted operating system.” ACM SIGARCH Computer Architecture News. Vol. 41. No. 1.ACM， 2013.

【4】 ARM Architecture Group. Virtualization Extensions Architecture Specification， 2010. https：//www：arm：com/products/processors/technologies/virtualization-extensions：php.

【5】 Felix Baum. Why you don‘t necessarily need a hypervisor， 2014.http：//embedded-computing：com/guest-blogs/why-you-dont-necessarily-need-ahypervisor/.

【6】 CVEdetails.com. Vmware： Vulnerability statistics. http：//www：cvedetails：com/vendor/252/Vmware：html.

【7】 ARM Ltd. Security technology building a secure system using trustzone technology （white paper）. 2009.

【8】 Checkoway， Stephen， and Hovav Shacham. Iago attacks： Why the system call api is a bad untrusted rpc interface. Vol. 41. No. 1. ACM， 2013.

（責編：楊潔）

為美國賓州州立大學）