SGX 應用支持技術研究進展*

董春濤,沈晴霓,羅 武,吳鵬飛,吳中海1,

1(北京大學 軟件與微電子學院,北京 102600)

2(北京大學 信息科學技術學院,北京 100871)

3(北京大學 軟件工程國家工程研究中心,北京 100871)

4(高可信軟件技術教育部重點實驗室(北京大學),北京 100871)

隨著云計算與大數據技術的快速發展,越來越多的應用程序被部署到第三方數據中心和云平臺中,如Amazon AWS[1]和Microsoft Azure[2].但是,這也帶來了一系列安全問題,例如:應用程序在云平臺以明文方式處理敏感數據,容易被云服務提供商或其他攻擊者攻擊.因此,應用程序必須能夠抵御云服務提供商和其他攻擊者的攻擊.傳統手段中,基于加密的保護技術[3-5]只能支持有限的運算操作,全同態加密[6]可以支持任意操作,但增加了大量的開銷.當前,基于CPU 提供的可信執行機制是不可信環境中保護應用程序的重要手段,例如Intel 推出的SGX(software guard extensions)指令集擴展[7].

SGX 是一種基于內存加密和證明的硬件機制,可以為應用程序提供用戶空間的可信執行環境enclave[8],并將程序執行和狀態與底層操作系統(operating system,簡稱OS)、虛擬機管理程序、固件、I/O 設備等隔離開來,保障用戶關鍵代碼和數據的機密性與完整性不受惡意軟件的破壞.SGX 的可信計算基(trusted computing base,簡稱TCB)僅包括CPU,避免了基于軟件的TCB 自身存在安全漏洞的風險,提升了系統的安全性.同時,SGX 可以保障運行時的可信執行環境,抵御惡意代碼對程序被保護內容的訪問與篡改,進一步增強了系統的安全性.SGX強大的安全保障能力與性能保證,使其得到了廣泛的應用與發展.但是SGX 在應用中也暴漏出諸多的瓶頸問題,如何解決這些瓶頸問題也成為了學術界和工業界的重要研究方向.本文通過整理和歸納相關研究工作,總結了目前SGX 應用面臨的瓶頸問題,主要包括應用安全問題、應用性能瓶頸、應用開發的困難性和應用功能的局限性,并對這4 類問題的解決方案分別進行了分析和總結.

安全性是SGX 最基本和最重要的目標.SGX 可以為代碼和數據提供機密性和完整性保證,但其在實際應用中依然會面臨諸多的安全風險和威脅,例如過大的TCB、暴露過多的對外接口和敏感代碼的安全劃分與驗證以及側信道攻擊[9-11]等.針對上述安全風險與安全威脅,學術界已經提出了多種方案,本文將其歸納為TCB 最小化、對外接口最少化、敏感代碼的自動化生成與安全檢測以及潛在的安全威脅分析與防護這4 種類型.

性能開銷是目前制約SGX 應用推廣的重要因素.SGX 為代碼和數據提供機密性和完整性保證,同時也帶來了較高的性能開銷.SGX 性能開銷主要包括進入和退出enclave 導致的enclave 切換開銷、內存加解密開銷和頁替換(paging)開銷這3 個方面.針對上述性能開銷的原因,本文總結和梳理了目前研究工作中的性能優化方案,將SGX 性能優化歸納為模式(enclave)切換性能優化、內存加密優化和內存頁替換這3 種技術.

應用開發困難也是制約 SGX 發展和推廣的重要原因.Intel 公司為用戶提供了軟件開發包(software development kit,簡稱SDK),但是使用該SDK 開發SGX 應用程序卻并不容易,甚至錯誤的使用方式會導致安全風險.目前,SGX 應用開發的困難問題主要包括敏感代碼劃分工作量大且無法直接支持舊有的應用程序、缺少安全檢測與性能測試等輔助開發工具、支持的語言類型有限和缺少操作系統庫(library OS)支持.本文總結了相關研究工作提出的SGX 應用輔助開發技術,主要包括安全開發語言、輔助開發工具和通用系統庫等.

云環境是SGX 技術應用的主要場景,但是目前SGX 技術自身缺乏對虛擬機(vitual machine,簡稱VM)遷移和容器(container)等云平臺常用功能的支持.很多研究工作針對SGX 缺乏的功能支持,對其功能進行了擴展,主要包括虛擬機遷移支持技術和容器支持技術.

本文第1 節對SGX 的相關概念進行概述,并介紹SGX 的關鍵機制和SDK.第2 節對SGX 的應用現狀以及瓶頸問題進行總結.第3 節對SGX 應用的安全風險以及已有的安全防護技術進行總結.第4 節分析SGX 性能開銷的原因,并對相關性能優化技術進行歸納.第5 節總結SGX 應用開發的困難性問題以及已有的SGX 應用輔助開發技術.第6 節總結目前已有的SGX 應用功能擴展技術.最后對全文進行總結,闡述SGX 應用支持技術仍然需要解決的問題并展望未來的研究方向.

1 SGX 概述

SGX 是在原有Intel 架構上擴展了一組新的指令集和內存訪問機制[11],這些擴展能夠在計算平臺上提供一個可信的隔離空間,允許應用程序使用enclave[7]保障用戶關鍵代碼和數據的機密性和完整性,不受特殊權限惡意軟件的破壞[12].SGX 整體架構如圖1 所示.SGX 擴展指令集包括17 條新指令,其中5 條指令是用戶指令,包括進入enclave(EENTER)、退出enclave(EEXIT)、恢復enclave(ERESUME)、獲取密鑰(EGETKEY)和證明時獲取enclave 度量報告(EREPORT).其他12 條指令是系統指令,用戶通過操作系統的SGX 驅動(driver)調用執行,主要包括 enclave 創建(ECREATE,EADD,EEXTEND,EINIT)、enclave 異步退出(AEX)、enclave 銷毀(EREMOVE)、資源管理(EPA,ELDB/U,EWB,EBLOCK,ETRACK).因為enclave 的創建必須在內核空間中進行,而enclave 的交互僅限于用戶空間應用程序,特權代碼無法進入enclave,非特權代碼無法創建enclave.

所有的enclave 代碼和數據都存儲在EPC(enclave page cache)中,EPC 是一塊用來存放enclave 和SGX 數據結構[7]的被保護的物理內存區域,EPC 內存以頁為單位進行管理,對EPC 頁進行訪問控制的元數據信息保存在硬件結構EPCM(enclave page cache metadata)里.SXG 應用開發需要將應用程序分為可信和不可信兩個部分,兩部分之間通過用戶定義的Ecall 和Ocall 代碼進行調用.

Fig.1 Architecture description of SGX圖1 SGX 整體架構

1.1 SGX安全機制

SGX 旨在保護enclave 內計算的機密性和完整性,抵御惡意軟件攻擊和物理攻擊.SGX 技術主要包括隔離執行、認證(attestation)和密封(sealing)這3 個核心機制.本小節對SGX 的相關核心安全機制進行介紹.

1.1.1 隔離執行

SGX 的核心概念就是enclave,它是一個被保護的安全容器,用于存儲應用程序的敏感數據和代碼[13,14].Enclave 內除代碼和數據以外,還包括元數據和TCS(thread control structure),TCS 用于保存進入或退出enclave時恢復enclave 線程的特殊信息(如圖2 所示).EPC 是PRM(processor reserved memory)的一部分,PRM 則是內存的一部分,BIOS 通過配置一組范圍寄存器分配PRM,系統軟件或外圍設備無法訪問.

Fig.2 SGX sample layout of PRM and EPC圖2 PRM 和EPC 布局示意圖

圖2 是一個PRM 和EPC 布局示意圖.EPC 內存以頁為單位進行管理,對EPC 頁進行訪問控制的元數據信息保存在硬件結構EPCM 里,一個enclave 頁面對應一個EPCM 表項.通過處理器的訪問控制,可以保證每個EPC頁面只能映射到特定的虛擬地址,確保每一個EPC 頁只允許與其相關聯的enclave 訪問.

Enclave 中的代碼、數據和TCS 等在運行過程中始終被加密存儲在內存中.處理器緩存(cache)中的數據在寫到內存之前,處理器中的內存加密單元(memory encryption engine,簡稱MEE)會對其進行加密,因此操作系統無法直接獲取EPC 中的內容,保證了應用程序代碼和數據在運行過程中不受特權系統軟件的攻擊.SGX 的內存保護機制可以保證enclave 外部的應用程序不能訪問enclave 內存,enclave 內部的代碼在EPC 范圍內只能訪問屬于自己的內存,不能訪問其他enclave 的內存.這樣的內存保護機制防止了enclave 內部運行的程序被其他惡意軟件盜取和篡改隱私信息;同時,保證了在物理上鎖住EPC 內存區域,將外部的訪問請求視為訪問了不存在的內存,使得外部的實體(直接存儲器訪問等)無法訪問.

應用程序在申請創建一個enclave 時,需要進行頁面分配(ECREATE)、復制程序代碼與數據(EADD)和度量操作(EEXTEND).Enclave 被加載以后,需要進行完整性驗證,以判斷特權軟件在創建enclave 過程中是否篡改了程序和數據.在enclave 初始化之后(EINIT),不可信任的代碼(在enclave 外)執行可信代碼(在enclave 內)的唯一方法是調用EENTER 指令.EENTER 執行上下文切換到enclave,保存不可信代碼的狀態,并恢復可信代碼的最后已知狀態.該上下文切換在概念上類似于用于英特爾 VTX 技術中的虛擬機上下文切換的VMENTER 和VMEXIT[15].

SGX SDK 提供了封裝代碼,稱為ecall[16],用于準備執行環境并調用EENTER 指令.由于enclave 以用戶級權限運行可信代碼,因此enclave 無法訪問硬件或其他系統資源.為了訪問外部資源,例如文件系統、網絡或時鐘,enclave 必須退出到不可信代碼,它可以通過EEXIT 指令完成.EEXIT 執行反向上下文切換并切換回不可信的代碼.執行此操作的SDK 封裝代碼稱為ocall[16].為了避免泄漏隱私數據,正在執行enclave 代碼的CPU 不直接處理中斷、故障(例如頁面錯誤)或虛擬機退出.相反,CPU 首先執行AEX(asynchronous enclave exit)從enclave 代碼切換到非enclave 代碼,然后才處理中斷故障或VM 退出.

1.1.2 認 證

在enclave 初始化之前,代碼和數據是公開的,敵手可竊取和篡改.SGX 提供一個證明指令EREPORT 來抵御敵手竊取和篡改初始化之前的代碼和數據.具體地,enclave 通過調用EREPORT 產生一個硬件簽名的enclave 度量值報告,并發送給驗證方進行證明.SGX 支持本地認證和遠程認證兩種類型的身份認證方式[7,17]:本地認證用于平臺內部enclave 之間,用來認證報告的enclave 和自己是否運行在同一個平臺上;遠程認證則是用于平臺之間,用于遠程認證者認證enclave 的身份信息.

當enclave 向平臺上其他enclave 報告身份時,首先要獲取自身的身份信息和屬性以及平臺硬件TCB 信息,附加上用戶希望交互的數據,生成報告結構(report structure).然后獲取目標enclave 的報告密鑰,對報告結構生成一個消息認證碼(message authentication code,簡稱MAC)標簽,形成最終的報告結構,傳遞給目標enclave,由目標enclave 驗證請求報告身份的enclave 與自己是否運行于同一平臺.遠程認證則需要引入一個引用(quoting)enclave,由引用enclave 創建用于平臺認證的簽名密鑰EPID(enhanced privacy identification).被認證enclave 首先執行EREPORT 指令,將身份和附加信息生成報告結構,并利用引用enclave 的報告密鑰生成一個MAC 標簽,一起發給引用enclave.引用enclave 通過該結構驗證被認證enclave 是否運行于同一平臺,然后將它封裝為一個引用結構體QUOTE,并使用EPID 進行簽名,將QUOTE 和簽名一同發送給遠程認證者.遠程認證者驗證enclave報告是否由可靠的Intel 處理器生成.

1.1.3 密封

密封是指enclave 使用EGETKEY 指令獲取一個硬件產生的封裝密鑰對enclave 數據進行加密,并將加密數據存儲在enclave 之外不可信存儲中的過程[17].Enclave 數據根據enclave 的標識(MRENCLAVE)或簽名標識(MRSIGNER)進行密封,對MRENCLAVE 加密的數據只能由相同的enclave 解密,而對MRSIGNER 加密的數據可以由同一開發人員簽名的任何enclave 解密.在這兩種情況下,密封密鑰都來自特定于CPU 的密鑰,因此數據只能在它被密封的同一臺物理機器上打開.SGX 密封保證了密封數據的機密性和完整性,但不會自動提供回放(roll-back)保護.如果需要,enclave 開發人員必須檢查已提供的密封數據的版本是否正確,通常通過使用安全單調計數器(monotonic counter)來實現.

1.2 SGX管理機制

1.2.1 SGX 內存管理機制

Enclave 與主機程序共用一片虛擬地址空間,部分enclave 中映射到EPC 頁的虛擬內存稱為enclave 線性地址空間(enclave linear address range,簡稱ELRANGE).這段地址空間在EPC 分配終止后,對于主機進程來說是不能訪問的.任何試圖讀寫ELRANGE 地址空間的enclave 外部代碼都會產生一個未定義行為的錯誤.

Enclave 執行總是在受保護模式下,并由OS 內核或hypervisor 進行地址轉換.SGX 為了不影響傳統OS 對平臺資源的管理和分配,實現enclave 中的頁到EPC 中幀轉換的頁表(page table)仍由OS 管理[7].OS 和hypervisor完全控制頁表和擴展頁表(extended page table,簡稱EPT),enclave 代碼使用與其主機應用程序相同的地址轉換過程和頁表.由于操作系統或hypervisor 是不可信的,因此CPU 必須要防止對enclave 的地址轉換攻擊[10].當從EPC 頁地址轉換到物理地址時,CPU 使用在SGX enclave 控制結構(SGX enclave control structure,簡稱SECS)中存儲的初始分配信息來保證傳遞給地址轉換過程的EPC 頁虛擬地址與EPCM 中保留的EPC 入口地址相匹配.以此來防止操作系統將ELRANGE 地址映射到不受保護的內存,使得ELRANGE 內存對enclave 之外的軟件不可見.

1.2.2 EPC 頁驅逐(eviction)

操作系統可以將EPC 頁面驅逐到不可信的DRAM 中,并將其加載回來,如圖3 所示.系統軟件使用EWB 指令驅逐EPC 頁面,該指令產生ELDU 指令恢復被驅逐頁面所需的所有數據[7].SGX 通過加密(EGETKEY)來保證被驅逐的EPC 頁面存儲在不可信內存中時的機密性和完整性.EWB 和ELDU/ELDB 指令使用一個ID 來識別擁有被換出頁面的enclave.EWB 驅逐EPC 的內容時,會創建一個8 字節的隨機數,稱為頁面版本(page version).SGX 的新鮮度(freshness)保證則建立在安全存儲頁面版本的假設之上,因此,EWB 將其存儲在一個版本數組(version array,簡稱VA)中,VA 頁面也可以驅逐.被驅逐的頁面依賴于存儲其頁面版本的VA 頁面,在VA 頁面被重新加載之前無法被重加載到EPC 中.基于這種依賴關系創建的關系圖稱為驅逐樹(eviction tree).驅逐樹將EPC 頁面作為葉子,將VA 頁面作為內部節點.頁面的父節點是存儲其頁面版本的VA 頁面[7].

Fig.3 EPC pages evicted into non-PRM DRAM圖3 EPC 頁驅逐到非PRM 內存

1.3 SGX SDK

為了簡化SGX 應用程序的開發,Intel 發布了SDK[14].它向開發人員隱藏了SGX 硬件細節信息,并引入了ecall 和ocall 的概念,分別用于進入和退出enclave,如同普通的函數調用那樣.通過使用SGX SDK,開發人員可以創建加載到enclave 的代碼,并定義enclave 代碼與其他不可信的應用程序代碼之間的ecall 和ocall 接口.

Intel 提供了一個名為edger8r 的邊緣函數創建工具,用于自動生成ecall 和ocall 的安全封裝代碼.要自動生成ecall 和ocall 代碼,開發人員必須使用SGX 規定的語法,在enclave 描述語言(enclave description language,簡稱EDL)擴展文件中聲明ecall 和ocall 函數.然后,edger8r 解析EDL 文件生成封裝代碼,如圖4 所示.Ecall 和ocall被認為是邊緣函數(edge function),因為對它們的執行會跨越安全邊界.函數的參數需要編組(marshall),并從加密內存復制到明文內存,反之亦然.為了邊界交互的安全,需要對調用的參數執行多項安全檢查,特別是在參數是指針的情況下.Enclave 代碼必須驗證所訪問數據的完整性,如ecall 的參數、ocall 的返回值和從不可信內存讀取的數據.

Fig.4 Process of edger8r generates wrapper code from EDL file圖4 Edger8r 解析EDL 文件生成封裝代碼的過程

Enclave 支持多線程,因此需要同步原語.由于在enclave 內部無法進行睡眠等待,因此,SGX SDK 提供的enclave 內部同步原語實現了通過ocall 以在enclave 外部進行睡眠等待.SDK 提供的互斥鎖的工作方式如下:如果線程嘗試鎖定未鎖定的互斥鎖,則此操作成功完成而無需離開enclave.每當線程嘗試鎖定已鎖定的互斥鎖時,它將進入隊列并通過ocall 退出enclave 進入睡眠狀態;然后,持有互斥鎖的線程需要通過進入隊列并通過ocall離開enclave 來喚醒睡眠線程.因此,SGX SDK 提供的互斥鎖會導致兩次ocall,開銷比較大.

2 SGX 應用現狀及瓶頸問題

SGX 技術推出以來,受到了學術界和工業界的極大關注,目前在很多領域已經得到了廣泛的應用,如文獻[18]重點討論了SGX 在保障應用與網絡安全方面的應用研究進展.但是,SGX 在應用的同時也暴露出很多安全缺陷,如Wang 等人重點討論了針對SGX 的側信道攻擊和防御方面的研究進展[19].事實上,除了側信道問題,SGX應用還暴露出了許多其他安全性問題、性能瓶頸、開發困難、功能局限等諸多應用方面的問題.本節首先介紹SGX 目前的應用現狀,然后總結SGX 在應用中暴露出的諸多問題,最后對SGX 應用支持技術的研究方向進行總結.

從應用的場景來看,SGX 可以用于構建安全的云應用[20-22],用于保護網絡通信[23-27]以及增強本地應用的安全性[28-31].SGX 首先被應用在云計算安全領域,如構建云平臺應用安全隔離執行環境[32]、構建云平臺大數據安全可信計算環境[33,34]和對虛擬化技術的支持[35].例如,Hunt 等人提出的Ryoan 系統[32],利用enclave 實現了一個分布式沙箱來保護沙箱實例不受潛在惡意平臺的攻擊.Schuster 等人提出的VC3 框架[33],基于SGX 實現了保護代碼和數據的機密性和完整性mapreduce[36]框架.Brenner 等人提出的Securekeeper 框架[21],通過設計存儲數據的加解密方案和在enclave 中對數據處理的方式,實現了對管理數據隱私性和完整性的保護.Arnautov 等人設計了一個用于Docker[37]的安全容器環境SCONE[35],利用SGX 來保護Docker 容器內進程免受外部攻擊.微軟與英特爾協作利用SGX 以增強云中的安全性,幫助數據和代碼在使用過程中得到更強的保護[38].IBM 利用英特爾SGX 配合IBM Cloud Data Shield 以幫助保護使用中的數據[39].

SGX 也被用于保護網絡通信安全和本地應用安全.如在文獻[23]中,作者提出一種保護方案(S-NFV),利用SGX 對網絡功能虛擬化(network function virtualization,簡稱NFV)產生的狀態進行安全隔離保護.Andrew 等人提出的Haven 系統[30],通過修改Drawbridge 沙箱[40]實現了Windows 應用直接在沙箱中的enclave 內安全運行,為Windows 應用提供了安全保障.

除了應用于云計算、網絡通信和本地應用以外,許多解決方案都受益于SGX 提供的安全保護,包括多方計算[41]、機器學習[42,43]、區塊鏈[44-46]、人工智能和生物識別技術保護等.例如,文獻[44]介紹了一種基于SGX 區塊鏈資源挖掘框架REM(resource-efficient mining),REM 利用SGX 的安全保證實現了有效工作量證明(proof-ofuseful-work,簡稱PoUW),以提供可信的工作負載報告.UCloud 引入了SGX 技術,為智能合約提供了區塊鏈所不能提供的機密性,可拓展的計算節點也解決了區塊鏈本身無法應對復雜應用場景的問題.在保留區塊鏈去中心化、用戶互信的基礎之上,通過可信硬件執行機密性高、需要相對復雜計算能力的程序,并通過區塊鏈對執行結果進行記錄和驗證,實現可追溯的特性[96].Ekiden 同樣使用SGX 保證智能合約的機密性,并利用SGX 可信性提高區塊鏈的共識效率[47].螞蟻金服金融科技推出的可信計算云服務則是將螞蟻區塊鏈自主研發的虛擬機內嵌在SGX 可信執行環境中,在數據保密的通用鏈下能夠實現智能合約[48].

SGX 技術目前被廣泛地應用到各個領域,同時,SGX 技術在應用中也暴露了諸多瓶頸問題.如何解決SGX在應用中的瓶頸問題,也成為學術界的研究熱點.本文首先對目前SGX 技術相關應用和研究工作進行了梳理和總結,將SGX 技術應用的瓶頸總結為以下3 個方面.

? 應用安全問題.SGX 在TCB 大小、enclave 接口等SGX 應用程序設計方面存在諸多安全隱患,同時也面臨側信道攻擊、內存攻擊和硬件攻擊等傳統的安全威脅;

? 應用性能瓶頸.SGX 在內存加密、執行模式切換(包括ecall、ocall 和AEX)和內存頁替換等方面存在高昂的性能開銷,這嚴重制約了SGX 的應用和推廣;

? 應用開發的困難性和功能的局限性.Intel 公司提供的SDK 雖然簡化了SGX 的使用,但仍需程序員手動地將應用程序劃分為可信和不可信兩部分,不能直接無縫對接原有的應用程序,導致SGX 應用程序的開發工作量很大.SGX 提供了強大的安全功能,但對虛擬機遷移和容器等云平臺常用技術支持不足,難以滿足當前云平臺應用對SGX 的需求.

針對SGX 技術的上述應用瓶頸問題,工業界和學術界進行了具體的分析,并提出了相應的解決方案.本文總結了相關文章,主要包括CCS、S&P、NDSS 等頂級會議,對這些工作進行了總結和分類,見表1,主要可以分為三大類.

Table 1 Related researchs of SGX application supporting techniques表1 SGX 應用支持技術相關研究工作

? 安全增強:分析SGX 應用存在的安全風險和面臨的安全威脅,并提出增強SGX 應用安全性的相關方案.目前,SGX 應用安全增強方案主要有TCB 最小化、對外接口最少化、敏感代碼安全生成與檢測和潛在安全威脅的分析與防護等;

? 性能優化:分析SGX 性能開銷的原因,并提出相應的性能優化方案.目前,改進SGX 應用性能的解決方案主要包括減少模式切換(enclave 切換)開銷、減少頁替換開銷以及減少對enclave 內存頁的使用和訪問等;

? 易用性改進:主要包括SGX 應用輔助開發技術和功能擴展技術.應用程序輔助開發技術主要包括安全開發語言、輔助開發工具以及通用系統庫和函數庫等;功能擴展則主要包括對虛擬機遷移和容器等云平臺常用技術的支持方案等.

通過上述對SGX 應用支持技術研究現狀的總結和分類,可以將SGX 應用程序支持技術的目標歸納為安全、性能和易用性這3 個方面.這3 個目標不是相互獨立的,而是互相關聯和影響的,如TCB 大小就會關系到應用的安全和性能.

本節首先介紹了SGX 技術的應用研究現狀,分析了SGX 應用中暴露出的安全性問題、性能瓶頸、開發困難、功能局限等諸多方面的問題,然后將SGX 應用支持技術的研究方向概括為SGX 應用安全增強技術、SGX應用性能優化技術、SGX 應用程序輔助開發支持技術和SGX 應用功能擴展技術這4 個方向.本文第3 節～第6節將分別從這4 個方面進行詳細的分析和總結.

3 SGX 應用安全防護技術

SGX 通過一系列技術來保護程序的安全,并且將系統的可信計算基縮小到CPU,相比以往將整個操作系統或特權軟件(如hypervisor)視為可信計算基,可以避免更多的系統攻擊帶來的危害.但是SGX 在實際應用中依然會面臨諸多的安全風險,如過大的TCB 和暴露過多的外部接口等.本文將SGX 應用程序設計和開發時需要考慮的安全風險歸納為以下4 個方面.

? TCB 的大小.有研究[70,71]表明,軟件漏洞的數量以及潛在的安全漏洞會與代碼大小成比例地增加.盡可能地減小TCB,可以有效地減少enclave 內部代碼漏洞潛在的安全風險;

? 外部接口的多少.由于enclave 需要與不可信區域進行交互,外部接口就成為不可信操作系統的攻擊面,控制主機操作系統的攻擊者可以使用此接口來破壞在enclave 內運行的進程或者推測出敏感信息.因此,設計enclave 程序時需要考慮到該隱患;

? 開發的工作量和可靠性.SGX 程序開發最重要的是需要將代碼劃分為敏感和非敏感兩部分,SGX SDK目前不支持現有的應用程序直接運行在SGX 環境中,SGX 程序開發需要經驗和時間,并且不合理的敏感代碼劃分可能會破壞enclave 代碼的安全性.因此,開發時需要充分考慮敏感代碼劃分的工作量和可靠性;

? 面臨的安全威脅.有研究表明,SGX 面臨著側信道攻擊[9-11]、內存攻擊[55,72]等多種攻擊的威脅.開發SGX 應用程序時也需要考慮到這些安全威脅.比如,enclave 中的數據處理過程如果依賴于外部數據,攻擊者可以通過一些不合法輸入,發起對enclave 的緩沖區溢出攻擊,這些攻擊可能會改變可信區中程序的執行流程以及獲取可信區中的敏感信息.

針對SGX 目前在應用中存在的上述安全問題,工業界和學術界提出了很多解決方案,本文對相關解決方案進行了梳理和總結,具體分類如下.

? TCB 最小化.SGX 應用程序的TCB 由enclave 代碼和可信硬件組成.根據最小特權原則[73],只有應用程序中需要訪問敏感數據的代碼才應在enclave 內執行.最小化TCB,可以保證enclave 內部代碼面臨盡可能少的威脅;

? 對外接口最少化.除了TCB 大小外,enclave 對外接口的復雜性同樣會影響enclave 內部代碼和數據的安全性.減小enclave 和不可信操作系統之間的接口,可以減小暴露的攻擊面,從而減小攻擊者成功攻擊的可能性[70];

? 敏感代碼的安全生成與檢測.利用自動化的開發工具對SGX 應用程序的代碼進行自動劃分,可以極大地減少開發人員的工作量;通過對enclave 代碼進行安全檢測,可以有效地增強敏感代碼的安全性;

? 潛在的安全威脅防護.本文針對常見的潛在安全威脅進行了分析和總結,并給出了目前研究中已有的防護方案和相關的開發建議.

本節下面將對這4 類方案進行詳細的介紹和分析.

3.1 TCB最小化

3.1.1 TCB 安全風險分析

本小節首先來分析TCB 大小對SGX 應用程序安全性的影響.目前使用SGX 的應用在TCB 中enclave 代碼部分的大小設計方面有3 種選擇.

? 預定義的少量專用敏感代碼:將盡可能少的代碼放入enclave 中,一般只將需要直接處理敏感數據的代碼放入enclave 中,如VC3[33],只將處理數據的map/reduce 函數放入enclave,而將其他不完全可信的平臺代碼排除在enclave 外,這樣可以避免平臺可能存在的安全漏洞威脅enclave 內代碼和數據安全;

? 完整的應用程序及其依賴的庫:將應用程序和enclave 內程序運行時所依賴的系統庫和函數庫等部署在enclave 內,如Haven[30]、SCONE[35]和Graphene[51]等系統,采用的方案是,在enclave 內部署函數庫或系統庫來支持執行完整的應用程序.安全敏感和不敏感的應用程序代碼和數據都位于enclave 內,提高了性能,但從TCB 的角度來看,卻增加了enclave 內部代碼和數據面臨的安全風險;

? 從特定應用中劃分出敏感代碼:將應用程序中的敏感代碼劃分出來作為TCB,這里的敏感代碼除直接處理敏感數據的代碼外,還可能包括其他間接處理敏感數據的代碼以及與enclave 內部代碼交互頻繁的代碼等.這類方案需要程序開發人員手動劃分應用程序,開發工作量大,并且劃分敏感代碼缺乏參考標準,如果敏感代碼劃分得不夠合理,可能會破壞enclave 內代碼和數據的安全性.

另外,目前SGX v1 版本支持的enclave 最大為128M(應用程序實際能使用約93M),一旦TCB 大小超過93M,就會觸發頻繁的頁替換,增加了安全風險和性能開銷.SGX v2 有可能進一步擴展SGX 的可用物理內存,但目前Intel 官方還未發布相關資料.

3.1.2 最小化TCB 的安全方案

最小特權原則下,應該最小化TCB,從而減少enclave 內部漏洞造成的威脅.最小化TCB 的相關安全方案一般僅把支持功能,或者敏感部分放入enclave.應用程序必須遵守預定義的受限制的enclave 接口[21,33,49].這些工作的核心是使用SGX 提供的enclave 保證運算的機密性,同時保證enclave 盡可能地小.

Schuster 等人提出的VC3 系統[33]就是采用了最小化TCB 的設計方案.VC3 使用分布式系統Hadoop[36]中計算節點提供的enclave 來保護map/reduce 任務的代碼和數據,并嚴格限制map/reduc 任務僅通過特定的接口與不可信的環境進行交互.VC3 將未經修改的Hadoop 和操作系統均排除在TCB 之外,最小化了TCB,從而減少了enclave 內部代碼和數據面臨的安全風險.因此,即使Hadoop 和操作系統受到損害,也可以保證map/reduce 任務代碼和數據的機密性和完整性.并且,VC3 通過部署協議以保護分布式MapReduce 計算結果的安全性和可驗證性.VC3 在TCB 最小的情況下,保證了數據和代碼的完整性和機密性,并保證了計算結果的可驗證性,但是由于map/ reduce 任務只能通過特定的接口與不可信環境交互,因此其支持的功能非常有限.

Brenner 等人提出的保證所管理數據的隱私性和完整性的ZooKeeper[74]框架Securekeeper[21]同樣采用最小化TCB 的設計方案.SecureKeeper 系統通過設計所存儲數據的加解密方案和在enclave 中對所管理數據進行處理的方式,將輕量修改的ZooKeeper 和操作系統排除在TCB 之外,將系統的TCB 保持在很小的水平,從而使在不可信環境下數據的隱私性和完整性得到了有效的保證.

Shinde 等人提出的PANOPLY 系統[49]旨在最小化SGX enclave 應用程序TCB,同時又能為enclace 代碼提供豐富的操作系統抽象.PANOPLY 提出了一種稱為微容器(micro-container or micron)的新概念,微容器是運行在enclave 中應用程序的邏輯單元,微容器將標準的Linux 抽象提供給應用程序.例如,除支持標準Linux 系統調用外,啟用微容器的應用程序還可以使用多進程、多線程、事件注冊/回調(例如信號).PANOPLY 可以將應用程序分成一個或多個微容器,或者通過導入微容器庫來增強安全性,如圖5 所示.同時,PANOPLY 保證enclave 間交互的完整性,確保即使操作系統出現異常,應用程序的執行也仍然遵循合法的控制和數據流.

PANOPLY 將最小化TCB 優先于性能作為目標.與以前的系統(例如操作系統庫解決方案SGXKernel[50]、Graphene[51])不同,PANOPLY 使用了一種簡單的委托而不是模擬的設計理念,將操作系統抽象的實現委托給底層操作系統,而不是在enclave 內進行仿真.PANOPLY 微容器只需要通過執行少量檢查來抵御操作系統的惡意響應.這種設計消除了在enclave 內模擬基礎操作系統的大量工作.通過這種設計,PANOPLY 提供的應用程序TCB 比以前的操作系統庫系統的數量級小2 個數量級.

Fig.5 Panoply system overview圖5 Panoply 系統概況

3.2 對外接口最少化

3.2.1 Enclave 接口的安全風險分析

由于enclave 處于用戶態,自身無法執行系統調用,需要與不可信區域進行交互,enclave 必須向主機操作系統公開外部接口.外部接口則會成為不可信操作系統的攻擊面,控制主機操作系統的攻擊者可以使用此接口來破壞在enclave 內運行的進程并推測敏感信息,增大了安全風險和性能開銷.如Iago 攻擊[75],這是來自不受信任的操作系統對應用程序的語義攻擊,其中未經檢查的系統調用返回值或許會影響應用程序.Iago 攻擊難以進行全面檢測,至少對于當前的可移植操作系統接口(portable operating system interface,簡稱POSIX)[76]或Linux 系統調用表接口而言是這樣.因此,任何SGX 框架都必須提供隔離支持,以驗證或拒絕來自不受信任的操作系統的輸入.接口復雜性直接影響隔離的復雜性,如操作系統庫或填充(shim)庫可以減小enclave 接口的數量和復雜性,從而降低Iago 攻擊成功的風險.

總之,系統調用的返回值必須進行檢查以防止Iago 攻擊.創建有原則的enclave 接口可以更容易地抵御特定攻擊.決定是否采用特定方案,使用enclave 保護應用程序安全的重要判定原則是開發工作量及其是否適用于任何應用程序.目前主要有3 種enclave 接口方案.如圖6 所示.

Fig.6 Design alternatives for the use of enclaves圖6 Enclave 設計選擇方案

? 完整的enclave 接口:在enclave 為應用程序提供完整的系統庫支持,減少enclave 與不可信的系統之間的交互,如在enclave 提供庫支持.例如,Graphene[51]是在enclave 中使用一個操作系統庫來支持快速部署未修改的Linux 應用程序;

? 預定義的enclave 接口:如圖6(b)所示,遵守預定義的受限制的enclave 接口.例如,VC3[33]強制map/reduce 任務僅通過特定的接口與不可信的環境進行交互;

? 特定應用程序的enclave 接口:如圖6(c)所示,針對特定的應用程序劃分可信與不可信代碼,并設計相關的enclave 接口.該方案開發要求高、工作量大,且無法在應用程序之間通用.

3.2.2 減少對外接口的安全解決方案

減少enclave 接口方案一般會在enclave 內設置操作系統庫或者標準函數庫來支持enclave 內應用程序的執行,從而減少enclave 內代碼與操作系統之間的交互,例如Haven[30]、SGXKernel[50]、Graphene[51]和SCONE[35]等等.

Haven[30]使用Drawbridge[40]操作系統庫直接運行未修改的Windows 應用程序.Haven 基于drawbridge 沙箱機制,為用戶程序的運行提供了一個微處理(picoprocess)容器,從而保證運行在里面的用戶程序無法對外界系統造成破壞;再在容器中創建一個enclave,將用戶程序、系統庫和防護模塊(shield module)放進enclave 中,以防止這些數據和代碼被外界的特權軟件或惡意程序所訪問和篡改.系統庫通過向下調用(downcalls)和向上調用(upcalls)的方式與drawbridge 主機進行交互,用來完成用戶程序需要的系統功能,防護模塊配合檢查函數的參數和返回結果,進而保護用戶程序的安全執行.

Graphene[51]則是在enclave 中部署一個操作系統庫來支持在SGX 上快速部署未修改的Linux 應用程序.Graphene 為SGX 提供了一個端口以及一些SGX 改進措施,例如動態加載庫(dynamically-loaded libraries)的完整性支持和安全多進程(secure multi-process)支持.Graphene 開銷與使用填充層(shim library)的應用程序相近,大多數單進程應用的性能開銷小于2 倍,Graphene 目前已經開源.SGXKernel[50]也是在enclave 內實現了一個操作系統庫,通過結合異步交叉enclave 通信和可搶占的enclave 多線程避免enclave 切換,其性能明顯優于Haven和Graphene.SCONE[35]則是在enclave 中配置了標準C 函數庫的修改版本來支持重新編譯的Linux 應用程序.

文獻[64]在enclave 接口的安全設計方面給出了3 個建議.

(1)SDK 允許將ecall 定義為公有或私有[16]:公有ecall 可以隨時被調用,而私有ecall 只能在ocall 中被調用.將ecall 定義為私有可以限制調用ecall 的途徑來增強enclave 的安全性;

(2)開發人員必須精確指定每個ocall 中允許哪些ecall 調用.如果沒有指定特定的ecall,則在執行期間會觸發錯誤.如果開發人員未考慮特定的ecall/ocall 組合,則攻擊者可能會利用它來更改程序執行的控制流并獲得對特定機密的訪問權限;

(3)EDL 文件定義了作為ecall 和ocall 參數傳遞的指針的行為,其中,user_check 標明是否將指針留給開發人員.然而,user_check 可能帶來安全漏洞,例如緩沖區溢出、time-of-check-to-time-of-use 攻擊[77]或傳遞enclave 內地址[78].因此,在進行enclave 接口設計時,需要檢查并限制指針如何在enclave 接口中傳遞和使用.

3.3 敏感代碼的自動化生成與安全檢測

SGX 應用程序開發的關鍵是將應用程序劃分為敏感代碼與非敏感代碼兩部分,到底將哪些代碼作為敏感代碼放入enclave 中目前還缺乏標準化的方法,并且劃分的敏感代碼是否安全和合理也缺乏相應的驗證方法.總的來說,SGX 應用程序開發所面臨的困難主要有以下3 個方面.

? 開發工作量大:針對每一個應用程序進行開發,不僅需要開發人員具備豐富的開發經驗和安全背景,同時也需要進行大量的開發工作;

? 通用性:目前需要開發人員針對每一個應用程序進行手動劃分,缺乏通用性的解決方案.當前,SGX SDK 沒有提供相關支持;

? 敏感代碼劃分的合理性和安全性:劃分的敏感代碼需要進行安全性和合理性驗證,以確認劃分出的敏感代碼是否存在安全漏洞.

因此,如何對enclave 的敏感代碼進行自動化劃分且保證劃分結果的可靠性,是SGX 應用程序開發需要解決的問題.目前,相關工作分別實現了對程序敏感代碼的自動化劃分和對enclave 代碼的安全檢查等.

3.3.1 敏感代碼自動劃分技術

文獻[52]提出了一個用于開發C 語言SGX 應用程序的源碼劃分框架Glamdring.通過開發人員對安全敏感應用程序數據的注釋,Glamdring 可以自動地將應用程序劃分為可信和不可信代碼兩部分,如圖 7 所示,Glamdring 的操作分為4 步.

(1)代碼注釋:開發人員通過注釋需要機密性和完整性保護的變量來提供有關安全敏感數據的輸入和輸出信息;

(2)代碼分析:Glamdring 基于帶注釋的源代碼,使用數據流分析來識別可能處理敏感數據的函數,并使用向后切片來識別可能會間接影響敏感數據的函數.將直接或者間接訪問或者影響敏感數據的代碼標記為敏感代碼.因此,Glamdring 獲得了處理敏感數據或影響其完整性的最小代碼集;

(3)代碼劃分:接下來,Glamdring 創建一個劃分規范(partition specification,簡稱PS),該規范定義了必須由enclave 保護的代碼.PS 會根據程序分析枚舉敏感的函數、內存分配和全局變量;

(4)代碼生成:Glamdring 使用源到源編譯器(source-to-source compiler)基于PS 將代碼分為敏感和非敏感的代碼,然后將敏感代碼放置在enclave 內,并在enclave 邊界自動添加運行時檢查和加密操作,以保護其免受攻擊.

Fig.7 Overview of the Glamdring framework圖7 Glamdring 架構

Glamdring 保護了敏感輸入數據的機密性和敏感輸出數據的完整性,基于最小特權原則,最小化訪問敏感數據的代碼,自動更改應用程序代碼,極大地減少了程序開發人員的開發工作量,增強了SGX 的易用性.Liu 等人則在其源碼自動劃分方案PtrSplit[79]中,提出了一系列支持全局指針的方法.

3.3.2 Enclave 代碼安全檢測技術

SGX 可以為enclave 內部代碼和數據提供機密性和完整性保護,以抵御來自enclave 外部的攻擊.但是enclave 代碼本身的漏洞也可能會泄露機密,例如enclave 可能受到Heartbleed[80]之類的攻擊,這些攻擊已被證明會從內存中泄露秘密密鑰.開發人員也必須采取必要的措施來抵御協議和應用程序攻擊,包括正確使用SGX 指令、使用安全的加密協議、避免由于違反內存安全性而造成錯誤等.

文獻[53]開發了一個靜態enclave 代碼安全性驗證工具Moat,用以驗證enclave 代碼是否滿足機密性要求,即是否存在將秘密泄露給敵手可見的非enclave 內存的代碼.Moat 分析了enclave 二進制代碼的指令級行為,采用信息流敏感類型檢查算法自動驗證enclave 程序是否提供機密性保證.對于類型錯誤的程序,Moat 會利用漏洞程序證明機密可能會泄露給非enclave 內存.Moat 為程序員編寫安全的enclave 提供了驗證方法和工具支持.

3.4 潛在安全威脅的分析與防護

SGX 原則上能夠提供安全的隔離計算環境,但實際上同樣面臨各種各樣的安全威脅,比如側信道攻擊、內存攻擊和回放攻擊等.當前,學術界的相關工作也已經進行了證實[9-11,77].針對每類攻擊,相關研究工作提出了一系列防御措施,但目前仍缺少通用的解決方案.因此,需要SGX 應用開發人員在開發SGX 應用程序時充分考慮相關的安全威脅,并采取一定的防御措施.

3.4.1 側信道攻擊和防護方案

SGX 面臨的最大威脅是側信道攻擊.側信道攻擊的主要手段是通過攻擊面獲取數據,推導獲得控制流和數據流信息,最終獲取enclave 的代碼和數據的信息,比如加密密鑰、隱私數據等.Wang 等人對相關的SGX 側信道攻擊進行了詳細的分析和總結[19].本文只介紹典型的攻擊面,包括頁表、緩存(cache)以及CPU 內部結構,這幾種側信道攻擊的方式如下.

? 基于頁表的攻擊:利用頁表對enclave 頁面的訪問控制權,設置enclave 頁面為不可訪問.之后,任何訪問都會觸發缺頁異常,從而能夠區分enclave 訪問了哪些頁面.按照時間順序把這些信息組合,就能夠反推出enclave 的某些狀態和保護的數據.該類攻擊包括controlled-channel 攻擊[10]和pigeonhole 攻擊[11]等;

? 基于Cache 的攻擊.在SGX 環境中,大部分基于Cache 的側信道技術仍然適用,例如文獻[81]證明,SGX易受Cache-timing 攻擊;

? 基于CPU 內部結構的攻擊.CPU 內部有大量的結構是在enclave 和非enclave 之間共用的,這就給側信道攻擊提供了大量的攻擊面,例如文獻[82]實現的側信道攻擊.

這些側信道攻擊有的需要從SGX 設計的角度來解決,有的則可以在應用程序內部進行解決.更加合理地設計應用程序,可以減少攻擊者能夠收集的有效信息,極大地降低攻擊者成功攻擊的幾率.SGX 現有的部分側信道防御方法可以按照不同層次進行分類,主要包括:

? 軟件層:應用程序可以進行自我防御,通過合理地設計應用程序,避免泄露過多的差異信息,使得攻擊者難以成功.例如:像Opaque[34]等分析平臺通過內部混淆讓攻擊者無法獲取相關的差異信息,有效地保護了enclave 內部數據的安全性;Chandra 等人提出的方案[42]在訓練機器學習模型時充分考慮到了側信道攻擊,將決策樹的數據結構進行重新設計,保證敵手無法觀察到差異信息,以避免應用程序泄露相關模型信息;ORAM[83]技術同樣通過無差別的訪問等方法避免泄露差異信息,從而有效地抵御SGX 面臨的側信道攻擊,但是目前在性能方面仍然需要加以提高;

? 硬件層:通過優化SGX 硬件設計,可以避免某些側信道攻擊.例如,在enclave 的切換過程中,CPU 清除共用的內部結構體信息,避免非enclave 得到任何殘留記錄.同時還要注意一些細節,比如清除的時間也必須是穩定不變的[82].硬件層為每個enclave 隔離出一個cache,也是側信道攻擊的解決方案之一,雖然文獻[84]已經進行了一些嘗試,但仍然還未能徹底解決該問題.

3.4.2 內存攻擊和防護方案

基于SGX 的隔離執行,為應用程序在不可信平臺上的運行提供了強大的安全保障.但是隔離執行不能保護程序免受內存攻擊[72],這些攻擊很普遍,特別是用非安全語言(如C/C++)編寫的應用程序.例如,Heartbleed[80]之類的內存安全攻擊可能會使隔離執行的機密性和完整性保障完全失效.遠程攻擊者可以通過利用現有的程序漏洞來調用越界內存訪問,以破壞內存安全性.然后,攻擊者可以劫持程序控制流程或泄露機密數據[85].

所有內存攻擊的基礎條件是能夠訪問禁止訪問的內存區域,因此,可以通過邊界檢查技術[86]限制enclave 程序可訪問的內存范圍.具體地,為每個分配對象的邊界維護數據結構用于邊界檢查,確認指針是否仍在邊界范圍內.但是該數據結構可能會變得很大,并且查找成本很高.文獻[55]基于SGX設計了一種用于enclave 的高效邊界檢查技術,可有效抵御來自于enclave 內部漏洞的威脅,并且結合標記指針和緊湊內存布局來提高性能.

3.5 小結

本節總結的以上4 種SGX 應用安全防護技術概括了目前常見的SGX 應用安全增強方案,為了更加直觀地表述每一種技術的優缺點和性能,本小節給出如下總結(見表2).通過分析這4 種常見的SGX 應用安全增強技術的方案與優劣性,可以將這4 種技術的研究總結為以下3 個方面.

? 最小化TCB 和最少化對外接口,都可以降低SGX 應用面臨的安全風險.但是兩者之間存在一定的沖突,例如,要最小化TCB 就難以提供enclave 內部豐富的系統調用支持,難以做到最少化對外接口.目前缺少能夠自動平衡TCB 大小和對外接口的開發工具,主要還是依賴程序員的開發經驗來設計TCB 和enclave 接口.同樣,也缺乏能夠兼顧兩個方面的安全增強方案;

? 敏感代碼自動劃分工具能夠減少程序員的工作量,但其劃分結果的準確性和可靠性難以驗證,而且目前也缺乏普遍認可的劃分標準.如何更準確、更可靠和更細粒度地自動劃分應用程序,是需要實現的目標;

? 開發人員設計SGX 應用程序時應該充分考慮到側信道攻擊等未知安全威脅,根據不同的場景進行相應調整,以抵御可能面臨的安全威脅.這需要開發人員具有足夠的安全知識,當前還缺乏自動化支持工具以輔助開發人員實現對潛在安全威脅的抵御.

Table 2 Security enhancement solutions of SGX application表2 SGX 應用安全增強方案

4 SGX 應用性能優化技術

SGX 性能一直是學術界和工業界關注和研究的重要方向之一,也是制約SGX 應用的重要因素.對SGX 性能進行優化是必不可少的.相關研究[21,35,56-58]分析了SGX 潛在的性能問題,并提出了多種技術來優化SGX 性能.本文總結了優化SGX 性能相關的研究工作,將SGX 性能開銷的問題和相關原因概括為以下幾個方面.

? 模式切換開銷.模式切換即enclave 切換,原因主要包括ecall、ocall 和AEX.模式切換出于安全原因,必須執行一系列檢查和更新,包括TLB(translation lookaside buffer)刷新,基于內存的enclave 參數也必須在可信和不可信的內存之間進行復制,從而導致模式切換需要付出高昂的代價;

? Enclave 頁替換開銷.內存要求超過EPC 大小的應用程序必須在EPC 和未受保護的內存之間替換頁面.EPC 頁換出的代價高昂,因為它們必須在被復制到外部內存之前被加密并得到完整性保護.為了防止地址轉換攻擊,替換協議中斷所有enclave 線程并刷新TLB.并且,頁替換同樣會導致enclave 模式的切換.在enclave 執行期間的頁替換,由于額外的轉換和加密操作而開銷巨大;

? 內存加密開銷.由于MEE 必須加密和解密高速緩存線,會導致加密內存訪問存在高昂的開銷,enclave代碼也會由于寫入內存和高速緩存未命中而產生開銷.

針對上述開銷原因,相應地,本文將目前SGX 性能優化方案也總結為3 種技術——模式切換性能優化技術、內存頁替換優化技術和內存加密優化技術.

? 模式切換開銷優化技術.模式切換需要付出高昂的代價,因此應盡量避免模式切換,可以通過異步調用[56-58]來加以避免;

? 頁替換開銷優化技術.頁替換的開銷很大,應盡量避免頁替換,可以通過多種技術來減少頁替換.如盡量將enclave 保持得較小,通過EPC 頁面預加載以避免enclave 內部發生頁錯誤,在enclave 內部使用替換的內存管理機制,如STANlite[20]和Eleos[58];

? 內存加密開銷優化技術.內存加密開銷是因SGX 的內存加密保護機制所致,可以通過減少對enclave內存的不必要使用、使用節省空間的數據結構或將較小的數據塊加載到enclave 來進行優化.

4.1 模式切換性能優化技術

模式切換是SGX 能夠在enclave 中執行代碼的基本保障機制,但是模式切換也是SGX 應用程序性能開銷的主要原因,尤其是對于系統調用密集型SGX 應用程序而言,導致的開銷會達到幾倍、幾十倍甚至上百倍.只要CPU 進入或退出enclave,就會發生模式切換.模式切換開銷的主要原因是復雜的狀態保存和安全檢查、保存和恢復CPU 狀態以及由刷新TLB 引起的TLB 緩存未命中.

SGX SDK[16]提供的用于進行跨enclave 函數調用的標準方法ecall 和ocall 都會觸發enclave 上下文切換.文獻[35,44,50]分別對SGX 的ecall 和ocall 的性能開銷進行了評測.任何ecall 和ocall 都會導致性能開銷,因為硬件必須執行某些操作來維護SGX 的安全保障.Enclave 代碼還必須驗證所訪問數據的完整性,例如ecall 的參數、ocall 的返回值和從不可信內存讀取的數據.本文對評測結果進行了總結,具體見表3.從表中總結結果來看,直接使用SGX SDK 的邊緣函數性能開銷高達8 000 到17 000 個時鐘周期(CPU cycle).Ecall 的開銷大約為8 000個時鐘周期,ocall 的開銷大約為10 000 個時鐘周期,這相比于系統調用150 個時鐘周期來說是非常高的.因此,減少模式切換導致的開銷變得非常重要.目前,避免或降低模式切換的技術主要有通過共享內存和專用線程避免切換、增加庫操作系統來減少切換操作以及合理地設計enclave 接口.

Table 3 SGX ecall and ocall performance evaluation表3 SGX ecall 和ocall 性能測試

文獻[64]則在3 種設置中直接測量了EENTER 和EEXIT 指令的時間開銷:(1)在未修改的支持SGX 的處理器上,使用一個熱高速緩存(warm cache)進行了一次往返,測得的切換時間約為5 850 個時鐘周期(約為2 130ns);(2)SDK 更新修復Spectre[87]漏洞補丁(patchs)后(該漏洞影響了SGX[88]),測得的切換時間約為10 170個時鐘周期(約為3 850ns),是沒有補丁情況下切換時間的1.74 倍;(3)更新修復Foreshadow[89]漏洞的補丁后,在同時抵御Spectre 和Foreshadow 漏洞的情況下,enclave 切換變得更加緩慢,約為13 100 個時鐘周期(約4 890ns),約2.24 倍,這些測試結果進一步說明了避免模式切換的必要性.

4.1.1 無切換調用

為了最大限度地降低模式切換帶來的性能損失,文獻[35,56-58]分別提出了解決方案,這些方案具有相同的核心思想:調用線程將ecall/ocall 的請求發送到共享的不可信緩沖區,工作線程則從該緩沖區異步接收和處理請求.由于采用這種方式調用eall/ocall 不會觸發模式切換,故稱為無切換調用(switchless calls)[57].如文獻[56]提出一個由請求者和響應者組成的體系結構HotCalls,通過未加密共享內存進行通信,采用同步自旋鎖機制,相比于SGX 默認的接口加速13～27 倍.

Eleos[58]則采用遠程過程調用(remote procedure call,簡稱RPC)的方式處理系統調用,RPC 機制允許在不退出enclave 的情況下,將調用阻塞到不可信代碼中執行,實際調用被委托給工作線程,該工作線程在enclave 所有者進程的不可信內存區域中執行.由于enclave 可執行多個線程,因此,Eleos 維護一個具有多個工作線程的線程池,通過位于不可信內存中的共享作業隊列與enclave 交互.線程池中的線程輪詢隊列,調用請求的函數,并通過不可信的共享緩沖區傳回結果.因為enclave 的線程不能使用互斥等標準的OS 同步原語,可信和不可信上下文之間的同步是通過輪詢執行的.為了降低輪詢成本,Eleos 通過簡單的ocall 機制調用長時間運行的系統調用.

上述通過使用共享內存作為通信信道和專門設置線程輪詢消息的方案被證明是有效的,但是這種無切換調用技術在效率方面存在疑問,用額外的CPU 內核來減少模式切換未必總是合理的.無切換調用必須由工作線程執行,因此需要額外的CPU 內核.實現的加速比隨著工作量的減少而減小.在幾乎空閑的工作負載的極端情況下,使用的額外CPU 內核顯然是浪費資源的.文獻[56]建議:如果工作線程長時間沒有收到任何請求,則將其置于休眠狀態.但是,可能存在請求稀疏卻不足以觸發超時睡眠的情況;并且,是否喚醒休眠工作線程處理一個或兩個請求然后再次睡眠也存在疑問,這種情況下,浪費CPU 問題變得更加嚴重.工作線程使用額外CPU 核心可能已用于為同臺機器上其他應用程序的線程.由于上述原因,enclave 應用程序會遇到各種動態工作負載,是否采用無切換調用則需要進一步加以分析.

Intel 的研究團隊將無切換調用作為一種實用技術,確保它能夠有效地提高性能[57].通過數學和模擬分析建立性能模型,研究無切換調用可以有效提高性能的條件,并設計了一種基于效率的調度算法,該算法可以自動調整工作線程數量以響應不斷變化的工作量.Intel 公司目前已將無切換調用及其優化算法集成到SDK,從SDK 2.2 開始,正式提供這一功能.

4.1.2 增加操作系統庫/函數庫減少模式切換

SGX 提供了強大的安全保證,但SGX 的一個限制是enclave 內缺乏系統調用支持,這導致SGX 在性能方面并不理想.為解決這一問題,Haven[30]、SGXKernel[50]和Graphene[51]通過提供用于enclave 執行的兼容層,為SGX內部的應用程序提供操作系統庫支持,無需修改應用程序代碼.

SGXKernel[50]在enclave 內部提供了一個操作系統庫,從而可以減少enclave 切換,使應用程序不再需要進行頻繁的模式切換.這種減少模式切換的設計是通過結合兩個設計實現的:即異步進行enclave 通信和可搶占的enclave 內部多線程.Graphene[51]除了提供一個操作系統庫支持之外,還提供了一些使SGX 更加可用的改進措施,例如動態加載庫的完整性支持以及安全的多進程支持,有效地減少了模式切換.

4.1.3 輕量級細粒度的并行減少enclave 之間模式轉換

文獻[60]提出了一個針對SGX 的框架EActors,提出新的概念actor,實現輕量級細粒度的并行,從而避免了SGX SDK 提供的同步功能的高開銷問題,解決了enclave 內部和多個enclave 之間執行模式轉換的高開銷問題.最后,EActors 提供了基于安全和性能要求的高度選擇自由來執行可信或不可信的actor.性能評估結果表明:基于EActors 實現的安全消息傳遞服務與基于SGX SDK 實現的版本性能提高了40 倍,EActor 可以更加無縫、靈活和高效地使用SGX,特別是對于需要多個enclave 的應用程序.

4.2 內存頁替換開銷優化技術

Enclave 性能開銷高的另一個重要原因是enclave 內存空間比較小,尤其是應用程序本身可用工作空間比較小.Enclave 所在的EPC 大小有限,當前SGX v1 最大可設置為128M,實際約93M 可供應用程序使用,其他空間用于存儲完整性保護的元數據[7].SGX 支持從EPC 到主內存的頁替換,以滿足不適合EPC 的enclave.當程序代碼數量和規模增大時,敏感頁面會在內存中的EPC 和非EPC 區域之間頻繁交換.Enclave 執行期間的頁替換開銷巨大(約4 萬時鐘周期),因為它需要進行系統調用、頁面復制、完整性樹和元數據的更新等.文獻[59]分析表明:頁替換開銷使系統平均減慢5 倍,內存密集型應用的速度更慢,對enclave 的性能有很大影響[21,35].

頁替換會導致過高的性能開銷,因此,enclave 設計應盡可能地避免遇到頁替換.本文分析了頁替換開銷的原因以及相關的解決方案,具體如下.

? Enclave 太大可能是由于內部的數據集太大或數據處理不當所致.保持enclave 較小以始終適合EPC,可以避免發生頁替換,如通過使用節省空間的數據結構或將較小的數據塊加載到enclave 來實現.但是EPC 在所有運行的enclave 之間共享,很難確定enclave 大小是否合適,因為EPC 可能已被其他enclave阻塞,從而無法避免頁替換,尤其是在多租戶的云平臺中;

? EPC 空間太小的問題也可以通過增加EPC 大小和增加并發線程來加以解決.鑒于大量的頁替換開銷,可以讓EPC 更大以提高其命中率.如直接提供更大的EPC 空間或支持創建enclave 后再進行擴展[90],VAULT[59]提供了支持EPC 擴展的數據結構支持,但enclave 超出EPC 大小仍然會導致頁替換;

? 在enclave 內使用替換的內存管理機制,取代SGX 采用的系統內存管理機制.例如,STANlite[20]和Eleos[58],這些系統在enclave 內部提供了新的內存管理機制,從而消除了EPC 硬件頁面故障和enclave退出導致的性能開銷;

? 通過預加載頁到EPC 中來防止enclave 執行期間發生頁面錯誤.例如,可以通過在發出ecall 之前加載所需的頁面來實現.這樣可以防止執行過程中enclave 內部發生頁面錯誤和AEX.

4.2.1 高效的完整性驗證結構減少分頁開銷技術

通過增加EPC 的大小來匹配物理內存的大小,允許EPC 容納非敏感頁面,可以有效地減少分頁開銷.Taassori 等人提出了解決方案VAULT[54],他們首先分析了目前EPC 最大只支持128M 的原因,具體如下.

? 用于存儲EPC 元信息的完整性樹深度和大小限制:完整性樹的深度和大小隨著受保護的內存的增大而增大.過大的樹大小和深度導致可緩存性差以及帶寬損失更高;

? 內存容量開銷:每個EPC 塊所需要的完整性樹和MAC 可占據受保護內存的四分之一(約占128MB 中的32MB);

? 性能要求:由于EPC 頁面訪問開銷巨大,因此不適合非敏感頁面.在設計時將大部分內存指定為EPC,會導致敏感頁面需求較少的應用程序不能充分利用EPC 和更高的性能開銷.

因此,為了支持啟用更大的EPC,必須解決至少兩個重要問題:(1)改進完整性樹的深度及其可緩存性以保持內存容量和帶寬開銷較低;(2)減少完整性驗證的空間開銷(包括完整性樹和MAC).

VAULT[59]首先引入了用于完整性驗證的可變元統一加密葉子樹(variable arity unified encrypted-leaf tree,簡稱VAULT)計數器,如圖8 所示.VAULT 可以有效平衡管理樹深度和計數器溢出問題.SGX 完整性樹的參數(arity)為8,VAULT 則將完整性樹的arity 設計為16 到64 可變,從而實現一個更緊湊且深度更低的VAULT,每次讀取和寫入的可緩存性和帶寬開銷都得到了提高.并且,VAULT 提出了壓縮共享 MAC(shared MAC with compression,簡稱SMC)技術,用以壓縮數據塊并將其MAC 打包到單個高速緩存行中,從而減少帶寬開銷,通過在多個數據塊之間共享MAC 來減少存儲開銷,并證明了基于壓縮的技術可以在大多數情況下消除或減少帶寬損失.因此,SMC 可以同時減少帶寬和內存容量開銷.最后,VAULT 僅為敏感頁面按需分配MAC,以進一步減少MAC 容量開銷.通過結合VAULT 和MAC 共享和壓縮,VAULT 實現了擴展EPC 到整個物理內存,并且可以解決SGX 內存訪問中的大多數低效問題,相對于SGX,整體性能提高3.7 倍,而內存空間開銷僅為4.7%.

Fig.8 VAULT schematic diagram圖8 VAULT 示意圖

4.2.2 安全用戶管理虛擬內存技術

Orenbach 等人提出了用于enclave 的無退出(exit-less)運行時系統服務Eleos[58],通過透明且安全地將系統調用委派給運行在一個應用程序線程中的RPC 服務,實現了無退出系統調用,即無需退出enclave.Eleos 包含3個部分(如圖9 所示):可信的運行時負責在enclave 內提供RPC 和SUVM;在單獨的應用程序線程中運行的不可信運行時負責處理RPC 請求并與SGX 驅動程序進行交互;SGX 驅動程序模塊公開了用于在多個協調SUVM內存分配的接口.

Eleos 還提出一種安全用戶管理虛擬內存(secure user-managed virtual memory,簡稱SUVM)抽象,這種抽象通過引入enclave 子頁面訪問粒度,消除了EPC 硬件頁面故障和enclave 退出導致的性能開銷.用戶通過特殊的分配器,在SUVM 中分配緩沖區,并獲得安全指針;然后可以將其用作應用程序中的常規指針,指針訪問被逐出的SUVM 頁面會觸發軟件頁面錯誤,并且完全在enclave 內部進行處理.這些機制提高了enclave 性能,且不會削弱SGX 安全保證.Eleos 只在TCB 中添加了幾百行代碼,與SGX SDK 或Graphene[51]等操作系統庫(約1 000 行代碼)相比,Eleos 在TCB 中添加的代碼相對較少.

Fig.9 Eleos high-level design圖9 Eleos 架構示意圖

Sartakov 等人提出了在機架規模環境中進行安全數據處理的內存數據庫引擎STANlite[20].STANlite 通過在enclave 內使用可擴展的虛擬內存引擎(virtual memory engine,簡稱VME),替代了操作系統提供的內存頁替換機制,并使其對內存具有完全控制權,從而避免巨大的模式轉換開銷.STANlite 在不需要考慮機密性的情況下,提供了一種純粹的完整性保護數據管理模式,以提高性能.STANlite 還具有基于遠程直接內存訪問(remote direct memory access,簡稱RDMA)、無切換和零拷貝的通信層,可在機架級環境中進行快速的遠程數據庫訪問.

4.3 安全內存訪問開銷優化

文獻[35]使用SGX SDK 微基準測試評估了enclave 內存訪問開銷.該基準測試了順序讀/寫和隨機讀/寫操作的時間開銷,并與未部署enclave 安全內存的訪問時間進行了對比.所有操作總共處理256MB 數據,但訪問的內存區域大小不同.

如圖10 所示:只要訪問的內存大小不超過3 級(L3)緩存(8MB),enclave 內存訪問開銷就可以忽略不計.如果L3 緩存未命中,隨機存儲器訪問的性能開銷可高達12 倍左右.當訪問的內存超出可用的EPC 大小時,觸發的頁錯誤會導致3 個數量級(1 000 倍)左右的開銷.連續內存訪問由于CPU 預讀取實現了更好的性能,這隱藏了一些解密開銷,在EPC 大小范圍內幾乎沒有內存訪問開銷,而超出EPC 大小的內存訪問大約有2 倍左右的性能開銷.

Fig.10 Normalized overhead of memory accesses with SGX enclaves圖10 SGX encalve 內存的標準化開銷

文獻[56,58]也對enclave 內存訪問開銷進行了測試,見表4.文獻[56]采用SPEC[91]測試集進行測試,表明內存寫操作的開銷(30%～102%)要比內存讀操作(6.5%～19.5%)高5 倍左右,但是沒有區分連續訪問和隨機訪問操作.文獻[58]則采用生成10 萬個隨機數進行enclave 內存訪問開銷測試,內存隨機訪問和連續訪問以及讀和寫操作的開銷相近,大約在5.6 倍～9.5 倍開銷之間.

Table 4 Performance evaluation of SGX memory read/write operation表4 SGX 內存讀寫操作性能測試

以上結果表明,enclave 內存加密開銷由SGX 設計本身所致,難以作進一步的優化.出于性能原因,安全程序設計應盡量減少對enclave 內存的使用和訪問.例如,SCONE[35]通過將加密的應用程序數據(如緩存文件和網絡緩沖區)存儲在enclave 之外,以減少enclave 昂貴的內存訪問.如果必須使用enclave 內存,應盡量采用連續訪問的數據結構,避免采用隨機訪問的數據結構.

4.4 小結

本節總結的以上3 種SGX 性能優化技術概括了目前常見的SGX 應用性能優化方案,為了更加直觀地對比每一種技術的性能提升程度和對安全性的影響,本節作了如下總結(見表5).

Table 5 SGX performance optimization solutions表5 SGX 性能優化方案

通過分析這3 種常見的SGX 應用性能優化技術的性能提升與安全性影響,可以將這3 種技術的研究總結為以下4 個方面.

? Enclave 的開銷主要歸結為模式切換、頁替換和內存加解密開銷.目前,主要的研究工作集中在對模式切換和頁替換開銷優化方面;

? 模式切換開銷目前的主要解決方案是將同步執行改為異步執行,最大化enclave 內部和外部的執行時間,從而減少頻繁的模式切換導致的性能開銷;

? 頁替換開銷目前的解決方案是,通過高效的數據存儲結構來增大EPC 和采用更高效的內存管理機制;

? Enclave 內存加解密開銷是由于SGX 本身的設計,目前主要通過合理使用加密內存來有效避免這些開銷.要從根本上降低加密內存訪問開銷,需要從SGX 設計層面來優化,如重新設計加解密算法等.

5 SGX 應用輔助開發技術

SGX 技術目前應用的場景越來越廣泛,但是安全且簡便地使用SGX 并不容易,錯誤或者不合適的使用方式甚至會導致安全風險.因此,輔助用戶更好地使用SGX 技術,也是一個非常重要的需求.目前,SGX 應用輔助開發技術主要包括安全開發語言、輔助開發工具和通用的操作系統庫和函數庫等.

5.1 安全開發語言

通過使用SGX SDK[16],開發人員可以創建加載到enclave 的代碼.雖然SDK 簡化了SGX 的使用,但SGX 所提供的編程支持有限,如不提供enclave 內部交互的編程支持、要求將可信代碼硬編碼到enclave 中,這限制了靈活性.開發SGX 應用需要對程序進行改造,當程序規模比較大時,帶來的編程成本非常高.為了方便用戶進行SGX 應用的開發并增強SGX 的安全性,目前學術界和工業界提出了支持SGX 應用開發的安全開發語言.

Rust SGX SDK[61]是百度安全實驗室開發的一個SGX Rust 語言開發工具包.通過將Rust 語言和SGX 技術相結合,開發人員可通過用Rust 語言編寫SGX 應用程序.開發人員基于Rust 語言可以快速開發出沒有內存安全漏洞的SGX 應用程序,即使在操作系統被惡意控制時也能提供強大的安全防護能力,避免敏感數據被竊取.

MesaPy[62]也是百度安全實驗室開發的一個安全開源項目,是一個內存安全的Python 實現.Python 包含超過30 萬行C 代碼,含有很多安全漏洞和隱患.MesaPy 基于Python 編譯器PyPy,通過使用內存安全語言重寫外部庫和形式化驗證保障代碼的內存安全等方法,全面提升Python 解釋器的安全性,避免內存問題引發的高危安全漏洞.基于這些安全特性,MesaPy 也支持運行在SGX 中,開發者可以使用Python 輕松地開發SGX 應用運行于可信運行環境中.

Ghosn 等人為增強SGX 的可用性,提出了一種將可信執行環境(trusted execution environment,簡稱TEE)集成到語言中的方案Secured Routines[63].該工作擴展了Go 語言,允許開發人員依靠編譯器自動提取安全代碼和數據.其原型GOTEE 是基于Go 編譯器進行的擴展.GOTEE 為TEE 提供了一種簡單的編程模型,開發人員可以直接通過關鍵字定義敏感代碼.

5.2 輔助開發工具

5.2.1 安全劃分與檢測工具

自動化安全開發和檢測工具也是SGX 應用輔助開發工具的重要類型,該類工具的主要目標是實現對應用敏感代碼的自動化分析和劃分,以及對enclave 代碼的安全性檢測.本文第3.3 節介紹了用于SGX 應用程序的源碼劃分框架Glamdring,可以基于開發人員對敏感數據的注釋,自動地將應用程序劃分為不可信和可信兩部分.

SGX 為enclave 內的代碼和數據提供硬件保護,以抵御來自底層操作系統的攻擊,但是應用程序本身中的漏洞(例如SGX 指令使用不正確或內存安全錯誤)也存在泄露機密的風險.文獻[53]基于自動定理證明和信息流分析,提出了一套SGX 的使用規范,設計了Moat 這一檢測工具,通過在匯編語言層面對程序進行分析,從而檢測應用程序是否存在泄露SGX 區域中秘密信息的可能.

5.2.2 性能測試與優化工具

SGX 目前所提供的開發支持工具非常有限,這會導致耗時的反復實驗開發和調試,并存在性能下降的風險.SDK 自帶了一個調試器插件,可用于檢查enclave、設置斷點等,但是該插件僅適用于使用SDK 開發的應用程序.Intel 提供的性能分析器VTune Amplifier[92]也可用于測試SGX 應用程序(包括enclave)性能.VTune Amplifier支持一種稱為熱點(hotspots)的新分析類型,可用于分析enclave 應用程序.熱點是一段頻繁執行的代碼,例如循環主體,由類似于每條指令的總周期數或高速緩存未命中等指標來定義.開發人員可以使用熱點的默認設置來深入了解SGX 應用程序與熱點有關的enclave 函數,確定要進一步優化的代碼.VTune 專注于代碼片段的底層分析,未充分考慮SGX 特性,不足以幫助開發人員編寫高效的enclave 域代碼.

文獻[64]介紹了一組用于SGX 應用程序的動態性能分析的工具sgx-perf,它可以對enclave 中的性能關鍵事件進行細粒度分析,允許開發人員跟蹤enclave 執行并記錄影響性能的關鍵事件,例如enclave 切換和頁替換.它通過隱藏SGX SDK 的特定功能并重定向控制流來實現,分析記錄的數據可以發現潛在的性能瓶頸.此外,sgx-perf 提供了改進enclave 代碼和接口提高性能的建議.測試表明:使用sgx-perf 提供的建議最多可以將應用程序的性能提高2.66 倍,這有助于開發出性能良好的SGX 應用程序.

5.3 系統庫支持

相關工作中提供操作系統庫和函數庫來支持enclave 內通用應用程序的執行,如Haven[30]、SGXKernel[50]、Graphene[51]和SCONE[35]等.本文已在上文中有所介紹,這里再進行一些簡單梳理.Haven 將drawbridge 系統庫部署到enclave 內部,支持在enclave 內直接運行未修改的Windows 應用程序.Graphene 則是在enclave 中部署了一個支持Linux 應用程序運行的操作系統庫,可以實現在SGX 上快速部署未修改的Linux 應用程序.SGXKernel同樣也是在enclave 內部署了一個支持Linux 應用程序操作系統庫,且其性能明顯優于Haven 和Graphene.SCONE 則是在enclave 中配置了標準C 函數庫[79]的修改版本,以支持重新編譯的Linux 應用程序.

5.4 小結

本文將SGX 應用輔助開發技術總結為安全開發語言、輔助開發工具以及系統庫和函數庫這3 類(見表6).通過分析總結上述研究工作,并結合目前SGX 應用需求,本文分析了SGX 應用輔助開發技術的發展方向.

? 開發語言目前已經支持C/C++、Python、GO 語言,并且GOTEE 已將可信的開發環境集成到了GO 語言中,可以通過關鍵字直接定義敏感函數.相關工作都考慮到將內存安全功能集成到開發語言中,簡便使用和更多的功能集成,是安全開發語言的發展方向;

? 輔助開發工具目前主要有SGX 應用程序自動劃分工具、enclave 機密性驗證工具和程序性能測試工具,但是這些工具仍存在一些問題需要解決,如自動劃分工具代碼劃分粒度不夠細、缺乏劃分標準等;

? 操作系統庫和函數庫目前主要有通用Linux 系統庫、Windows 系統庫和標準C 函數庫,并且基本能夠支持90%以上的常用系統庫和函數庫API.

Table 6 SGX application-assisted development techniques表6 SGX 應用輔助開發技術

6 SGX 應用功能擴展技術

SGX 的主要功能是創建可信執行空間,抵御特權軟件的威脅,應用的主要場景是云平臺.然而,目前SGX 自身缺乏對虛擬機遷移和容器等云平臺常用技術的支持.目前很多研究工作對SGX 進行了功能擴展,使其支持常用的云平臺技術.

6.1 支持虛擬機遷移

SGX 可以解決云計算中的信息泄露問題,但是現有的虛擬機管理器(virtual machine manager,簡稱VMM)不提供啟用SGX 虛擬機(vitual machine,簡稱VM)的高效管理操作,如實時遷移.隨著SGX 越來越多地部署到云平臺中,內部運行enclave 的VM 失去了實時遷移的能力,而VM 實時遷移在云計算中被廣泛使用,例如用于負載平衡、容錯.這是由于SGX 硬件防止不可信的虛擬機管理程序或操作系統訪問enclave 的運行狀態所致,而這是傳統VM 實時遷移所必需的.啟用SGX 的VM 能夠實時遷移不是一個簡單的問題,也面臨著如下困難.

? 加密內存頁在目的主機解密問題:Enclave 綁定到單個物理CPU,使用特定于CPU 的唯一密鑰加密,如果VMM 以現有方式遷移enclave,則由于密鑰不匹配,另一主機無法從源主機解密enclave 內存頁;

? 抵御回放攻擊(roll-back attack):Enclave 存儲空間有限,有時需要將enclave 內部的數據加密并換出enclave,然后在需要處理時再換入enclave 并解密.但這樣會面臨回放攻擊,惡意系統使用舊版本的數據欺騙enclave,enclave 需要使用硬件計數器來抵御;

? 持久狀態的遷移:包括密封數據和單調計數器,前者存在數據丟失風險,后者破壞了SGX 的安全保障.

Park 等人提出了一種支持SGX VM 遷移的方法及其實現模型[65],基于KVM(kernel-based virtual machine)實現了相關設計,為應用程序和支持SGX 的KVM 客戶操作系統提供了SGX 庫,并為開發人員提供了SDK,以便他們編寫enclave 代碼時無需了解相關的遷移機制,例如控制線程.其系統性能開銷可以忽略不計,遷移內部運行64 個enclave 的虛擬機,遷移的總時間增長了4.7%,而停機時間僅增加了3ms.

Chen 等人設計了一個基于軟件的VM 安全遷移機制,允許enclave 遷移其運行狀態[66].遷移過程需要enclave 和不可信特權軟件之間的合作.該機制在每個enclave 中引入一個控制線程來幫助VM 遷移,從內部安全地轉存所有enclave 的狀態.對于enclave 中的數據和CPU 上下文等狀態,控制線程將對它們進行加密,并在轉存之前進行完整性保護;對于不能由軟件直接訪問的狀態,例如由CPU 維護的當前狀態保存區域(CSSA),設計記賬機制來推斷 enclave 內的值,并通過兩階段檢查點方案強化設計,利用遠程證明和自我銷毀來保證每個enclave 實例在遷移后不會回放或生成多個實例,以此來防御回放攻擊.該工作采用純軟件方法實現密封數據和單調計數器遷移,并且維持SGX 的安全保證,最大限度地減少了開發人員的工作量,性能開銷可以忽略不計.

Alder 等人則將SGX 計數器作為持久狀態,實現了相應的遷移方案[67],并設計和實現一個框架,實現具有持久狀態enclave 的遷移,同時保持SGX 相同的安全性保證.該遷移方案解決了一些實際挑戰,例如從VM 訪問enclave,并將enclave 遷移到目標計算機的性能開銷限制在12.3%以下,大大減少了enclave 開發人員的工作量.

6.2 支持容器

基于容器的虛擬化技術變得越來越流行[93].許多多租戶環境使用容器來實現應用程序的性能隔離,比如使用Docker[37]來封裝容器、使用Docker Swarm[94]或Kubernetes[95]進行部署.盡管硬件虛擬化得到了改進,但容器在虛擬機管理程序上仍然比虛擬機(VM)具有性能優勢:啟動時間更短、I/O 吞吐量更高且延遲也更低[96].但提供的安全屬性比VM 要弱,因為主機OS 通常只使用軟件機制進行隔離[97].現有的容器隔離機制主要保護環境免受不可信容器的訪問,但是租戶希望保護其應用程序數據的機密性和完整性,防止未授權方的訪問,不僅來自其他容器,還來自更高權限的系統軟件.攻擊者會攻擊虛擬化系統軟件中的漏洞,或損害特權系統管理員的安全憑證[98].

SGX 可以保護應用程序代碼和數據免受其他軟件的訪問,包括更高權限的軟件.使用enclave 可以保護容器不受更高權限軟件的威脅.容器的應用程序可以在enclave 內執行,以確保數據的機密性和完整性.但是,使用SGX 設計安全容器機制面臨著兩個挑戰:(1)最小化enclave 內TCB 的大小,同時支持安全容器中的現有應用程序;(2)保證安全容器的低性能開銷.

文獻[35]設計了一個用于Docker 的安全容器環境SCONE,基于SGX 實現在安全容器中運行Linux 應用程序,SCONE 內部架構如圖11 所示.

SCONE 的內部組件如下.

? 對主機OS 系統調用的外部接口.SCONE 在將參數傳遞給應用程序之前執行完整性檢查,并將所有基于內存的返回值復制到安全區內部來抵御攻擊.為保護通過文件描述符處理的數據的完整性和機密性,SCONE 通過屏蔽(shield)來支持數據的透明加密和身份驗證;

?M:N線程模型.M個enclave 綁定的應用程序線程在N個OS 線程之間進行多路復用.當應用程序線程發出系統調用時,SCONE 檢查是否存在另一個可以喚醒并執行的應用程序線程,直到系統調用的結果是可用為止,從而避免了不必要的模式切換開銷;

? 異步系統調用接口.異步系統調用通過使用共享內存來傳遞系統調用參數和返回值,并發出信號請求執行系統調用實現.系統調用由 SCONE 內核模塊中單獨運行的線程執行.因此,執行系統調用時,enclave 內的線程不必退出;

? 與現有的Docker 容器環境集成,并確保與標準Linux 容器兼容.但是Linux SGX 驅動程序和SCONE內核模塊必須運行在主機OS 上,因此,除了Linux SGX 驅動程序以外,SCONE 不使用SDK[16]中的任何功能.

SCONE 在保證安全容器的TCB 較小的情況下,通過線程異步執行等操作實現了很低的性能開銷,且對Docker 是透明的,與普通容器類似.由于容器鏡像通常由專家生成,因此,缺乏經驗的用戶可以從SCONE 中受益,只要信任安全容器鏡像的創建者即可.

Fig.11 SCONE architecture圖11 SCONE 架構圖

在異構集群上部署和調度容器,混合使用具有和不具有SGX 功能的計算機存在挑戰.需要使用SGX 的容器將會存在爭奪enclave 內存的可能性,因此,必須使用具有度量資源使用功能的調度管理器跟蹤SGX 內存請求并相應地調度容器.但是現有的容器協調器都沒有提供有關的SGX 資源使用運行時監控,只能依賴用戶在部署時提供的靜態信息.這些信息可能是錯誤的或不符合容器的實際使用,導致分配過多或分配不足.文獻[68]提出了一種用于調度容器的SGX 感知架構,并提供了該框架的開源實現,包括修改SGX 的Linux 驅動程序作為Kubernetes 設備插件.

6.3 構建可信的外部路徑

在本地應用環境中,用戶可以使用SGX 保護應用程序不被受到破壞的操作系統的影響.但是SGX 缺乏對通用可信I/O 路徑的支持,以保護用戶在enclave 和I/O 設備之間的輸入和輸出.文獻[69]介紹了一種SGX 通用可信路徑架構SGXIO,允許用戶應用程序在不可信的操作系統上安全運行.SGXIO 將SGX 編程模型的優勢與傳統的基于hypervisor 的可信路徑架構相結合,實現了支持通用I/O 設備的可信路徑.SGXIO 超越了云計算中的傳統用例,使SGX 技術可用于保護以用戶為中心的本地應用程序,以防止內核級別的鍵盤記錄程序等攻擊手段的使用.

6.4 小結

本節對SGX 的相關功能擴展技術進行了總結和分析.當前,SGX 的功能擴展技術主要包括虛擬機遷移支持技術、容器支持技術和通用I/O 可信路徑支持技術.具體擴展的功能和優勢見表7.

通過總結和分析上述研究工作,并結合云平臺等典型的計算場景,本文總結和分析了SGX 應用功能擴展技術未來的研究方向.

? 目前,SGX VM 遷移主要基于軟件模擬的方式實現,并不能完美地解決SGX VM 遷移問題,VM 遷移等操作需要SGX 設計和實現的進一步支持;

? 容器技術與SGX 基本的結合問題得到了有效的解決,但在性能方面仍然有進一步優化的空間;

? SGX 技術在很多方面仍然缺乏一定的功能支持,尤其是在某些具體的應用場景,如多方計算場景下,需要多個enclave 之間進行交互,而多個enclave 之間的切換開銷高昂,目前,SGX 缺乏有效的支持技術.

Table 7 Feature extension techiques for SGX application表7 SGX 應用功擴展技術

7 SGX 應用支持技術研究展望

SGX 技術的推出,為遠程可信計算問題提供了解決方案.本文對SGX 技術的研究現狀及瓶頸問題進行了總結和歸納,如何完美地解決SGX 技術應用的瓶頸問題,需要進一步的研究.本文從安全防護、性能優化和易用性這3 個方面進行了分析.

(1)安全防護:應用安全是SGX 應用所面臨的最基本的問題.如何有效地解決SGX 應用所面臨的側信道攻擊、內存攻擊等安全威脅,增強SGX 應用的安全性,依然是該技術應用研究的重要研究方向,具體的研究方向包括:SGX 代碼運行時的安全性分析與檢測、SGX 應用代碼合理劃分、抵御側信道攻擊等問題;

(2)性能優化:性能開銷高是制約SGX 應用的重要瓶頸.如何減小SGX 技術的內在開銷,實現其性能優化的一般性解決方案,是后續的研究方向.具體的研究方向包括:通過硬件加速或可選加解密算法等方式降低enclave 內存加解密開銷、具備性能調優功能的自動化代碼劃分和更加高效的加密內存頁管理方式等;

(3)易用性:SGX 應用開發的困難性和功能的局限性也是制約其應用的重要原因.如何增強SGX 技術的易用性和擴展SGX 功能,是該技術研究的熱點問題.具體的研究方向包括:對遺留應用中敏感代碼自動化識別劃分和安全性分析、避免重構代碼支持原有程序直接運行的方案、更簡潔易用的開發語言和動態可調整的庫支持、對虛擬化等云平臺常用技術的有效支持以及輔助用戶開發安全和性能良好的SGX 應用的開發工具等.

SGX 應用支持技術在學術界和工業界都引起廣泛關注,我們認為,SGX 應用支持技術在未來的研究工作可能會偏重以下幾個方面.

(1)對硬件能力的擴展

SGX 目前的功能主要是基于17 條指令來實現的,SGX 本身不支持虛擬機遷移,雖然基于軟件模擬的方案實現了相關功能,但是更好的解決方案是對SGX 的硬件能力進行擴展,提供支持相應操作的SGX 指令及安全機制.目前,SGX v1 可以支持的最大EPC 為128M,但仍然無法滿足應用對SGX 的需求,EPC 需要進一步地加以擴展.這其中,有一些挑戰性問題需要解決,如高效的完整性驗證結構以及無安全需求的代碼對EPC 的浪費和高開銷問題.

(2)對各種應用場景的有效支持

SGX 目前的主要應用場景是云計算,但是目前可信計算的需求越來越廣泛,IoT、邊緣計算等都需要可信支持.SGX 由于性能等限制難以直接應用到相關場景中,需要對SGX 技術進行擴展和改進.目前,SGX 已經應用到的場景中,如多方計算,SGX 主要起到基本的安全隔離作用.但在多方計算場景下,應用本身交互頻繁,SGX 的設計無法直接對這些場景提供有效的支持,性能開銷很高.SGX 的密鑰管理同樣面臨性能問題,在復雜場景和應用中,性能開銷過高、實用性差,SGX 需要更加高效的密鑰管理方案.

(3)與區塊鏈等技術結合擴展SGX 能力

SGX 與區塊鏈等新興技術的結合,目前是SGX 技術的研究熱點之一.SGX 提供的可信環境可以為智能合約等提供區塊鏈所不具備的機密性保證[99],可信的計算節點也可以支持區塊鏈應用于更加復雜的應用場景[47].目前,利用SGX 提高區塊鏈安全性和性能的研究工作還有很多瓶頸問題需要解決,如不支持enclave 內部智能合約之間的調用問題[47]、利用SGX 的可信性替代區塊鏈共識機制可信性的合理性問題等[47].SGX 可以為區塊鏈提供機密性和可信性保證,同樣,區塊鏈技術也可以為SGX 提供持久化存儲和可信性驗證方法,對計算結果進行記錄和驗證,從而實現可追溯等.這些都是對SGX 非常重要的能力擴展,可以使其應用到更加廣泛的場景.如何結合區塊鏈等技術對SGX 能力進行擴展,也是后續研究的重要研究方向.

(4)如何解決SGX 固有的信任問題

SGX 自公布以來在很多方面受到質疑,例如固件的不可審計、對Intel 管理引擎(management engine)代碼模塊的依賴導致會受到安全漏洞的威脅以及必須信任Intel 作為遠程證明的前提.尤其是SGX 必須使用Intel認證服務(Intel attestation service,簡稱IAS)使其可信性受到廣泛質疑,Intel 公司作為SGX 技術遠程證明服務提供方,用戶也無法對其進行審計,因此很難完全信任SGX.目前,Intel 公司在固件中實現的新特性FLC(flexible launch control)可以實現開放第三方驗證服務,一定程度上增強了SGX 的可信性.但是,固件的不可審計和對Intel 管理引擎代碼模塊的依賴,仍然沒有得到有效解決.

8 結束語

本文對SGX 應用支持技術的研究進展進行了深入分析和總結.首先介紹了SGX 技術的相關機制和SDK,分析了SGX 技術應用現狀及瓶頸問題的研究進展;接著,分別介紹了SGX 應用安全防護技術、性能優化技術、輔助開發技術和功能擴展技術;最后,展望了SGX 應用支持技術的未來研究方向.從我們的總結來看,SGX 應用支持技術仍然有一系列的挑戰問題,未來有很多工作值得繼續加以研究.期望通過我們的工作,能夠給以后的研究者提供有益的借鑒與參考,為SGX 技術的進一步應用和發展做出貢獻.

致謝在此,我們向對本文工作給予支持并給出寶貴建議的評審老師和同行表示衷心的感謝.