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.

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).