Yuki Nakata

In edge computing, flexibly offloading or handing over computing workloads among devices, edge, and cloud, achieved by live migration, is crucial because of its hierarchical and heterogeneous structure. Implementing the process migration requires the runtime system to capture and restore the state of a running application at any arbitrary time. WebAssembly (Wasm) has attracted attention as a common platform for edge computing since it provides not only architecture neutrality and secure sandboxing as a lightweight VM but also performs at a native-level performance with AOT/JIT code optimization. Unfortunately, the different code optimizations in various Wasm runtimes make it harder to insert instrumentation code into application binary at runtime. We are currently developing a self-hosted Wasm runtime, i.e., a runtime that can be executed on another runtime as a Wasm application instrumentation mechanism while handling the runtime heterogeneity, including AOT/JIT code transformation. One of the major concerns in our proposal is the overhead caused by the intervention of another runtime for instrumentation. This study discusses the feasibility of a self-hosted runtime with instrumentation for obtaining the application’s running state by comparing it with existing methods and evaluating it through preliminary experiments.

Containers, which have evolved in Linux primarily, have become a significant trend in the cloud due to their lightweight virtualization and growing convenient ecosystem. However, the laxer isolation of containerization also introduces attack surfaces on the underlying Linux kernel. Unfortunately, combining other virtualizations, such as the traditional VM and interposition by application kernel, for sandboxing could spoil the lightweight and scalable nature of the containers. In this study, we propose another approach to lightweight sandboxing that focuses on the fact that such attackers have mostly assumed containers rely on Linux. It can avert major vulnerability exploits derived from Linux by transplanting Linux containers onto the FreeBSD kernel. Furthermore, it can fortify the isolation by transparently applying "Capsicum," a unique sandbox mechanism that is nonstandard in Linux, to the transplanted containers. This paper analyzes vulnerabilities faced by Linux containers, identifies technical issues in transplanting Linux containers onto FreeBSD, and designs a mechanism to transparently apply the Capsicum sandbox to Linux applications to explore the feasibility of our approach.

Containers provide a lightweight and fine-grained isolation for computational resources such as CPUs, memory, storage, and networks, but their weak isolation raises security concerns. As a result, research and development efforts have focused on redesigning truly sandboxed containers with system call intercept and hardware virtualization techniques such as gVisor and Kata Containers. However, such fully integrated sandboxing could overwhelm the lightweight and scalable nature of the containers. In this work, we propose a partially fortified sandboxing mechanism that concentratedly fortifies the network isolation, focusing on the fact that containerized clouds and the applications running on them require different isolation levels in accordance with their unique characteristics. We describe how to efficiently implement the mechanism to fortify network isolation for containers with a para-passthrough hypervisor and report evaluation results with benchmarks and real applications. Our findings demonstrate that this fortified network isolation has good potential to tailor sandboxes for containerized PaaS/FaaS clouds.