Are PSLs the Next Big Thing After Serverless? Here’s What You Need to Know

Table of Links

Abstract and I. Introduction

II. Background

III. Paranoid Stateful Lambda

IV. SCL Design

V. Optimizations

VI. PSL with SCL

VII. Implementation

VIII. Evaluation

IX. Related Work

X. Conclusion, Acknowledgment, and References

III. PARANOID STATEFUL LAMBDA

Paranoid Stateful Lambdas (PSLs) provide unifed access to the computation and storage resources of the cloud and edge. They provide access to the abundance of edge servers which have better locality and lower latency than would be available with cloud-only environments. The serverless abstraction enables applications to be transparent about the underlying infrastructure.

\ Paranoid: PSL allows clients to launch a scalable number of distributed workers (i.e. Lambdas) on both cloud clusters and edge servers. Recognizing that servers on the cloud and edge may come from mutually distrustful service providers, PSL executes all the privacy-sensitive programs in secure enclaves, guaranteeing the confidentiality and integrity of all executions.

\ For the threat model, PSL adopts the typical ”cloud/edge attackers” who can listen and tamper with any communications or computations. For example, the attack may come from a compromised operating system kernel or a malicious staff member, both situations in which the attacker has full control over the system. SCL guarantees the confidentiality, integrity, and provenance of any data in execution and in transit. The trusted computation base (TCB) of SCL is limited to the processor chip, PSL code, and sandboxed application code running in an enclave, which explicitly excludes the operating system managed by the cloud provider. The design of SCL guards against message replay attacks and detects DDoS attacks at a granularity of a user-defined time interval (epoch). However, PSL does not guarantee against sidechannel attacks, given that Intel SGX suffers from various side-channel vulnerabilities [11, 13, 36]. However, there are various techniques [11, 31, 36, 37] proposed to mitigate the risk of side channel attacks.

\ Stateful: Beyond other secure FaaS implementations [5], PSL supports stateful execution of distributed workers, meaning that one in-enclave worker is able to communicate with workers in other enclaves or even workers that will be executed in the future [38]. Statefulness has already become a necessity in

\

\ many popular FaaS applications: for example, ExCamera [18], numpywren [33], mplambda [23].

\ In order for Lambdas to be Paranoid and Stateful, PSL consists the following main components: (1) Secure Concurrency Layer (SCL): enables secure communication between multiple enclaves, (2) In-Enclave LSM-tree based DB: provides persistence and durability of the DataCapsule, (3) PSL Secure FaaS: securely attests SCL, distributes cryptographic keys, and dispatches tasks to Worker Enclaves, and (4) Global Data Plane [29]: provides global routing infrastructure.

\ Secure Consistency Layer: In designing PSL, we recognize the need to have a secure layer that allows enclaves to communicate and concurrently share objects. This layer provides security and consistency semantics for transient messages over untrusted and unordered multicast. Consequently, distributed worker programs can use this layer as a form of shared memory, and PSL as a whole can use this layer to dispatch program scripts and coordinate idle secure enclaves. An analogy to this layer is BigTable for Google or Dynamo for Amazon, infrastructure which provides a KVS layer as foundational communication abstraction to higher level applications.

\ To enhance performance, we designed an eventuallyconsistent replicated KVS that presents a shared memory view to all the secure enclaves connected to the same network multicast tree. If an enclave makes KVS updates to the local cache, the changes will be propagated to all other secure enclaves by broadcast. The secure enclaves maintain the same copy of memory cache. SCL partitions the KVS into a memtable that fits in main memory, and PSL has a Log-Structured Merge (LSM) tree inspired by RocksDB [40] that stores inactive keys.

\

:::info Authors:

(1) Kaiyuan Chen, University of California, Berkeley (kych@berkeley.edu);

(2) Alexander Thomas, University of California, Berkeley (alexthomas@berkeley.edu);

(3) Hanming Lu, University of California, Berkeley (hanming lu@berkeley.edu);

(4) William Mullen, University of California, Berkeley (wmullen@berkeley.edu);

(5) Jeff Ichnowski, University of California, Berkeley (jeffi@berkeley.edu);

(6) Rahul Arya, University of California, Berkeley (rahularya@berkeley.edu);

(7) Nivedha Krishnakumar, University of California, Berkeley (nivedha@berkeley.edu);

(8) Ryan Teoh, University of California, Berkeley (ryanteoh@berkeley.edu);

(9) Willis Wang, University of California, Berkeley (williswang@berkeley.edu);

(10) Anthony Joseph, University of California, Berkeley (adj@berkeley.edu);

(11) John Kubiatowicz, University of California, Berkeley (kubitron@berkeley.edu).

:::

:::info This paper is available on arxiv under CC BY 4.0 DEED license.

:::

\