Twine: An Embedded Trusted Runtime for WebAssembly

Abstract

WebAssembly is an increasingly popular lightweight binary instruction format, which can be efficiently embedded and sandboxed. Languages like C, C++, Rust, Go, and many others can be compiled into WebAssembly. This paper describes TWINE, a WebAssembly trusted runtime designed to execute unmodified, language-independent applications. We leverage Intel SGX to build the runtime environment without dealing with language-specific, complex APIs. While SGX hardware provides secure execution within the processor, TWINE provides a secure, sandboxed software runtime nested within an SGX enclave, featuring a WebAssembly system interface (WASI) for compatibility with unmodified WebAssembly applications. We evaluate TWINE with a large set of general-purpose benchmarks and real-world applications. In particular, we used TWINE to implement a secure, trusted version of SQLite, a well-known full-fledged embeddable database. We believe that such a trusted database would be a reasonable component to build many larger application services. Our evaluation shows that SQLite can be fully executed inside an SGX enclave via WebAssembly and existing system interface, with similar average performance overheads. We estimate that the performance penalties measured are largely compensated by the additional security guarantees and its full compatibility with standard WebAssembly. An indepth analysis of our results indicates that performance can be greatly improved by modifying some of the underlying libraries. We describe and implement one such modification in the paper, showing up to 4.1× speedup. TWINE is open-source, available at GitHub along with instructions to reproduce our experiments.

WebAssembly as a Common Layer for the Cloud-edge Continuum

“…Wasm is naturally slower than native because of the increasing of register pressure and code size and the presence of extra branch statements, as discussed in previous work [17]. In some rare cases, Wasm may be faster than native thanks to a reduced number of cache misses, as we observed in our previous work [24]. Finally, some workloads are not well optimised when compiled in Wasm and then recompiled ahead-of-time into native code, as can be observed for the Arm versions on the left-hand side of Figure 2.…”

“…While TEEs are not demonstrated in this work, these two platforms support trusted execution, namely Intel SGX for the former and Arm TrustZone for the latter. We already illustrated how Wasm could be embedded within SGX and TrustZone in our previous work [24,25].…”

“…PolyBench/C [29] is a CPU-bound benchmark suite comprised of various mathematical experiments and commonly used to evaluate the performance of Wasm applications and runtimes [17,13,24]. The name of the experiments have been abbreviated in this paper for conciseness.…”

Understanding TEE Containers, Easy to Use? Hard to Trust

“…To analyze these TEE containers, we propose a taxonomy including a set of key security properties expected from a Tcon: 1) their threat models, 2) their supports for isolation between the untrusted OS and the container (through Ecall/Ocall/exception interfaces), 3) their supports for isolation within the container (particularly for those running untrusted code), 4) their mechanism for attestation, 5) protection for storage and 6) their side-channel control. These properties are summarized from Tcon-related publications [105], [109], [50], [87], [80], [62], [81], [61], [59], [97], [48], [74] and documentations [18], [26], [34], [13]. In the rest of the section, we first present popular Tcons and their backgrounds, and then analyze them using the taxonomy.…”

“…• TWINE. TWINE [81] leverages WebAssembly-Micro-Runtime (WAMR) [46] to run WASM code with WASI support. C/C++ and Rust source code developed for Linux can be easily compiled into WASI target, and TWINE also provides a SQLite example.…”