The Android Virtualization Framework enables the execution of security-sensitive workloads in protected virtual machines using trusted hypervisors. We present Aster, an in-depth analysis of the Android Virtualization Framework security model as defined in the Android Compatibility Definition Document. It explores the design space for deploying protected virtual machines across Arm Trusted Execution Environments. Our analysis shows that executing Android in the normal world and protected virtual machines in the realm world using Arm Confidential Computing Architecture achieves the best tradeoff between security and implementation overheads. Aster strengthens Android Virtualization Framework isolation guarantees by introducing improved memory protection to mitigate physical attacks, enhancing independent memory management, deploying per-VM memory encryption, and enforcing stricter privilege separation. We implement and validate Aster on two platforms: functional emulator that supports Android, and a performance prototype on an Arm board that captures microarchitectural aspects. Our in-depth evaluation of impact of Aster on protected virtual machines execution under stress benchmarks (CPU, system, IO) as well as representative applications (public key generation, One-Time-Password, isolated compilation) show the minimal runtime performance impact.

Cloud-centric workloads increasingly leverage domain-specific accelerators (DSAs) such as GPU, NPU, FPGA, etc., to achieve massive speedup over general-purpose CPUs. These workloads compute sensitive data; furthermore, the programs can be proprietary business secrets such as high-performance AI models. Therefore, several confidential cloud solutions have recently emerged to protect against the attacker-controlled software stack (OS/VMM) and the cloud service providers or CSPs themselves. CPU-centric trusted execution environments, or TEEs, have been around for decades and are deployed commercially. However, despite some recent proposals, most nodes lack TEE capability and, therefore, are unprotected against malicious CSP and software stack.We address this gap by proposing a new dedicated hardware module, the security controller (SC), that acts as the TEE proxy for the legacy non-TEE DSA nodes in a data center across racks. SC enforces access control and attestation mechanisms and protects the non-TEE nodes even from a physical attacker. This way, SC enables new-generation TEE-enabled nodes and legacy non-TEE nodes to be used in a data center simultaneously while ensuring security. We implement and synthesize SC hardware and evaluate it with real-world cloud-centric workloads with heterogeneous DSAs. Our evaluation shows that, on average, SC introduces 1.5-5% overhead while running AI, Redis, and file system workloads and scales well with an increasing number of DSA nodes (up to 2236 concurrent NPUs running CNNs).

AMD SEV-SNP offers VM-level trusted execution environments (TEEs) to protect the confidentiality and integrity for sensitive cloud workloads from untrusted hypervisor controlled by the cloud provider. AMD introduced a new exception, #VC, to facilitate the communication between the VM and the untrusted hypervisor. We present WeSee attack, where the hypervisor injects malicious #VC into a victim VM’s CPU to compromise the security guarantees of AMD SEV-SNP. Specifically, WeSee injects interrupt number 29, which delivers a #VC exception to the VM who then executes the corresponding handler that performs data and register copies between the VM and the hypervisor. WeSee shows that using well-crafted #VC injections, the attacker can induce arbitrary behavior in the VM. Our case-studies demonstrate that WeSee can leak sensitive VM information (kTLS keys for NGINX), corrupt kernel data (firewall rules), and inject arbitrary code (launch a root shell from the kernel space).