其實SGX應用也包括，SGX保護框架，SGX軟件層改進，單獨拎出來
先說說SGX保護框架（SGX Shield Framework）
Haven(OSDI’14) 微軟
SGX已經硬件實現了，但是，很多老的APP並沒有用上SGX。並且SGX的代碼開發和原來不太一樣了，得把代碼劃分成Enclave內外兩個部分。那麼意味着老的APP很難用上SGX了，因爲不是所有人都願意花力氣把原來的APP移到SGX上。那麼怎麼把老的APP放到SGX上呢？微軟提供了Haven方案。
Haven架構如圖：Enclave（APP->LibOS->Shield模塊）->uRTS->OS的棧結構（LibOS在這裏的作用相當於自己租的臥室內搭建一個小廚房等設施，儘可能的不與外界打交道，儘可能不用外面的大廚房）。這樣子，整個APP都是Enclave內部的，APP和LibOS打交道就行，LibOS或者直接滿足APP的需求，或者向外讓Host OS完成具體需求。總之APP就不用改代碼了。
如上所說，Enclave仍然會有小部分的比如系統調用需要與外界接觸（好比小廚房的電、氣還是得走總的房子的電、氣）。此外，SGX還有一些細節限制：EPC大小有限（比如256M），頁錯誤等異常仍然由外界OS來處理，還有很多硬件指令Enclave內不能調用……。
上述這種有Enclave與外界接觸的情況，就有被攻擊的風險，只要SGX與外部有啥共享的機制，就可能被攻擊，SGX側信道很多就是基於共享機制（後面會講）。
LibOS和庫直接塞入SGX會導致TCB過大的問題，小結處會討論Haven和他的小夥伴們，進行一個橫向對比。
SCONE(OSDI’16)
SCONE的初衷應該就是想讓容器能夠由SGX進行安全加固。同時最好就是容器可以直接在Enclave中跑，不需要修改，因此它提出如上圖架構。
它發現其實並不需要整個LibOS都移進來也能完成對容器的支撐，因此將LibOS概念移除，移除了包含網絡和文件Shield層、多線程（不支持多進程）、MUSL等。
另外它還實現了一套異步系統調用的機制（可能是處於安全考慮？目前尚不清楚）。
可以看到SCONE的架構和Haven就有一些區別了，SCONE的TCB相對Haven更小（Haven的LibOS代碼、庫的代碼量很大），同時效率也得到了提升。不過SCONE架構中，Enclave與外界的接口更多了，因爲SCONE裏面刪除了很多東西，意味着這些東西都得找HostOS提供。
Ryoan(OSDI’16)
這個當時看懂的有點少。大概是說作者認爲SGX原來的機制不夠安全（的確存在非常多SGX攻擊），於是作者在Enclave再防一個沙箱來執行代碼。這個沙箱在SGX基礎增強安全性，並且提供了一些軟件側信道的防禦手段（比如與外界輸入輸出加密、系統調用的模擬、檢查點）。
Panoply(NDSS’17)
爲了讓傳統程序能夠不改代碼的移植到Enclave中，Haven、Graphene-SGX中將LibOS移入Enclave，並仿真地提供系統調用、線程、事件處理、Forking等功能（最終會轉換到Host OS的系統調用），但是也會導致TCB太大（主要是庫比較大），效率低等。SCONE、Ryoan使用容器、沙箱來向上支撐傳統程序，但是如Fork/Exec等功能無法仿真（因爲本身並不是像Haven那樣整個LibOS都搬進SGX），這種選擇一般來說TCB很小（主要是庫不在Enclave內），效率個人猜測會高於Haven這種。
Panoply另闢蹊徑，或者說上述兩種綜合一下，將Libssl等庫（Haven中將其放在Enclave中）專門用一個Enclave來執行，目的是爲了實現複用（不需要每個Enclave保留一份，降低TCB），然後想要調庫，就向庫Enclave發出申請，庫Enclave返回結果。可以放心的是Enclave間的調用(通信)走的是加密信道，同時彼此實現相互認證。
另一個點和SCONE還是有點像，就是Enclave留一個Shim來執行系統調用來實現各種豐富的功能，具體實現放到不可信的Host OS中。
Panoply這種庫Enclave的想法一定程度實現代碼複用，降低TCB，不過應該會導致面向HostOS的接口變多，Haven中Enclave與HostOS的接口只有20+。
總之，Haven、Panoply都能幫助傳統程序不改代碼移植，間接提供系統調用、線程等功能，區別在於Haven通過LibOS實現了很多OS功能，Panoply留了個接口給Enclave，讓有些功能由HostOS來做。Panoply庫Enclave的概念挺新穎，用來實現代碼複用。
Panoply的庫Enclave思想其實和RPC有點接近。
Graphene-SGX(ATC’17)
個人覺得這個和Haven類似，或者說Haven架構的Linux下實現，Haven是Win下的實現。Haven應該是20個固定系統調用，Graphene-SGX是28個固定系統調用（18個系統調用會有檢查）。除了向上支持Linux傳統軟件，後來還能夠支持容器（這一點可能挺有意思），未來將支持EDMM（Enclave Dynamic Memory Management）。
EDMM這是個SGX v2新增的機制，背後由新增的硬件指令實現，目的是說SGX v1時候，我一開始聲明Enclave多大，那加載起來的Enclave就那麼大，大小不能再改了，SGX v2增加EDMM，讓Enclave可以建立以後，也就是運行的時候動態申請新的EPC頁，滿足Enclave大小的變化。
SGX軟件層改進
Eleos(EuroSys’17)
文章首先講了SGX帶來的開銷。第一點，SGX帶來的直接開銷：進出Enclave要3300/3800週期，而系統調用也就250週期；LLC Miss開銷是非Miss下的5.6~9.5倍；EPC頁換入換出硬盤Swap區需要40,000週期。第二點，SGX帶來的間接開銷：由於安全期間進出Enclave會刷新TLB（LLC我忘了是否刷新，L1在Intel的微碼補丁之前是不刷新，Foreshadow的出現導致Intel也做L1的刷新了。），LLC污染會造成2倍延遲、TLB污染可能造成6倍延遲。
上述實驗結果主要說明了進出Enclave開銷大。無論是正常的Enclave退出還是頁錯誤之類的問題導致Enclave退出（AEX）都會帶來很大的延遲，因此通過非Enclave退出的方式——RPC，來替換Enclave退出的功能；而關於頁錯誤則通過一個安全的用戶空間頁表機制SUVM（沒細究，值得看，見下圖，大概是說軟件實現了虛實地址翻譯工作，Enclave頁表也放在Enclave內部，原來都是統一用的內核頁表，如果發現有頁被換出到普通內存，那麼就Enclave內部仿真一個錯誤處理機制【這個不確定是不是軟件仿真】，將換出到普通內存的EPC頁再放回EPC中，並完成完整性度量）來避免Enclave退出。相比與改進之前的SGX，Eleos RPC增加23%帶寬，Eleos RPC+SUVM增加50%帶寬，可喜可賀。
這裏讓我聯想到了SGX的Switchless模式，Switchless模式大概是說我先專門弄一個線程出來讓他們直接跑在Enclave環境，然後把他們稱爲ECALL工人線程，工人線程自然是用來幹活的。現在我們運行APP，然後APP調用一個ECALL函數，那麼ECALL任務放到任務池，並通知（通過發送Signal）之前一直空轉的ECALL工人起牀幹活了，然後ECALL工人將ECALL任務跑起來。
Eleos和Swithless的區別我還沒細究。
CoSMIX(ATC’19)
這篇光看了視頻，有點沒看懂。
以前，SQLite的fast_read_db之類的函數依賴內存映射文件（mmap），這會調用OS錯誤句柄將內容從硬盤帶到內存，但是OS不可信，因此OS的錯誤處理也不可信。如果使用請求頁面指令（不瞭解，猜測是硬件指令），這個指令的功能和流程定死了，不靈活。如果使用用戶自定義處理句柄，由於會通過OS來調用Enclave內部用戶自定義句柄，流程很長，效率低（而且個人認爲給了OS攻擊的可能性）。
CoSMIX在Enclave內部仿真了頁表機制來完成虛實地址轉換，目標虛擬地址轉變成不可信的物理地址，然後將內容取回EPC，該頁的數據同時會保留到緩存中，可以加快訪問“內存”（怎麼聽着很像SUVM，啥區別？而且前面提到的mmap應該是從硬盤映射到內存吧？值得去看看）。
總的感覺是將頁表機制移入Enclave，通過LibOS來實現，並完成加密內存的解密等操作。會想起Sectum將頁表移入Enclave的做法。
這也體現了有些SGX漏洞就是由於Enclave部分功能需要通過OS來完成（比如頁表機制）產生泄露。通過LibOS實現部分機制可以緩解此類漏洞。
Rust-SGX SDK(CCS’19)百度
Rust語言號稱是一個能夠實現內存安全（不會出現指針越界之類由於指針這個東西導致的問題）的語言，SGX又是個能抵抗特權攻擊CPU特性，兩者優勢互補，就是Rust-SGX了。不過當然不只是這樣，除了能夠用上Rust語言的內存安全性和SGX提供的安全內存，Rust-SGX還讓開發者多了一個使用Rust語言的機會。
看上圖，Rust-SGX下，Enclave可以使用Rust語言書寫，然後會調用Rust庫來使用SGX，Rust庫通過Rust-to-C FFI調用C語言的SGX SDK。
Rust-SGX有一個近親，Fortanix的Rust EDP SDK方案，它將SGX SDK也用Rust重寫，這可以將Rust的內存安全特性實現地更充分。但是百度的Rust-SGX SDK能夠避免SGX SDK的上游更新導致後續又要用Rust重寫，同時C語言的SGX SDK效率比Rust更高（安全性降低）。
百度的Rust-SGX能夠保證除SGX SDK以外的其他部件都是安全的，不會引入新的漏洞，且經過形式化驗證。
Fortanix Rust EDP SDK
以本人淺見發表自身對Intel SGX調研情況，不能保證某些細節均正確，不定期進行內容補充、修正。
如有高見，歡迎討論！
本文爲原創文章。轉載請註明出處，僅供學習，禁止用於出版、發表文章等用途，禁止用於商業用途。侵權者必究。