利用TrustZone保護可信程序免受惡意操作系統(tǒng)攻擊

文/管樂

利用TrustZone保護可信程序免受惡意操作系統(tǒng)攻擊

文/管樂

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

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

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

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

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

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

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

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

1.在運行過程中，可信進程和普通操作系統(tǒng)隔離，普通操作系統(tǒng)不能訪問可信進程的數(shù)據(jù)和代碼；

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

3.驗證系統(tǒng)調(diào)用的返回值，來抵抗Iago攻擊【8】；

4.加密文件操作，使得寫入磁盤的數(shù)據(jù)是密文，防止不可信操作系統(tǒng)的訪問。

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

圖2 代碼段缺頁處理

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

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

我們在NXP的i.MX6q開發(fā)版上實現(xiàn)了以上設計，并成功運行了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.

（責編：楊潔）

為美國賓州州立大學）