Hypervisor & Protected VMs

Protected Virtual Machines (pVMs) represent the highest level of isolation in the Android ecosystem. Driven by the Protected KVM (pKVM) hypervisor, pVMs guarantee that not even a fully compromised host kernel can read or modify the guest VM's memory or execution state.

pKVM (Protected KVM) Architecture

Traditional KVM (Kernel-based Virtual Machine) runs within the Linux kernel (EL1 in ARM architecture) and relies on the kernel for resource management. If the host kernel is rooted, the hypervisor and all VMs are compromised.

pKVM modifies this architecture by splitting KVM. A small, highly trusted hypervisor component is moved into a higher, more privileged execution level (EL2 on ARMv8). The primary host Android OS runs in EL1, completely deprivileged relative to the pKVM core.

When the host wants to manage a VM, it makes hypercalls to pKVM at EL2, which enforces strict security boundaries before fulfilling the request.

Stage-2 Page Table Isolation

Memory isolation is achieved through nested paging, specifically Stage-2 page tables on ARM.

• Stage-1: Translates Virtual Addresses (VA) to Intermediate Physical Addresses (IPA). Managed by the guest OS (or host OS).
• Stage-2: Translates IPA to actual Physical Addresses (PA). Exclusively managed by the pKVM hypervisor at EL2.

pKVM maintains separate Stage-2 page tables for the Host OS and every Protected VM. The hypervisor mathematically ensures that a physical page of memory mapped to a pVM is strictly unmapped from the Host OS's Stage-2 page tables.

Protected VM Memory: Host Cannot Access

Because the host kernel's Stage-2 page tables do not contain the physical addresses belonging to the pVM, any attempt by the host (even kernel-level code or DMA from peripherals) to access pVM memory results in a hardware memory fault triggered by the MMU/IOMMU.

If a pVM needs to share data with the host (e.g., for virtio communication), it explicitly makes a hypercall to pKVM to "donate" or "share" a specific memory page back to the host, transitioning its state in the page tables.

// Conceptual representation of pKVM memory protection
void protect_guest_page(uint64_t phys_addr, uint16_t vmid) {
    // Remove page from Host's Stage-2 tables
    unmap_stage2(HOST_VMID, phys_addr);
    // Map page exclusively to Guest's Stage-2 tables
    map_stage2(vmid, phys_addr, PROT_READ | PROT_WRITE);
}

Remote Attestation for Protected VMs

How does an external server know it is talking to a secure pVM and not an emulator or a compromised host? This is solved via Remote Attestation.

When a pVM boots, the hypervisor generates a cryptographic attestation report. This report contains:

• Measurements (hashes) of the pVM's bootloader, kernel, and payload (Microdroid).
• Hardware-backed signatures chained to the device's physical Root of Trust (e.g., Titan M chip).

The pVM payload sends this report to the remote server. The server verifies the signature and the measurements. If they match the expected secure configuration, the server securely provisions secrets (like DRM keys or ML model weights) directly into the pVM.

Security Guarantees of pKVM

pKVM provides a rigorous threat model:

1. Confidentiality: Host cannot read pVM memory or register states.
2. Integrity: Host cannot modify pVM memory or inject code.
3. Secure Boot: pVM execution is guaranteed to start from an immutable, verified state.

You can verify if pKVM is active on a device using dmesg:

adb shell dmesg | grep "kvm"
# Look for initialization messages indicating "Protected KVM" or "EL2"