為什么要Intel SGX？

以云環境為例子，云租戶會將自己的產品部署在云平臺中，但是云平臺現在普遍認為是一個不可信的地方，因為可能會有云平臺管理者、同一云主機其他租戶的惡意攻擊，也可能云平臺本身存在漏洞，使得黑客輕易的攻擊并拿到Ring0權限，這種情況下，云租戶就開始擔心了。

（就好比我租了房東的一間臥室，我害怕房東、其他租戶、陌生人對我房間東張西望，甚至搞破壞。）

與此同時，Intel SGX出現了，它對自己做了一個安全內存Enclave的概念，對安全內存實施權限控制、加密等安全措施，防止別人（Ring0級別的攻擊者）非法對安全內存內的敏感數據代碼進行機密性、完整性的破壞（個人見解，SGX對可用性并不保障），其中完整性主要通過可信建立Enclave保證。

（就好比，我租了房東臥室后，我對自己臥室的墻進行加固，并且對門加上自己的鎖，不讓人家偷窺、搞破壞。）

除了云環境，Intel SGX旨在防所有Ring0級別的攻擊者（OS、VMM等），服務器中也可以對敏感部分就行加固。開發商下放版權也可以放到客戶端的SGX保證版權保護。此外還有對區塊鏈這種分布式客戶端的形式就行客戶端本地的SGX保護。

Intel SGX尚處于學術討論

Intel SGX在學術圈屬于非常熱門的一個點，論文很多，這說明大家感覺Intel SGX的安全特性很有意義，也說明Intel SGX目前也有不少值得探討的問題存在。

由于Intel SGX會導致應用開發方式的不同，使得Intel SGX很難真正用于實際生產，這里主要指無法將原有的產品直接放到SGX中，這是第一點。第二點，對于未來將開發的產品，由于產品往往依賴于某些庫，但是實際中，這些庫并沒有人將它費勁的搬到SGX中，導致SGX只有Intel維護的標準C/C++庫等，并沒有豐富的庫，導致Enclave內部開發起來也費勁。此外，Enclave內部目前應該只支持C、C++的開發，Python、Java這種個人感覺更適合上層開發的語言目前沒有支持。

上述說明SGX是個學術寵兒，但是實際應用中，除非工業界非常感興趣，不然沒有那么多人力物力將不重要的產品搬到SGX中。所以就看產品是否敏感到非用SGX不可。

此外也有Graphene-SGX等能夠讓傳統APP不需要改代碼就能跑在SGX中，但是其會引入LibOS等相關內容，使得Enclave內部冗雜，TCB變大；并且效率受影響，SGX本身由于進出Enclave刷新TLB等安全措施導致效率有損耗；兼容性值得考量，個人不是很了解LibOS，但是對LibOS能夠提供的兼容性值得考慮。

以我現在觀察發現，基于Graphene-SGX等的產品數量貌似不如直接用SGX開發的多，（這個觀察不一定準確），一方面是Graphene-SGX知名度不如SGX，一方面是Graphene-SGX出現時間也略晚，還有一方面就是Graphene-SGX某些特性上并不如直接從SGX開發來的高效，穩定。

Intel SGX的好伙伴——ARM上的TrustZone，我們似乎也沒有觀察到TrustZone也有很普遍的應用，一般還是敏感到需要用到了才不得不用。（觀察不一定準確）或許未來又是另一番場景，我便不得而知了，但是可以肯定的是SGX想要廣泛應用，必須要SGX支持足夠的中間件、庫，能讓上層便捷的開發。

Intel SGX和可信啟動什么關系？

在SGX之前，可信計算中可信啟動其實挺火，主要是說從底層Bootloader->BIOS->OS/VMM->APP的一步步遞進的可信度量和啟動。但是這種模式局限程度高，而且也有人說這限定了就幾個大廠的產品滿足可信啟動的條件，相當于某種壟斷。而且這種效率其實也有影響，且TCB大。

SGX主要還是CPU硬件里面強制將某塊內存定義為安全內存，并施加硬件級別的訪問控制等，這樣的話，就不要求整個主機都是可信的，只要SGX所管理的Enclave安全內存是可信就行（包括Enclave代碼的可信度量和建立）。

開發者眼中SGX長什么樣子？

?

?

簡單來說SGX就是提供了一個安全內存及其相關。下面稍微講一下SGX軟件棧結構（具體見《SGX軟件棧》文檔）

總的來說，SGX是劃分兩個世界的——可信世界和不可信世界。每一個世界中，想要使用SGX的開發都需要開發哪一個世界的代碼，一般來說，不可信世界開發非敏感代碼（稱為APP，另一種理解就是APP也包含Enclave，這樣為了區分，就把不可信的叫做APP），可信世界開發敏感代碼（Enclave），或者說敏感代碼移入了可信世界。

既然有了兩個世界，他們之間的連接就需要有一個叫做橋函數的東西，ECALL橋能讓APP可以調用橋函數間接調用Enclave中寫好的API函數。反向的有個叫OCALL橋的東西。橋函數上承載著兩個世界間傳遞的參數，而且ECALL中，Enclave并不信任APP傳給Enclave的ECALL參數，所以需要參數的消毒檢查。OCALL有點類似。

既然要開發程序，就要用到SDK（我這里是把可信Enclave使用的SDK稱為SDK，這也符合Intel的叫法，另一種理解是SDK包括給不可信APP使用的PSW、給可信Enclave使用的SDK、橋函數）和PSW，這兩個都是Intel提供的（linux下見github.com/intel/linux-sgx）。由于Enclave要保證自己內部開發的函數盡可能不會離開Enclave，所以Enclave內部用的SDK都是用靜態庫鏈接，除非萬不得已，比如系統調用等，那么就得同OCALL橋到不可信世界完成任務。然后頂多是啟發式的對OCALL返回值進行檢查（而且目前Intel并無消毒檢查，除非Enclave開發者自己做檢查）。

PSW、SDK一部分功能是用于我們傳統的那種為了具有某個功能而開發的函數，還有一部分是對CPU提供的SGX功能指令的包裝，主要用于SGX特性的支持，為了讓你真正和CPU溝通，并獲得SGX特性支持。SGX特性是通過CPU向外面提供Ring0指令和Ring3指令，其中Ring0指令ENCLS主要有一些比如創建Enclave這種生命周期管理、頁權限管理的指令。Ring3指令ENCLU主要是讓控制流能夠在兩個世界之間流動，比如進出Enclave這種。

這一塊的細節可以看《SGX軟件?！贰?/p>

SGX訪問控制是什么？

SGX訪問控制是說對Enclave安全內存進行訪問控制，不能讓攻擊者非法訪問敏感內存。這主要還是通過CPU內部實現的。有SGX特性CPU能夠讓不可信APP只有滿足進入它的Enclave的條件時才能放行，而且Enclave A和Enclave B之間是互相不可訪問的。這種邏輯是CPU里面的EPCM和內存RAM中被CPU定義為EPC里面的SECS結構體、TCS結構體這些單元連動完成的。

《SGX技術的分析和研究》有介紹具體有哪幾則訪問控制。

MEE與SGX EPC內存加密

EPC，Enclave Page Cache，是被加密的安全內存頁，由MEE加密。

MEE是Memory Encrypt Engine,內存加密引擎，會對從CPU緩存、寄存器之類的地方往其他如內存（比如EPC）、硬盤運輸之前都加密，因此在內存、硬盤的敏感數據都是加密的。

這種好處就是能夠抗總線攻擊，防止攻擊者直接物理連接總線竊取敏感數據。劣勢，就是或多或少會有加密導致效率的影響，雖然說MEE已經是一個專門的用來加密的模塊。

CPU里面SGX長什么樣子？

?

這張圖主要是講SGX初始化過程的，也可以拿來講解CPU里面多了哪些部件。下面中間RAM這個是內存，內存里面一部分EPC就是存放Enclave的安全內存池，里面有多個安全內存頁，每個Enclave按需從這里拿取Enclave安全內存頁。

最左下角EPCM（Enclave Page Cache Map）是一個安全內存管控的內置微架構結構體（internal micro-architecture structure ），會由PMH硬件模塊進行查EPCM，進行訪問控制。PMH和EPCM主管對EPC的訪問控制，會依賴SECS、TCS聯動判斷。

圖片右下角就是CPU及其MMU、MEE部件，MMU是傳統的地址翻譯部件，MEE是說SGX能夠做到在EPC中的敏感數據能夠明文存在（因為有訪問控制，不擔心被偷窺），但是EPC中的數據一旦會轉到普通硬盤中的（由于EPC大小一般是256M，因此會出現換入換出到硬盤的情況），那么MEE就加密那個明文，只讓密文存在于硬盤中。其實MEE不單單是對換入換出到硬盤就行加密，它對任何離開CPU安全邊界的明文都進行加密。

最左上角是Enclave代碼，這里代表的意思是Enclave代碼已經放到了EPC中，然后圖片上講原來在RAM的EPC中的Enclave，單獨畫出到外面來，它本質是存在于EPC中的。

上面這個APP和Enclave代碼是一個二進制文件，最終會被加載到內存的普通內存（APP部分代碼）和安全內存中（Enclave部分代碼）。

中間OS是在Enclave啟動過程中（從無到有），完成對安全內存頁申請，代碼復制進安全內存頁等一系列操作的管理（《SGX軟件棧》文檔中有專門講這個）。我之前說了OS是不可信的，所以通過OS啟動Enclave會需要一些額外的措施：Architectural Enclave這個特殊的Enclave（由Intel簽名并啟動起來的Enclave）會對Enclave的完整性進行簽名保證，Enclave被OS啟動過程中，相應的啟動過程的度量會放在EPC的SECS中，最后會對AE簽名的那個度量值比對，為了防止OS對Enclave啟動過程中做小動作。

總結一下，CPU本身擴充了很多硬件指令，可以分為兩大類ENCLS、ENCLU。上圖可以看到CPU所增加的硬件部件，有MEE、PMH（查EPCM）、Intel ME（粗粗了解到它提供可信輸入和可信時間）（其他暫且沒想到，似乎還有）。

SGX初始化過程大概就是建立時候申請安全內存頁，然后將Enclave代碼放進去，并且度量建立過程是否可靠。（細節見《SGX軟件?！?#xff09;

有Enclave的APP的虛擬地址空間長什么樣？

APP依然還是那個APP，有著常見的虛擬地址空間（比如4G，32位地址下），然后其中有一整塊，比如0X700-0X800（通過觀察一般都是高地址，這里只是隨便寫了）是給Enclave的，因為Enclave是一個.so動態庫鏈接給APP的，Enclave虛擬地址的起始地址依賴于ALSR地址空間隨機化給定。

那我們假設訪問某個Enclave函數時，我們用的這個函數的虛擬地址（和正常虛擬地址空間里面調用函數一樣），然后會經過MMU的虛實地址轉換，變成物理地址，這個物理地址會指向EPC，前面講了EPC是RAM中的一部分（而且是靠前的一部分，存在于PRM中，由BIOS和范圍寄存器來決定EPC的大小），所以EPC也是有物理地址的，這也很正常。物理地址拿到后，想要訪問EPC物理頁，那么請先經過EPCM的訪問控制檢查。如果通過了，那么IP寄存器就會給到那個Enclave函數了。

SGX目錄、文件初體驗

?

和傳統應用開發不同，上圖可以看到APP、Enclave是分開編寫的。命名倒是無所謂，具體會通過Makefile里面說明把哪些編程Enclave。

?

此外，通過這個EDL文件可以清楚的看到光是進出Enclave的接口就分開了。一部分trusted括起來的是ECALL用來進入Enclave，untrusted括起來的是OCALL，用來離開Enclave。

SGX和它的小伙伴

要知道可信執行環境不止Intel SGX一家，所以很多思想可能值得借鑒的地方，并且，應該是能夠以可信執行環境一個更高的高度來看待這些應用攻防的問題。

硬件比如還有TrustZone，軟件有Virtual Ghost、SP3、Overshadow、InkTag、CHAOS、AppShield，他們都或多或少有類似Enclave的可信執行環境的概念。

SHIELDING SOFTWARE FROM PRIVILEGED SIDE-CHANNEL ATTACKS(SEC’18)這篇是關于Virtual Ghost的工作。它做了兩個工作。第一，針對已有的頁表側信道，它的做法是將頁表機制由Virtual Ghost內部來完成，OS所保管的Direct Map中對于Virtual Ghost內部安全有用戶空間的映射被刪除。第二，針對LLC側信道，利用Intel Cache Allocation Technology，從硬件層面對LLC實施隔離，不讓OS窺探Virtual Ghost內部的存放于LLC中隱私。Intel CAT技術是Intel RDT的子模塊，我目前感覺和SGX一樣是向用戶態提供Ring3指令用于CPU特性管理（可能存在錯誤）。

接下來我們講講現在有哪些SGX的研究了。分類方法主要依賴于CCS’17中，關于SGX的三篇綜述

總結

以上是生活随笔為你收集整理的Intel SGX入门（一）——背景篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。