2 背景
2.2 SGX Software Design Space
為了把傳統應用放到SGX中，Graphene-SGX等Shielding Framework面臨的一個問題是把多少功能給塞進Enclave中。為了確定性能開銷小，兩個重要的考量名額是：
- 由于Enclave切換環境開銷大，應盡量減少進出Enclave。
- 由于Enclave實體記憶體（EPC）有限，應避免過度使用記憶體導緻EPC出現Swap，進而影響性能。
具體實施起來應該考慮的點如下：
Shielding複雜性 應用放到Enclave後，有時候必須要一些核心功能，對此需要開放接口使用不可信的核心并檢查傳回值（Shield）。此時接口開放得越少，接口的邏輯複雜性越低，實作所需代碼越少，防範Iago Attack越輕松。
應用代碼複雜性 傳統應用代碼邏輯複雜度不盡相同，移植到Enclave的做法也不盡相同。
- 移植到Enclave中的應用的邏輯盡可能簡單純粹，避免涉及Runtime，避免頻繁跨越Enclave邊界。
- 有些移植到Enclave的應用還是需要一些Enclave内無法實作的功能，對此需要開放一些Enclave接口，OCALL到Enclave外實作某些功能并檢查傳回值。
- 在Encalve内塞全功能的LibOS/Shim，如此能很好地相容傳統應用，還支援系統調用等。
應用拆分 待移植的應用可以将功能拆分，分别放入不同Enclave執行個體中，這能提升安全。為此Shielding Framework應該能夠支援較小的代碼如Library，并確定Enclave間能共享狀态。
3 設計
3.1 威脅模型
我們可以相信CPU、Enclave代碼以及AESMD(Intel簽名的Architectural Enclave)。（注：如果能找到AE的漏洞，那感覺影響挺大）
我們會用到SGX驅動，但并不相信它，但我們可以通過CPU硬體指令驗證SGX驅動沒幹壞事。
我們不相信其它任何東西。
3.2 使用者政策配置
擴充了Enclave Manifest檔案（如這裡），需要開發者先驗地指明配置。
- 要求開發者在Manifest中事先聲明好要用的系統資源（如fs、network），保護Host避免Enclave濫用資源；
- 在Manifest中指定Enclave信任的外部檔案的hash，確定該檔案未被修改（完整性保護）；
- 在Manifest中指定Enclave會往外寫的檔案，但無法確定機密不外洩（無機密性保護）。
3.3 多程序應用
實作了使用者态Enclave Fork（如何實作的？），每個程序的Enclave内的LibOS執行個體間通過消息傳遞來複制父Enclave内容并同步狀态，存在如父子等協作關系的Enclaves同屬于Enclave Group。
4 保護Linux抽象（以防不可信Host OS）
4.1 保護動态加載
PAL讓SGX驅動初始化Enclave，從Shield開始動态加載、運作時連結，形成圖3的架構。
記憶體權限 ELF加載、連結時需要動态地改變Page的權限。但是SGXv1 Enclave記憶體權限在初始化時就确定了，是以需要事先将所有Page權限标記為RWX，雖然存在安全風險及功能不相容的情況。
位置相關可執行檔案 往往從0x400000位址起始，為了包含0x400000位址并滿足SGX要求（ E n c l a v e S i z e = 2 x EnclaveSize=2^x EnclaveSize=2x，起址對齊到EnclaveSize，即 E L R A N G E = n ⋅ 2 x ∼ ( n + 1 ) ⋅ 2 x ELRANGE=n\cdot2^x\sim(n+1)\cdot2^x ELRANGE=n⋅2x∼(n+1)⋅2x），ELRANGE 勢必包含0位址。ELRANGE包含0位址并将其Unmap，能避免不可信OS操控0位址破壞Enclave完整性。
4.2 保護單程序抽象
LibOS基于PicoProcess及PAL。PAL實作了36個函數。Enclave接口縮減至28個以向外調用不可信OS。（細節尚需看一下源碼）
檔案認證 通過建構Merkel Tree與Manifest中的Hash比對驗證。
記憶體映射 Manifest事先聲明預留多少堆記憶體，確定能緩存檔案等。（感覺還友善有足夠空間進行自定義的記憶體布局）
線程模型 未來基于支援動态建立線程的SGXv2，可以實作m:n的線程模型，友善異步調用提升性能（多個網絡請求的場景）
異常處理 SGX硬體AEX傳回後，利用SSA傳遞信号讓LibOS模拟異常。（能夠變相地在SGX内提供本不支援的硬體指令，如cpuid和rdtsc）
4.3 保護多程序抽象
Enclave間不能共享記憶體，Graphene-SGX通過消息傳遞而非共享記憶體實作多程序支援、Signal、System V IPC。
Enclave fork 流程如圖4，父程序基于加密信道傳遞上下文快照給子程序以初始化。
Enclave execve 由于實作時的安全性考慮，隻能執行Manifest中指定的可信程式。
Enclave IPC 通過Enclave間RPC消息傳遞實作。
5 評估
測量應用移植到Graphene-SGX上的吞吐量或延遲。
5.1 伺服器應用
| 應用 | 開銷要因 |
|---|---|
| Aphene | IPC密集型遇到加密RPC導緻表現變差 |
| NGINX | 主要因為事件驅動單線程型遇到Graphene-SGX隻支援同步IO導緻表現變差 |
| 其他原因包括SGX固有開銷 |
5.2 指令行應用
| 應用 | 開銷要因 |
|---|---|
| R | 記憶體配置設定和垃圾回收會造成明顯性能開銷。因為現有實作假設記憶體很大，布局稀疏，而SGX1要求Enclave記憶體建立時映射。 |
| GCC | Enclave初始化 |
| CURL | I/O延遲 |
5.3 性能開銷分析
| 操作 | 開銷要因 |
|---|---|
| 打開檔案 | 第一次打開檔案時預加載檔案内容建構Merkel Tree并計算Root Hash和Manifest比對 |
| 讀檔案 | 驗證讀取的檔案塊 |
| fork | 建立新Enclave、本地認證、上下文複制時無法批量IPC（Graphene-SGX不支援m:n線程模型及異步調用） |
5.4 TCB大小和功能性比較