提要

本期推送是對ICDE 2021 中發(fā)表的論文《TWINE：An Embedded Trusted Runtime for WebAssembly》的解讀。WebAssembly是一種越來越流行的輕量級二進制指令格式。這篇論文描述了TWINE，這是一個WebAssembly trusted runtime，它能夠支持編譯為wasm的應(yīng)用運行。TWINE提供了一個安全的軟件runtime（沙箱），它嵌入在TEE中；并且提供WASI interface，通過WASI來抽象底層環(huán)境。TWINE會動態(tài)地將WASI操作翻譯為等價的OS calls和SGX中的安全的庫。特別地，作者使用TWINE實現(xiàn)了一個安全、可信的SQLite版本，這是一個眾所周知的成熟的可嵌入數(shù)據(jù)庫。作者認為這樣一個受信任的數(shù)據(jù)庫將是構(gòu)建許多大型應(yīng)用程序服務(wù)的合理組件。評估表明，SQLite可以通過WebAssembly和現(xiàn)有的系統(tǒng)接口在SGX enclave內(nèi)完全執(zhí)行，平均性能開銷類似。額外的安全保證及其與標(biāo)準WebAssembly的完全兼容性在很大程度上彌補了性能上的損失。

研究背景

可信代碼執(zhí)行目前是分布式系統(tǒng)的主要挑戰(zhàn)之一。無論是云中的大型數(shù)據(jù)中心，還是瘦客戶機和物聯(lián)網(wǎng)設(shè)備上的網(wǎng)絡(luò)邊緣，其中存儲了許多的數(shù)據(jù)資產(chǎn)。這些數(shù)據(jù)是許多公司的關(guān)鍵資產(chǎn)。例如像Intel SGX、ARM TrustZone等等這些TEE環(huán)境（Trusted execution environment，可信執(zhí)行環(huán)境）就可以通過特殊的硬件結(jié)構(gòu)為代碼安全執(zhí)行提供硬件支持，從而可以從外界環(huán)境中被保護出來，或者說隔離出來，這些外界環(huán)境包括操作系統(tǒng)和特權(quán)用戶。

然而，盡管涌現(xiàn)出了許多framework和runtime environment，為TEE編寫應(yīng)用程序仍然是一項復(fù)雜的任務(wù)。開發(fā)人員通常必須使用定制的工具和api，而且僅支持少數(shù)的編程語言。所以，作者提出了支持對unmodified applications執(zhí)行的trusted runtime，這個runtime作為一個virtual machine運行在TEE中，只需將application編譯為WebAssembly，因為Wasm是不限制語言的。因為Wasm自身的一些優(yōu)點，這個trusted runtime具有執(zhí)行速度快、通用性好（支持多種語言開發(fā)的application）、安全（沙箱環(huán)境）等優(yōu)勢。

圖1：研究背景示意圖

系統(tǒng)設(shè)計

作者設(shè)計的Trusted runtime是運行在TEE中的。Intel SGX 是在現(xiàn)代英特爾處理器中的一組處理器指令，程序員可以通過使用 SGX 創(chuàng)建內(nèi)存的加密區(qū)域，稱為enclaves。通過enclave內(nèi)部的指令對其中內(nèi)存內(nèi)容進行讀寫操作時會自動加密和解密。Enclave加密密鑰保存在處理器內(nèi)部，沒有任何指令可以訪問這些密鑰，即使當(dāng)運行高級硬件特權(quán)級別時，操作系統(tǒng)、虛擬機管理員也無法獲取。Enclave內(nèi)的內(nèi)存受到保護，不接受任何未經(jīng)授權(quán)的訪問，甚至不接受具有物理訪問權(quán)限的機器管理員的訪問。

圖2：SGX工作示意圖

對enclave中的內(nèi)存訪問通過一個大塊的緩存來加速，這個cache memory被稱為enclave page cache（EPC）。EPC的大小是受限的，在最新的CPU中支持最大為256MB的EPC。處理器在 EPC 中保存所有 enclave page 的未加密副本，并且當(dāng) EPC 滿的時候采用分頁。并且硬件還為EPC中的所有enclave page維護加密hash表。enclave內(nèi)部的指令可以訪問enclave外部的數(shù)據(jù)，但是調(diào)用enclave外部的指令需要一個特殊的out call指令（OCALL）。當(dāng)調(diào)用OCALL時，CPU退出受保護的enclave，在外部執(zhí)行代碼。相反，有一個enclave call（ECALL）指令來調(diào)用enclave內(nèi)的代碼。OCALL和ECALL指令會比較慢，因為在enclave內(nèi)部和外部之間切換上下文的代價很高（在最新的服務(wù)器級處理器中，高達13’100個CPU周期）。已有的工作已經(jīng)證明，在enclave中的應(yīng)用程序應(yīng)該盡量避免這樣的調(diào)用，以減少性能損失。

作者提出了TWINE （Trusted Wasm in enclave），這是一個運行在TEE中的輕量級可嵌入Wasm虛擬機。圖3中描述了TWINE的workflow。它充當(dāng)應(yīng)用程序與底層TEE、OS和硬件之間的適配層。TWINE提供了嵌套在TEE中的安全軟件運行時（沙箱），支持WASI接口，并從應(yīng)用程序中抽象出底層環(huán)境。

圖3：TWINE workflow

TWINE是一個適用于在TEE中運行Wasm應(yīng)用程序的執(zhí)行環(huán)境。它主要由兩個主要模塊構(gòu)成： Wasm runtime 和 WASI接口。Wasm runtime 完全運行在TEE內(nèi)部，作者使用的TEE是Intel SGX。作者通過利用TEE的保護來為運行Wasm application提供一個可信環(huán)境。WASI充當(dāng)受信任和不受信任環(huán)境之間的橋梁，抽象出專用于與底層操作系統(tǒng)通信的機制。因此，WASI相當(dāng)于由OCALLs組成的傳統(tǒng)SGX適配層。WASI能夠通過沙箱實現(xiàn)安全性。常規(guī)應(yīng)用程序通常通過標(biāo)準接口（例如POSIX）調(diào)用操作系統(tǒng)。WASI在Wasm操作系統(tǒng)調(diào)用和實際的操作系統(tǒng)接口之間增加了一層（薄薄的）控制層。因此，runtime環(huán)境可以自己限制各個Wasm程序所能做的事情，從而阻止Wasm代碼使用運行進程的用戶的全部權(quán)限。（例如，WASI實現(xiàn)可以將應(yīng)用程序限制在文件系統(tǒng)的子樹中，這與chroot提供的功能類似。）在enclave中的代碼和數(shù)據(jù)被認為是可信的，在此之外的進程部分、操作系統(tǒng)和（任何hypervisor）都可能是敵對的、惡意的。enclave內(nèi)部的內(nèi)存只能從外部以加密的形式讀取。從外部寫入enclave會導(dǎo)致enclave終止。

圖4：TWINE 架構(gòu)

通過WASI，能夠?qū)崿F(xiàn)三重抽象：

（1）開發(fā)人員可以自由選擇編程語言，并通過compiler將它編譯為Wasm binaries。

這解除了SGX強加的限制，之前通常因為這個限制強制應(yīng)用程序必須用C/C++編寫。

（2）將TEE從應(yīng)用程序中抽象出來，只要TEE能夠解釋或執(zhí)行Wasm （帶有WASI支持），應(yīng)用程序就可以安全執(zhí)行。

這為其他TEE技術(shù)打開了大門。

（3）WASI是與系統(tǒng)無關(guān)的，只要操作系統(tǒng)能夠提供WASI所需的等效API。

由于WASI模擬POSIX系統(tǒng)的系統(tǒng)調(diào)用，許多Unix變體都可以實現(xiàn)它。

圖5：WASI的三層抽象

作者選擇了一個已有的Wasm runtime project-WAMR來作為runtime，并修改了它的WASI接口。WAMR支持解釋器、JIT、AoT三種方式的Wasm binaries執(zhí)行。但是考慮到速度的問題，native code執(zhí)行起來比解釋器快。并且，解釋器環(huán)境相對runtime而言，占用內(nèi)存更大，這對于邊緣計算又是很重要的。因此，作者放棄了WAMR中interpreter的方式。又因為JIT方式是運行時即時編譯，需要在一個enclave中嵌進來一個JIT compiler。所以就要在enclave中引入LLVM machinery，這需要移植代碼庫來編譯SGX的限制。所以最終作者采用了AOT的方式。

WAMR中原生的對WASI的實現(xiàn)，嚴重依賴于POSIX調(diào)用。POSIX在SGX enclave中不可用，因此WAMR作者編寫的WASI實現(xiàn)需要頻繁地跨越enclave的可信邊界，并使用OCALLs直接將大多數(shù)WASI函數(shù)路由到它們的POSIX等效函數(shù)。出于性能原因：大多數(shù)WASI調(diào)用將被簡單地轉(zhuǎn)換為OCALLs。其次，作者希望能夠利用其可信實現(xiàn)，例如英特爾保護的文件系統(tǒng)（IPFS）。因此，作者重構(gòu)了WAMR的WASI實現(xiàn)，以保持其沙箱實施。

實驗評估

如圖6所示，作者使用 PolyBench/C benchmarks 來作為實驗的benchmark，展示了30個PolyBench/C （v4.2.1-beta）測試的結(jié)果。通過native執(zhí)行時間來進行標(biāo)準化，比較了WAMR for wasm和TWINE for wasm in TEE的執(zhí)行時間，結(jié)果如圖所示。Wasm應(yīng)用程序通常比本機應(yīng)用程序慢，由于

（1）寄存器壓力增加

（2）更多的分支語句

（3）代碼大小增加等等

但是WAMR和TWINE之間的差距較小。

圖6：PolyBench/C benchmark的性能測試，標(biāo)準化到native speed

SQLite是一個被廣泛使用的成熟的嵌入式數(shù)據(jù)庫。由于其便攜性（portability）和緊湊的尺寸（compact size），它非常適合SGX。并且SQLite能夠體現(xiàn)出性能密集型的操作和文件系統(tǒng)交互，所以作者也對它進行了評估。作者使用了SQLite自己的性能測試程序Speedtest1，運行了32個可用測試中的29個，覆蓋了大量場景。每個Speedtest1實驗都針對于數(shù)據(jù)庫的一個方面，（例如，使用多個關(guān)節(jié)進行選擇，更新索引記錄，等等）。測試由任意數(shù)量的SQL查詢組成，根據(jù)生成的負載可能會執(zhí)行多次。圖7中顯示了測試的結(jié)果，以native execution為標(biāo)準進行了標(biāo)準化。（其中包括內(nèi)存中配置的結(jié)果，以及使用WASI的持久化數(shù)據(jù)庫的結(jié)果。）作者在所有測試中觀察到，對于in-memory數(shù)據(jù)庫和in-file數(shù)據(jù)庫，WAMR相對于本地數(shù)據(jù)庫平均慢4.1x和3.7×。

在in-memory和in-file數(shù)據(jù)庫中，TWINE相對于WAMR的速度慢了1.7x和1.9x。

圖7：在SQLite Speedtest1 benchmark上的相對性能

為了更好地理解所觀察到的性能損失的來源，作者為常見的數(shù)據(jù)庫查詢設(shè)計了一套測試，包括插入、順序讀取和隨機讀取。根據(jù)對這三類操作的執(zhí)行時間分析，得出以下結(jié)果：

（1）圖8a顯示了關(guān)于插入記錄的結(jié)果。

由于額外的文件加密，使用TWINE的持久數(shù)據(jù)庫的操作成本線性增加。

（SGX-LKL在插入順序元素方面有更優(yōu)的方法，并遵循了TWINE的內(nèi)存性能趨勢。）

（2）圖8b顯示了順序讀取所有記錄的執(zhí)行時間。

作者在SGX內(nèi)存訪問中發(fā)現(xiàn)了造成這種性能損失的根本原因。

（3）圖8c描述了隨機讀取的執(zhí)行時間。

隨機讀取更加經(jīng)常地觸發(fā)enclave分頁機制，文件內(nèi)隨機讀取的例子突出了TWINE的優(yōu)點，它提供了比SGX-LKL更快的性能，EPC（enclave page cache）限制之前為1.031×，之后為1.074×。在EPC限制以上的內(nèi)存內(nèi)插入也會有類似的性能提升，增益為1.035×。

圖8：對SQLite的插入和讀取進行性能評估

結(jié)論

這篇論文設(shè)計并實現(xiàn)了TWINE以支持編譯為wasm的應(yīng)用運行。TWINE提供了一個安全的軟件runtime（沙箱），它嵌入在TEE中；并且提供WASI interface，通過WASI來抽象底層環(huán)境。評估表明，SQLite可以通過WebAssembly和現(xiàn)有的系統(tǒng)接口在SGX enclave內(nèi)完全執(zhí)行，并且平均性能開銷類似。

原文標(biāo)題：思辨｜WebAssembly的嵌入式可信運行時

文章出處：【微信公眾號：Linux閱碼場】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。