Lightweight, Secure and Stateful Serverless Computing with PSL

TL;DR

The PSL framework is designed to efficiently operate within an asynchronous environment with a distributed tamper-proof confidential storage system, assuming minority failures, and the execution of PSL is up to 3.7x faster than the state-of-the-art SGX WASM runtime.

Abstract

We present PSL, a lightweight, secure and stateful Function-as-a-Serivce (FaaS) framework for Trusted Execution Environments (TEEs). The framework provides rich programming language support on heterogeneous TEE hardware for statically compiled binaries and/or WebAssembly (WASM) bytecodes, with a familiar Key-Value Store (KVS) interface to secure, performant, network-embedded storage. It achieves near-native execution speeds by utilizing the dynamic memory mapping capabilities of Intel SGX2 to create an in-enclave WASM runtime with Just-In-Time (JIT) compilation. PSL is designed to efficiently operate within an asynchronous environment with a distributed tamper-proof confidential storage system, assuming minority failures. The system exchanges eventually-consistent state updates across nodes while utilizing release-consistent locking mechanisms to enhance transactional capabilities. The execution of PSL is up to 3.7x faster than the state-of-the-art SGX WASM runtime. PSL reaches 95k ops/s with YCSB 100% read workload and 89k ops/s with 50% read/write workload. We demonstrate the scalability and adaptivity of PSL through a case study of secure and distributed training of deep neural networks.

Figures (10)

• Figure 1: Use Case of PSL in Distributed Learning Training on Confidential Data. In PSL, we consider privacy-preserving distributed deep learning training on untrusted infrastructure. Contrary to the conventional secure enclave programming interface that forces users to protect their data with hand-crafted remote encryption schemes, PSL provides Function-as-a-Service (Faas) with simple and easy-to-use interfaces, in which users exploit standardized mechanisms to store the function and parameters to servers, verify that an expected function will be executed with confidentiality and integrity, and invoke the function.
• Figure 2: The architecture of PSL: The FaaS Manager launches and attests all worker enclaves. Enclave workers cache key-value pairs in their local Memtable, and share state in an eventually consistent way using a Secure Concurrency Layer (SCL) that takes advantage of a secure-multicast primitive within the network. The PSL-DB tracks the most recent version of the state of each key and pushes updates to a set of replicated networked storage servers that provide state persistence.
• Figure 3: FaaS Manager Launch Sequence Diagram: At initialization time, (1) user securely uploads the function and input to storage server. (2-4) user attests FaaS manager while FaaS manager initializes and attests FaaS workers. When user invokes function, (5) they send a request to FaaS manager and (6) FaaS Manager distributes the request to other workers. The workers pull from storage server and execute the function. (9-11) On completion, the worker uploads the result to storage server and the FaaS Manager routes the response back to the user. The detailed description of the Launch Sequence Diagram and the security protocol can be found in Section \ref{['sec:design:faas']} with the same step indexing.
• Figure 4: (a) Durable Commits. Worker $W_1$ multicasts a batch of write to storage servers ($S_1, S_2, S_3$), other workers ($W_2$) and PSL-DB. It only waits for f + 1 responses from storage servers and progresses to multicast the next batch. (b) View of PSL-DB. It has all the writes from $W_1$. It lags behind $W_3$ and it has missed an intermediate write from $W_2$. The blue line shows a causally consistent cut. The green line is not a causally consistent cut until the PSL-DB back-fills the missing block from $W_2$.
• Figure 5: Execution Cycle Comparison on PolyBench between Twinemenetrey2021twine and PSL. All cycles are normalized by running PolyBench on WAVM (Native) without SGX. WAMR (the runtime of Twine) and WAVM (the runtime of PSL) demonstrate similar Native performance. However, PSL-JIT demonstrates up to 3.7 times latency improvement compared to Twine.

Theorems & Definitions (5)

• Definition 1
• Definition 2
• Definition 3
• lemma 1
• lemma 2