Large Language Models (LLMs) deployed on mobile devices offer benefits like user privacy and reduced network latency, but introduce a significant security risk: the leakage of proprietary models to end users.

VM-level containers provide strong isolation by running each container with its own kernel in a VM. However, they rely on virtualization hardware designed for general-purpose VMs, causing non-negligible performance overhead compared to OS-level containers. This performance gap widens dramatically in nested virtualization scenarios, where secure containers run inside a VM.

Containers are widely deployed in clouds. There are two common container architectures: operating system-level (OS-level) container and virtual machine-level (VM-level) container. Typical examples are runc and Kata. It is well known that VM- level containers provide better isolation than OS-level containers, but at a higher overhead. Although there are quantitative analyses of the performance gap between these two container architectures, they rarely discuss the performance gap under the constrained resources nrovisioned to containers. Since the high-density deployment of containers is demanding in the cloud, each container is provisioned with limited resources specified by the cgroup mechanism. In this paper, we provide an in-depth analysis of the storage and network (two key aspects) performance differences between runc and Kata under varying resource constraints. We identify configuration implications that are crucial to performance and find that some of them are not exposed by the Kata interfaces. Based on that, we propose a profiling tool to automatically offer configuration suggestions for optimizing container performance. Our evaluation shows that the auto-generated configuration can improve the performance of MySQL by up to 107% in the TPCC benchmark compared with the default Kata setup.

Major operating system kernels expose twin functions, which are groups of internal primitives that have mostly common but slightly diverging semantics, to kernel modules and subsystems. They are created to make the basic primitives work well in various scenarios. Unfortunately, though being expected as solutions, twin functions may turn to problem-makers in practice. As we have observed from over 500 patches applied to upstream Linux and FreeBSD, developers choose an improper one from the twins, leaving the kernel with stability and security bugs as well as error-prone code. In this paper, we aim to understand and mitigate the twin function misuse problem. First, we provide an informative discussion on the misuse-fix patches. We find that violating the constraints from calling context, missing the primitives with better performance, lacking the necessary security enhancements, and breaking the kernel coding style are the four major factors that lead to misuse. We then identify the programming rules from the patches and apply them with a static program analysis tool extended from Coccinelle, including callgraph tainting and type-based function pointer resolving. We have 136 patches accepted by the Linux community and fix 320 new misuses in the upstream Linux kernel.