Google Adapts Linux KVM to Shield Mobile Enclaves Without New Silicon

The Linux Foundation

By enforcing Stage-2 translation on the host kernel via software at EL2, pKVM delivers Intel TDX-level memory isolation on standard Arm chips but faces upstream hurdles over unfixable linear map crashes.

AI-assisted summary of Protected KVM on Arm64: A Technical Deep Dive - Quentin Perret, Google — original source. Check the original for full context.

Source published: 2022-10-08

Key ideas

• Protected KVM (pKVM) extends KVM/arm64 nVHE mode to provide confidential computing on Arm v8.0+ SoCs without specialized hardware extensions like Intel TDX or AMD SEV, enforcing memory isolation via an enlightened EL2 software hypervisor. (0:00)
• The architecture activates Stage-2 MMU translation on the EL1 host kernel itself, identity-mapping host memory while encoding ownership IDs in bits 1–63 of invalid Stage-2 PTEs with zero runtime metadata tree overhead. (12:36)
• To prevent kernel panics when host tools like strace trigger remote user page lookups on donated memory, upstream kernel work is evaluating guest_memfd and secretmem extensions supporting zero-copy in-place memory conversion. (31:16)
• Attestation and secure workloads like 4K DRM rely on a hypervisor-injected bootloader and hardware attestation keys, which Android intentionally revokes upon bootloader unlocking to prevent unauthorized access. (48:15)

Detailed notes

## Background This presentation was delivered by Quentin Perret of Google's Android Virtualization team and published by The Linux Foundation on YouTube on October 8, 2022. According to the page description, the talk is a technical deep dive into Protected KVM (pKVM), an extension of KVM/arm64 that brings confidential computing to Arm v8.0+ architectures without dedicated hardware extensions by managing the CPU's stage-2 MMU from the nVHE EL2 hypervisor.

## TL;DR Quentin Perret details the architecture and upstream Linux kernel implementation of Protected KVM (pKVM) on Arm64. He explains how pKVM elevates the lightweight nVHE EL2 context-switching stub into a hardened hypervisor that enforces stage-2 translation tables on both guests and the untrusted host Linux kernel. The talk walks through platform bootstrapping, memory ownership models tracked via unused software bits in stage-2 PTEs, dynamic memory donation, vCPU lifecycle management, and incremental page zeroing during teardown. Finally, Perret covers major technical hurdles around handling host linear map faults, proposing integrations with mechanisms like guest_memfd/private-fd to accommodate use cases requiring in-place zero-copy page transitions.

## Atmosphere & style The presentation carries the brisk, deeply pragmatic tone of an open-source systems engineer addressing a room of kernel peers, opening with the dry promise: 'here's the cake if you were waiting for it.' It feels rigorous, understated, and unpretentious, methodically navigating complex architectural layers, register bits, and exception vectors without marketing polish or high-level hand-waving. The technical tension peaks around the unsolved problem of host-side linear map crashes, transitioning smoothly into a highly collaborative, whiteboard-style Q&A where attendees and the speaker eagerly brainstorm kernel abstractions and low-level patch designs.

## Bulletin - [00:00](https://www.youtube.com/watch?v=9npebeVFbFw&t=0s) Protected KVM (pKVM) extends KVM/arm64 nVHE mode to provide confidential computing on Arm v8.0+ SoCs without specialized hardware extensions like Intel TDX or AMD SEV, enforcing memory isolation via an enlightened EL2 software hypervisor. - [12:36](https://www.youtube.com/watch?v=9npebeVFbFw&t=756s) The architecture activates Stage-2 MMU translation on the EL1 host kernel itself, identity-mapping host memory while encoding ownership IDs in bits 1–63 of invalid Stage-2 PTEs with zero runtime metadata tree overhead. - [31:16](https://www.youtube.com/watch?v=9npebeVFbFw&t=1876s) To prevent kernel panics when host tools like strace trigger remote user page lookups on donated memory, upstream kernel work is evaluating guest_memfd and secretmem extensions supporting zero-copy in-place memory conversion. - [48:15](https://www.youtube.com/watch?v=9npebeVFbFw&t=2895s) Attestation and secure workloads like 4K DRM rely on a hypervisor-injected bootloader and hardware attestation keys, which Android intentionally revokes upon bootloader unlocking to prevent unauthorized access.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=9npebeVFbFw&t=0s) pKVM delivers guest confidentiality and integrity on standard Arm v8.0+ processors by interposing access-control restrictions via software at EL2 instead of relying on dedicated hardware extensions. - [02:44](https://www.youtube.com/watch?v=9npebeVFbFw&t=164s) Under standard KVM nVHE, the EL1 host kernel operates without Stage-2 translation, giving an untrusted host complete access to physical RAM, guest pages, and hypervisor code. - [05:04](https://www.youtube.com/watch?v=9npebeVFbFw&t=304s) Building the EL2 hypervisor directly into the Linux kernel image allows atomic updates through standard Android over-the-air pipelines and eliminates the need for a frozen, stable hypervisor ABI. - [06:56](https://www.youtube.com/watch?v=9npebeVFbFw&t=416s) During early boot, the host kernel uses the memblock allocator to carve out private physical memory frames scaled proportionally to total system RAM, which EL2 claims exclusively. - [10:21](https://www.youtube.com/watch?v=9npebeVFbFw&t=621s) pKVM manages memory access through a strict ownership model recognizing four distinct page states: Owned, Shared (Lender), Borrowed (Recipient), and Inaccessible. - [12:36](https://www.youtube.com/watch?v=9npebeVFbFw&t=756s) Because the host Stage-2 translation is identity-mapped purely for access control, pKVM repurposes ignored bits 1–63 of invalid PTEs to track owner IDs, assigning ID 0 to the host. - [15:25](https://www.youtube.com/watch?v=9npebeVFbFw&t=925s) To maintain a minimal footprint, the EL2 hypervisor relies on the EL1 host to dynamically donate physical pages for shadow VM metadata, vCPU tracking structures, and guest Stage-2 page tables. - [18:20](https://www.youtube.com/watch?v=9npebeVFbFw&t=1100s) Because EL2 execution is strictly non-preemptible, sleepable synchronization primitives like mutexes are prohibited, restricting hypervisor concurrency control entirely to custom spinlocks. - [23:23](https://www.youtube.com/watch?v=9npebeVFbFw&t=1403s) When a guest triggers a Stage-2 abort, the host takes a long-term page pin to prevent swapping and page migration before donating the backing memory and unmapping it from host Stage-2. - [25:38](https://www.youtube.com/watch?v=9npebeVFbFw&t=1538s) Guests explicitly register valid MMIO GPA ranges via hypercalls so the EL2 hypervisor can mediate host emulation while exposing only necessary transfer registers without leaking general-purpose state. - [31:16](https://www.youtube.com/watch?v=9npebeVFbFw&t=1876s) The primary upstream architectural challenge is host kernel MM: unexpected linear map faults caused by operations like process_vm_readv() cannot be fixed up cleanly and trigger fatal kernel panics. - [35:14](https://www.youtube.com/watch?v=9npebeVFbFw&t=2114s) Guest teardown leverages an incremental, loop-based page reclaim protocol where the host reschedules between individual EL2 hypercalls, avoiding prolonged non-preemptible stalls while zeroing guest memory. - [38:33](https://www.youtube.com/watch?v=9npebeVFbFw&t=2313s) Identity mapping host Stage-2 allows extensive use of large block mappings, reducing TLB miss penalties so that host translation overhead is practically undetectable in benchmarks. - [41:37](https://www.youtube.com/watch?v=9npebeVFbFw&t=2497s) pKVM strictly requires in-place memory conversion rather than fresh buffer copies to support legacy TrustZone workloads like 4K video DRM that pass hundreds of megabytes of media data. - [48:15](https://www.youtube.com/watch?v=9npebeVFbFw&t=2895s) Guest integrity relies on a device bootloader memory carveout that EL2 unmaps from the host; unlocking the device bootloader permanently purges attestation keys, preventing rooted environments from forging protected guest signatures.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=9npebeVFbFw&t=0s) Introduction to Protected KVM (pKVM) on arm64

Quentin Perret introduces himself as an engineer on Google's Android Virtualization team, presenting the ongoing work around Protected KVM (pKVM) on arm64 architectures. The core concept behind pKVM is extending standard KVM for arm64 to deliver confidential computing features even on application processors that lack specialized, proprietary hardware extensions. In terms of security objectives, Quentin explains that pKVM aims to achieve parity with technologies such as Intel TDX or AMD SEV by shielding guest private memory from a potentially compromised or untrusted host kernel. However, its implementation strategy diverges significantly from these hardware-rooted alternatives, relying on an enlightened software hypervisor layer instead.

Quentin notes that this presentation marks the first anniversary of the pKVM codebase, providing a natural milestone to reflect on architectural milestones achieved over the preceding year. Beyond showcasing internal Android work, he emphasizes that the concepts pioneered in pKVM are actively influencing confidential computing approaches across other CPU architectures. A primary motivation for the talk is walking through a substantial patch series posted upstream on the Linux kernel mailing list, demystifying its design to assist kernel maintainers and community reviewers with complex, open design decisions. Quentin establishes a distinctly technical tone for the session: “As opposed to the previous talk, this very much intends to be a technical talk, so here's the cake if you were waiting for it.”

- Target scope: Arm64 SoCs lacking dedicated confidential computing hardware extensions (Arm v8.0+). - Functional comparison: Delivers guest memory confidentiality and integrity protections conceptually equivalent to Intel TDX and AMD SEV. - Upstream status: A comprehensive patch series is actively undergoing public review on the `kvmarm` mailing list.

[02:44](https://www.youtube.com/watch?v=9npebeVFbFw&t=164s) Baseline Architecture: KVM in nVHE Mode

To establish how pKVM achieves host isolation, Quentin reviews the standard architecture of KVM on arm64 when running in non-Virtualization Host Extensions (nVHE) mode. The Arm architecture defines four primary Exception Levels: EL0 for user space, EL1 for operating system kernels, EL2 for hypervisors, and EL3 for low-level firmware and Secure Monitor routines. In nVHE mode, the host Linux kernel runs strictly at EL1 rather than at EL2. Because EL1 software cannot manipulate virtualization controls directly, KVM relies on an isolated execution stub running at EL2 known as the KVM world-switch code.

The world-switch code is compiled directly within the Linux source tree and linked into a dedicated section of the kernel ELF binary. During early system initialization, this code is mapped into EL2 memory and left resident to manage context switches between host and guest execution contexts whenever requested by EL1. Under standard nVHE KVM, when a guest execution context runs, the hardware Stage-2 Memory Management Unit (MMU) translates Guest Physical Addresses (GPA) to Host Physical Addresses (HPA). However, the host kernel executes with no Stage-2 translation enabled, granting it unrestricted access across physical memory—including memory pages assigned to active virtual machines and the private memory of the hypervisor itself.

```mermaid flowchart TD accTitle: Standard KVM nVHE Architecture accDescr: Diagram illustrating privilege levels EL0 through EL2 in standard nVHE mode showing unconstrained host memory access.

subgraph EL0["EL0: User Space"] HostApp["Host Applications"] VMM["Virtual Machine Manager / VMM"] GuestApp["Guest User Space"] end

subgraph EL1["EL1: Operating System Kernel"] HostKernel["Host Linux Kernel (KVM)"] GuestKernel["Guest Kernel"] end

subgraph EL2["EL2: Hypervisor"] WorldSwitch["KVM World-Switch Code"] end

HostApp --> HostKernel VMM --> HostKernel GuestApp --> GuestKernel HostKernel -->|"HVC call"| WorldSwitch WorldSwitch -->|"Stage-2 active"| GuestKernel HostKernel -.->|"Unrestricted Stage-1 direct access"| EL2 HostKernel -.->|"Unrestricted access to all RAM"| GuestKernel ```

- Exception hierarchy: EL0 (user space), EL1 (kernel), EL2 (hypervisor), EL3 (secure firmware). - Execution split: The main Linux kernel runs in EL1; minimal context-switching logic resides at EL2. - Memory privilege vulnerability: In vanilla nVHE, the host kernel operates with Stage-2 disabled, allowing it direct access to hypervisor structures and guest pages.

[05:04](https://www.youtube.com/watch?v=9npebeVFbFw&t=304s) The pKVM Philosophy and Architectural Advantages

Protected KVM subverts this conventional setup by transforming the lightweight EL2 world-switch component into an authoritative, security-enforcing hypervisor. Under pKVM, the EL2 software activates the Stage-2 MMU translation tables for the *host* kernel as well as the guest. By interposing Stage-2 address translation on the host's execution path, the hypervisor establishes deterministic access control over arbitrary physical pages throughout the system. EL2 strips host access permissions from any physical frames allocated to protected guest memory or reserved for the hypervisor's internal bookkeeping.

Quentin emphasizes that retaining the co-located nVHE deployment model delivers profound software lifecycle benefits over traditional, standalone hypervisor platforms. In particular, building EL2 directly into the primary kernel image solves the chronic Android problem of out-of-band updates, guaranteeing that hypervisor binaries deploy atomically alongside the platform kernel through established Android update channels. Furthermore, because both components are compiled from identical source commits, developers are not forced to freeze a rigid, backwards-compatible Application Binary Interface (ABI) between the EL1 host and the EL2 hypervisor: “Since the hypervisor and the kernel are part of the same image and they are by construction updated atomically, which means that we don't have to keep a stable API between the host kernel and the hypervisor.” Finally, running an open-source hypervisor at EL2 ensures complete visibility for audits, security hardening, and community-driven verification.

- Stage-2 protection for the host: EL2 configures host Stage-2 page tables to revoke EL1 access to guest private memory and hypervisor memory. - Updatability: Hypervisor binaries are bundled inside the kernel image, inheriting Android's existing kernel deployment and over-the-air update mechanisms. - ABI flexibility: Eliminates the requirement for a frozen ABI between the host kernel and hypervisor, accelerating feature iteration. - Open auditability: All code executing at the elevated EL2 privilege level remains open source in upstream Linux.

[06:56](https://www.youtube.com/watch?v=9npebeVFbFw&t=416s) Bootstrapping pKVM: Early Boot and Memory Reservation

To trace how pKVM establishes trust in practice, Quentin introduces an illustrated user character to anchor a step-by-step tour through the platform lifecycle, beginning at hardware cold boot. Trust begins with verified boot: the system bootloader verifies cryptographic signatures over the Linux kernel image using industry-standard secure boot standards before execution starts. Per architectural requirements of KVM on arm64, firmware branches into the kernel image while the processor is operating at EL2. Within its first twenty instructions, the kernel detects it is executing at EL2, installs primitive "stub vectors" (placeholder exception handlers that do nothing), and issues an `ERET` instruction to drop execution down to EL1 to execute early kernel initialization.

As Linux initializes its core memory management subsystems at EL1, pKVM must guarantee private memory reserves for the EL2 hypervisor. EL2 requires dedicated backing pages to track its private Stage-1 translation structures and the host Stage-2 page tables. To accomplish this, early boot code invokes the kernel's `memblock` allocator to carve out a dedicated physical memory pool to donate to EL2. The total footprint of this reserved pool scales dynamically with the physical memory density of the SoC.

Because KVM on arm64 cannot be loaded as a runtime kernel module, pKVM initialization completes before user space is spawned. During this initialization phase, the host prepares a temporary Stage-1 page table and allocates per-CPU EL2 stack slots. The host then triggers a hypercall (`HVC`) down to EL2. This invocation displaces the early dummy stub vectors with active pKVM exception handlers, allowing the hypervisor to turn on its Stage-1 MMU immediately and bootstrap its private runtime state.

- Entry level: Bootloader jumps into the kernel image at EL2; early kernel assembly sets placeholder stub vectors and drops to EL1 via `ERET`. - Memory carving: The host uses the `memblock` allocator early in the boot sequence to carve out dedicated physical memory frames for EL2 page tables. - Scaling factor: The hypervisor memory footprint scales proportionally with total system RAM capacity. - Hypercall transition: Host constructs temporary Stage-1 page tables and issues an `HVC` to install pKVM vector handlers and bootstrap hypervisor execution.

[10:21](https://www.youtube.com/watch?v=9npebeVFbFw&t=621s) Host Stage-2 Initialization and Memory Ownership Model

```mermaid flowchart TD accTitle: Host Stage-2 Isolation and Memory Ownership Model accDescr: Hypervisor isolates itself from the host and establishes ownership states for physical pages.

subgraph Boot["Boot & Stage-2 Setup"] A["Hypervisor enables Stage-1"] --> B["Build Stage-2 page table for Host"] B --> C["Unmap hypervisor text, data, and memory pool"] C --> D["Return to Host at EL1<br/>(Stage-2 enabled)"] end

subgraph States["Page Ownership States"] S1["Owned / Exclusive"] S2["Shared (Sharer / Lender)"] S3["Borrowed (Recipient)"] S4["Unmapped / Inaccessible"] end

D -. enforces.-> States ```

During initialization, the hypervisor allocates its internal structures out of the early memory pool and builds the stage-2 page tables for the host. Crucially, it unmaps its own code and data from this host stage-2 mapping—specifically peeling away the hypervisor text section, data section, and early memory pool so that the host can no longer access them. Once the stage-2 page table is activated, execution returns to the host at EL1, which continues booting as if nothing has changed, unaware that vast swathes of memory are now hardware-isolated behind the CPU's stage-2 translation regime. Quentin Perret notes that this isolation “makes our little friend here really happy.”

By mapping memory into its own stage-1 page table and explicitly unmapping it from the host stage-2 page table, the hypervisor effectively claims exclusive ownership over those physical pages. Within Protected KVM (pKVM), the hypervisor assumes strict responsibility for tracking page ownership across the entire platform and enforcing access-control boundaries. pKVM formally tracks several distinct owner types, including the host, the hypervisor itself, protected guest VMs, and external security environments such as Arm TrustZone. From the perspective of any given entity, a page exists in one of four distinct states: 1. **Owned**: The entity has exclusive, complete access to the page. 2. **Shared (Lender)**: The entity owns the page but has shared it with another entity. 3. **Borrowed (Recipient)**: The entity has received shared access to a page owned by someone else. 4. **Inaccessible**: The page is entirely unmapped from that entity's address space.

- The hypervisor isolates itself by stripping its own `.text`, `.data`, and memory pool allocations out of the host's stage-2 page table. - pKVM treats physical page ownership tracking as an explicit hypervisor invariant that governs all memory transitions. - Potential page owners recognized by pKVM include the host OS, the EL2 hypervisor, protected guest VMs, and TrustZone.

[12:36](https://www.youtube.com/watch?v=9npebeVFbFw&t=756s) Tracking Page Ownership via Architectural Software Bits

```mermaid flowchart LR accTitle: Host Stage-2 PTE Encoding accDescr: Layout of invalid stage-2 PTE bits used to encode memory ownership.

subgraph PTE["Stage-2 Page Table Entry (Invalid Entry: Bit 0 = 0)"] direction LR B0["Bit 0<br/>Valid Flag = 0"] B1["Bits 1–63<br/>Ignored by Hardware"] end

subgraph Usage["pKVM Software Metadata"] Owner["Owner ID (Bits 1–63)<br/>Host ID = 0x0"] Bits["Software Bits (4 bits)<br/>Ownership & Sharing State"] end

B0 --> Owner B1 --> Bits ```

To maintain ownership records without incurring heavy memory overheads, pKVM encodes tracking state directly inside the page table entries (PTEs). The Arm64 architecture reserves four software-defined bits within valid PTE descriptors; the hypervisor repurposes these bits across host, guest, and hypervisor page tables to track sharing status and transitions. Furthermore, sharing is strictly limited to peer-to-peer relationships between two distinct entities; complex multi-party sharing among three or more parties is deliberately prohibited to keep the state machine tractable.

Because the host stage-2 page table is strictly identity-mapped, the stage-2 MMU is used exclusively for access control rather than address translation. This identity mapping enables a powerful hardware trick: whenever a page is marked invalid in the host stage-2 page table (clearing bit 0), Arm hardware ignores the remaining bits (bits 1 through 63). pKVM repurposes these unused hardware bits to store the unique owner ID of the entity that currently possesses the page. By deliberate convention, the host’s owner ID is defined as zero (`0`). Consequently, an entry consisting entirely of zeros naturally represents a page owned by the host that is currently invalid/unmapped, perfectly aligning with default memory initialization.

State transitions—such as donations or sharing operations—follow a two-step validation model. The hypervisor first checks strict invariants in the initiator's page table to ensure that it has legitimate authority to initiate the transition, and then updates the page table entries of both the initiator and the recipient. For memory donations, the initiator must possess exclusive access; transitive sharing or donating a page that is actively shared is forbidden. As Perret emphasizes, “before a page can be donated to someone it has to be unshared first to reclaim to get back exclusive ownership.”

- Page ownership tracking is embedded directly into Arm64 page table entries rather than separate, bulky out-of-band metadata trees. - Valid PTEs utilize the 4 architectural software bits to record fine-grained state (such as sharing roles). - Host stage-2 PTEs utilize bits 1–63 of invalid entries (bit 0 = 0) to encode owner IDs, with host ownership assigned to ID `0`. - All memory state transitions (donation, sharing, unsharing) enforce two-phase validation: checking source invariants before applying modifications to both participants.

[15:25](https://www.youtube.com/watch?v=9npebeVFbFw&t=925s) VM Creation and the Dynamic Memory Donation Pattern

```mermaid flowchart TD accTitle: Dynamic Memory Donation during Protected VM Creation accDescr: Flow of memory allocation and hypervisor handle instantiation when creating a pKVM guest.

subgraph Host["Host (EL1)"] H1["1. Allocate memory pages for guest metadata"] H2["2. Issue VM creation Hypercall"] H3["5. Receive opaque Shadow Handle<br/>(Analogous to userspace vmfd)"] end

subgraph Hypervisor["Hypervisor (EL2)"] HY1["3. Convert allocated pages to EL2-private memory<br/>(Host-to-EL2 Donation)"] HY2["4. Allocate internal structures:<br/>- Shadow VM (struct kvm)<br/>- Shadow vCPUs (struct kvm_vcpu)<br/>- Stage-2 Page Table Root"] end

H1 --> H2 H2 --> HY1 HY1 --> HY2 HY2 --> H3 ```

When a user on a pKVM-enabled machine creates a protected guest VM, the host kernel must perform several extra orchestration steps. Under pKVM’s design principle of minimal EL2 footprint, the hypervisor operates with the bare minimum amount of static memory. Whenever EL2 needs memory to manage new virtual machines, it requires the host to allocate pages from EL1 and dynamically donate them to the hypervisor. As Perret explains, “every time we need to do something with the hypervisor one of the first things we have to do is allocate memory we're going to donate to it.”

Upon receiving a guest creation hypercall accompanied by the donated pages, the hypervisor converts those pages into EL2-private memory via a host-to-hypervisor memory donation. It then allocates and initializes its private EL2 virtualization metadata, creating an EL2-side VM structure (historically termed a shadow VM), per-vCPU tracking structures, and the root of the guest's stage-2 page table. The hypervisor retains internal pointers back to the corresponding host data structures and returns an opaque integer handle back to the host. Perret compares this mechanism to userspace virtualization interfaces: “The handle that the hypervisor has allocated is what the host can then use in order to talk to the hypervisor when it talks about that VM so it's comparable to the to the `anon_inode:kvm-vm` file descriptor (`vmfd`) that user space has when you create a VM with an `ioctl`.”

Perret also mentions a terminological shift occurring in the upstream patch reviews. While earlier iterations of the patch series described these isolated EL2 structures as "shadow" objects (such as `kvm_shadow_vm`), the development team began phasing out the "shadow" naming convention to avoid confusion. Perret notes that the upstream series was actively evolving even on the day of the presentation: “I think we're in the process of renaming those data structures to to not be called Shadows anymore so I think this might even be sort of out of date as of this morning because I think Will has posted a patch series.”

- The hypervisor runs in a tightly constrained footprint; all EL2 memory scaling requires dynamic, explicit host-to-hypervisor page donations. - Guest creation requires the host to supply memory pages, which EL2 unmaps from the host and claims as private storage for hypervisor data structures. - The returned handle acts as a secure capability handle for EL1-to-EL2 hypercalls, mirroring the role of a KVM `vmfd` in userspace.

[18:20](https://www.youtube.com/watch?v=9npebeVFbFw&t=1100s) Building an OS Environment in EL2 and vCPU Scheduling

Running hypervisor logic securely at EL2 means executing code in an austere, isolated execution level. Standard Linux kernel infrastructure cannot simply be linked into EL2. To simplify development and preserve sanity, the team gradually imported adapted kernel primitives into EL2 so that Linux developers working in the hypervisor feel right at home. However, EL2 has strict environmental constraints: because the hypervisor is strictly non-preemptible, blocking synchronization primitives like mutexes are prohibited, leaving spinlocks as the sole locking mechanism.

Over time, the developers implemented a rich suite of EL2 runtime utilities: - Custom spinlocks with debugging features to verify lock assertions and tracking. - A minimalist buddy-style page allocator tailored to strict static memory boundaries. - A specialized EL2 virtual mapping engine (`vmap`) alongside an ultra-compact `struct hyp_page` abstraction. - Tracing infrastructure capable of routing hypervisor-generated trace events back out to the host's Linux tracing subsystem (ftrace).

Once a guest and its virtual CPUs are fully instantiated, the host schedules and runs them. Upstream KVM relies on `vcpu_load()` and `vcpu_put()` to bind a virtual CPU to a physical CPU core and optimize the entry-exit run loop. pKVM mirrors this lifecycle across hypercalls, introducing dedicated `vcpu_load` and `vcpu_put` EL2 entry points. However, because the untrusted host drives the execution, the hypervisor cannot blindly accept a load request; whenever the host issues a `vcpu_load` hypercall, EL2 must perform rigorous internal sanity and security validations before allowing guest code execution.

- EL2 execution is entirely non-preemptible, restricting synchronization strictly to spinlocks rather than sleepable locks. - Core kernel abstractions—such as `vmap`, `struct hyp_page`, lockdep-style assertions, and ftrace hooks—were ported directly into the EL2 hypervisor context. - Scheduling a protected vCPU leverages hypercall-driven `vcpu_load` and `vcpu_put` routines that enforce rigorous security sanity checks before executing guest contexts.

[20:30](https://www.youtube.com/watch?v=9npebeVFbFw&t=1230s) vCPU Lifecycle: Load, Put, and the Sync/Flush Paradigm

Before pKVM allows a vCPU to be loaded, the hypervisor enforces strict verification checks at EL2. It must ensure that the target vCPU is not already loaded elsewhere on another core, and conversely, that the current physical CPU does not already have a vCPU loaded onto it. Once a vCPU is successfully loaded, subsequent operations depend on that established state; as Quentin Perret emphasizes, “subsequent hypercalls such as vcpu run will require that the vcpu has been loaded before and this is this will be strong hard requirement.”

When releasing the reference via a `vcpu_put` hypercall, the hypervisor performs what is known as syncing the shadow vCPU state back to the host (for non-protected VMs), drops the reference, and clears the per-CPU tracking structures maintained at EL2. Quentin clarifies the terminology of "sync" and "flush," which have historical roots in KVM/arm64 but can cause confusion: - **Sync**: Moving state from the EL2 hypervisor context back into the host's EL1 copy. This routinely occurs after running a vCPU so the host kernel can inspect fault info or handle virtual exits. - **Flush**: Moving state the other way around—from the EL1 host structures into the EL2 hypervisor structures before entering the guest.

```mermaid flowchart LR accTitle: KVM arm64 Sync and Flush Cycle accDescr: Diagram illustrating the flow of state between Host EL1 and Hypervisor EL2 during flush and sync operations. subgraph Host["Host (EL1)"] HState["Host vCPU State"] end subgraph Hyp["Hypervisor (EL2)"] Shadow["EL2 Shadow vCPU"] end HState -->|"Flush (cherry-picked trusted state)"| Shadow Shadow -->|"Sync (exit info & registers)"| HState ```

[21:47](https://www.youtube.com/watch?v=9npebeVFbFw&t=1307s) Executing vCPUs and Handling Exits

When it is time to execute the virtual processor, the `vcpu_run` hypercall in pKVM requires essentially no parameters because EL2 expects the vCPU to already be bound to the physical CPU; any arguments supplied by the host are simply ignored. During the run transition, the hypervisor flushes only a carefully cherry-picked, minimal subset of host-provided vCPU state that can be trusted without compromising security, then switches to the guest using the protected EL2 vCPU state before entering execution.

Upon a guest exit, the flow reverses: the hypervisor copies necessary exit metadata from the EL2 shadow state back to the host. A small set of exits can be handled entirely within EL2 without waking the host kernel—such as lazily switching Floating Point (FP) register state between host and guest or minimal vGIC handling. However, these are exceptions rather than the rule; the vast majority of exits are punted to the host. Because the host maintains its own `kvm` and `vcpu` structures populated with minimal exit context, standard KVM exit-handling code runs largely unmodified.

[23:23](https://www.youtube.com/watch?v=9npebeVFbFw&t=1403s) Memory Abort Handling and Stage-2 Faults

A major departure from standard KVM occurs during memory aborts (data or instruction aborts). When a guest encounters an unmapped page, the EL2 hypervisor copies the Exception Syndrome Register (ESR_EL2) and Faulting Intermediate Physical Address (IPA/GPA) into the host’s vCPU structure, returning to EL1 with a request to handle the fault. The host locates the corresponding `memslot` and translates the GPA to a Host Virtual Address (HVA). In pKVM's implementation, rather than performing standard get-user-pages (`gup`) and mapping the page immediately, KVM takes a long-term pin on the page backing the HVA:

> “The reason we take a long-term pin is to prevent swap and page migration because we are about to donate that page to the guest and lose access to it so we don't want KSM or whatever to mess with it.”

Following the pin, the host tops up its per-vCPU memory cache (`kvm_mmu_memory_cache`) and issues a `pkvm_guest_map` hypercall. EL2 then replenishes its own internal memory cache from the host-supplied pages, enforcing a strict host-to-hypervisor memory donation for every single cache page to preserve trust boundaries. Once EL2 holds sufficient memory, it constructs the guest's stage-2 page tables. For protected VMs, the memory is completely donated to the guest and entirely unmapped from the host's stage-2 page table; for standard, unprotected VMs, the page is shared, retaining its mapping in host stage-2. Finally, control returns to the host to re-enter `vcpu_run`.

```mermaid flowchart TD accTitle: Protected Stage-2 Memory Abort Resolution accDescr: Step-by-step sequence of handling a stage-2 data abort from a protected guest to EL2 and Host EL1. subgraph Fault["1. Guest Abort"] A["Guest Stage-2 Abort"] --> B["EL2 saves ESR & GPA to Host vCPU"] end subgraph HostAction["2. Host EL1 Resolution"] B --> C["Host converts GPA to HVA"] C --> D["Take long-term page pin (block swap/migration)"] D --> E["Host fills memcache & calls pkvm_guest_map"] end subgraph HypAction["3. Hypervisor EL2 Mapping"] E --> F["EL2 donates host cache pages to Hyp"] F --> G["Donate page to Guest & unmap from Host stage-2"] G --> H["Resume vcpu_run"] end ```

[25:38](https://www.youtube.com/watch?v=9npebeVFbFw&t=1538s) MMIO Handling, Guest Sharing, and Cold Booting

Memory-mapped I/O (MMIO) introduces unique architectural hurdles because EL2 has no concept of KVM `memslots`, and for confidentiality reasons, guest general-purpose registers cannot be exposed to the host upon an exit. To resolve this, pKVM exposes dedicated hypercalls directly to the guest kernel, allowing it to declare explicit MMIO ranges in its GPA space where it permits host emulation. When an abort occurs in an authorized range, EL2 mediates access, exposing only the specific transfer register (such as `x0`) transparently to the host.

A companion hypercall interface enables protected guests to share memory pages back with the host for paravirtualized I/O queues (e.g., virtio buffers). Because guest memory is lazily populated on demand, an edge case occurs when a guest attempts to share a GPA that has not yet been backed by physical memory: - EL2 deliberately fudges the ESR syndrome before returning to EL1, spoofing a data abort. - This tricks the host into donating the physical page via standard fault resolution. - Upon re-entering the guest, EL2 replays the original share hypercall instruction (`HVC`/`SMC`).

For loading guest firmware and payloads, pKVM relies on the early bootchain. During platform boot, the Android Bootloader loads a trusted guest bootloader image into a reserved memory region specified in the host Device Tree (DT). When EL2 initializes and unmaps its own private memory from the host, it simultaneously unmaps this guest bootloader reservation. Later, when the Virtual Machine Manager (VMM) sets up a protected guest, it designates the target GPA base for the bootloader. On the guest's initial boot cycle, EL2 forces the vCPU program counter directly to that base, deliberately inducing page faults; as the host donates pages to back those addresses, EL2 populates them with the trusted guest bootloader code, which verifies and measures the final guest kernel image before execution.

[28:47](https://www.youtube.com/watch?v=9npebeVFbFw&t=1727s) Lazy Host Stage-2 Faults and Security Violations

Protected KVM enforces stage-2 translations not only on guests, but also on the host itself. Like guest mappings, the host's stage-2 translation table is constructed lazily. Whenever a stage-2 fault occurs at EL2 due to host access, EL2 walks the host stage-2 page tables to assess ownership:

1. **Host-owned page**: If the page table entry (PTE) is marked invalid, EL2 inspects software bits 1 to 63. If the encoded owner ID matches the host, EL2 installs a valid stage-2 mapping and resumes execution. 2. **Race condition**: If the PTE is already valid, another host CPU resolved the mapping concurrently; EL2 returns to host execution immediately. 3. **Host violation**: If the PTE is invalid and the software ID belongs to a protected guest or the hypervisor, the host has attempted an unauthorized access to private memory: “and the ID we find in the remaining bits is not the one of the host then we have a problem it means we've got the host accessing private memory and this is where the fun begins.”

When a host stage-2 access violation occurs, EL2 re-injects the exception into the host kernel at EL1. If the fault originated from EL0, a host user-space process—typically the VMM retaining an obsolete virtual address mapping to a donated guest page—attempted the read or write. EL2 re-injects the fault while setting an auxiliary flag bit in the ESR so the host kernel can distinguish this violation from routine demand paging; the host kernel identifies that user space touched illicit memory and terminates the offending process. Conversely, if the violation originated directly from the EL1 host kernel, the situation is far more critical.

[31:16](https://www.youtube.com/watch?v=9npebeVFbFw&t=1876s) Host Fault Handling and Core MM Challenges

Quentin Perret explains the tricky problem of dealing with host-side faults when the host tries to touch memory that it has donated or shared. If the host attempts an illegal access to protected guest memory, the hypervisor can intercept the exception, modify (or "repaint") the Exception Syndrome Register (ESR) so it looks like a same-level fault, and re-enter the kernel with the attitude of: "there you go, you've caused an exception yourself to enter the exception handler, do deal with it." However, while there are situations where the Linux kernel can gracefully handle a same-level fault, those cases are limited.

For instance, if a compromised or malicious Virtual Machine Manager (VMM) in user space executes a system call and passes pointers to protected guest memory as parameters, the kernel accesses that memory using routines like `copy_to_user` or `copy_from_user`. Under those circumstances, the kernel's fault fixup mechanisms kick in, the same-level fault is handled cleanly, and the kernel simply fails the syscall with an error code (such as `-EFAULT`).

The scenario falls apart when an external process inspects that same memory. Quentin provides an example using `strace`: if an `strace` process tries to examine the arguments of a malicious VMM's system call, it does so using the `process_vm_readv` syscall. That syscall invokes `get_user_pages_remote()` and proceeds to read the target pages through the kernel's linear mapping (direct map). When the hypervisor traps this access and refuses it, the kernel has no fixup routine for an unexpected fault inside the linear map, leaving it with no option but to crash or panic the entire machine. As Quentin summarizes:

> “This is in my opinion the biggest remaining problem with the host side implementation of pKVM. I think the hypervisor is now getting pretty solid, but there are still work that needs to be done on that front before we can we can land this upstream.”

- **Handled cleanly:** `copy_from_user()` / `copy_to_user()` access faults fail the immediate syscall. - **Fatal crash:** Linear map accesses initiated by `process_vm_readv()` via `get_user_pages_remote()` trigger unhandled kernel panics.

---

[32:56](https://www.youtube.com/watch?v=9npebeVFbFw&t=1976s) Proposed Upstream Solutions: guest_memfd/private-fd, secretmem, and Guest Killing

To resolve this host MM problem without taking down the entire machine, Quentin outlines several potential avenues being explored in the upstream Linux community:

1. **Extending `private-fd` / `guest_memfd`:** Originally proposed by Intel TDX developers, the private file descriptor mechanism offers several appealing properties. If implemented correctly, it prevents swapping and page migration on protected pages, stops kernel side-channel/linear map access, and provides a clean API to build hypervisor-assisted page migration in the future. However, pKVM strictly requires support for "in-place conversions"—allowing non-destructive memory sharing, unsharing, and page donation without discarding contents. 2. **Extending `secretmem`:** The pKVM team is evaluating `secretmem` (secret memory) as another possibility. In pKVM, having guest memory mapped into the VMM user space is not inherently problematic because the hypervisor can handle user faults cleanly; the critical risk is when the host kernel attempts to touch it. Extending `secretmem` with features borrowed from the private FD proposal could eliminate direct map access while keeping VMM mappings viable. 3. **Hypervisor Guest Termination:** A third, far less appealing workaround is to have the hypervisor simply terminate the guest whenever the host kernel faults on its memory. Under this design, the hypervisor would kill the guest, poison (zero out) all its memory, return ownership to the host, and allow the host kernel's read or write to proceed with poisoned data rather than panicking. While this preserves existing long-term GUP (Get User Pages) pins without requiring invasive changes to Linux core MM, Quentin warns that it introduces heavy complexity at EL2, unjustly punishes the guest for host behavior, and notifies KVM of guest death purely asynchronously—only surfacing the next time a `KVM_RUN` hypercall is issued, making debugging nearly impossible.

---

[35:14](https://www.youtube.com/watch?v=9npebeVFbFw&t=2114s) Guest Teardown and Incremental Page Reclaim

When a protected guest finishes running, the host initiates teardown by issuing a hypercall. The hypervisor must verify that no guest vCPUs are currently running or loaded before tearing down the resources. All memory pages originally donated to the guest must be returned to the host memory management subsystem, but they must first be poisoned (cleared) so that leftover guest secrets are not exposed to the host OS.

Because the EL2 hypervisor runs in a strictly non-preemptible environment, clearing gigabytes of guest memory within a single continuous hypercall would stall EL2 execution for seconds or minutes—a latency spike that cannot be tolerated. To bypass this restriction, pKVM uses a staged, incremental reclaim protocol.

```mermaid flowchart LR accTitle: pKVM Guest Teardown and Incremental Page Reclaim accDescr: The step-by-step memory transition from guest donation to incremental page reclaiming by the host via EL2 hypercalls.

subgraph Guest Teardown A["Host Issues Teardown Hypercall"] --> B["EL2 Stops Guest & Marks Pages Pending"] B --> C["Host Page: Pending Reclaim"] end

subgraph Incremental Reclaim Loop C --> D["Host Issues Reclaim Hypercall (Single Page)"] D --> E["EL2 Maps via Fixmap & Clears Page"] E --> F["Page Restored to Host Ownership"] F --> G{"More Pages Pending?"} G -- "Yes (Reschedule in Host)" --> D G -- "No" --> H["Teardown Complete"] end ```

When teardown begins, the guest notionally disappears, and its memory pages transition into a state labeled `HOST_PAGE_PENDING_RECLAIM`. At this stage, the memory contents remain untouched. The host kernel then executes a loop of individual hypercalls to reclaim the pages one by one. During each call, the EL2 hypervisor maps the single page using a fixed map (`fixmap`), clears it to wipe guest secrets, and transitions ownership back to the host. Because the loop runs in host kernel context at EL1, the host can freely reschedule between hypercalls, avoiding long non-preemptible stalls at EL2.

---

[37:04](https://www.youtube.com/watch?v=9npebeVFbFw&t=2224s) Future Work and Current Limitations

Quentin wraps up the technical deep dive by highlighting several major features and architectural components that could not fit into the presentation:

- **Secure World interactions:** Mediating communications between non-secure EL2/EL1 and TrustZone / Secure EL3 in the Arm architecture. - **DMA protection and SMMU:** Implementing IOMMU/SMMU drivers at EL2 to block unauthorized device DMA against protected pages. - **Hypervisor infrastructure:** Interrupt controllers (GIC), timers, power management (PSCI), and hardware true random number generators (TRNG).

He also lists notable gaps in the current patch series that are being actively developed before upstreaming: - **Missing baseline KVM features:** Basic virtualization capabilities—such as dirty page logging and read-only memory slots (`memslots`)—are not yet supported even for non-protected guests. - **Large pages:** Huge pages (2MB / 1GB) are not yet implemented for protected guests. - **System features:** Lack of `kexec` support and direct peripheral device assignment.

Quentin concludes the talk and opens the floor for questions, drawing applause from the audience.

---

[38:33](https://www.youtube.com/watch?v=9npebeVFbFw&t=2313s) Q&A: SMMU Support, Host Stage-2 Overhead, and Asynchronous Reclaim

The session turns to questions from virtual and in-person attendees:

**SMMU Support and Ownership Tracking** An online attendee asks about the timeline for SMMU (System MMU) integration in pKVM and how page ownership will be tracked across the IOMMU. Quentin responds that work is actively underway (mentioning efforts involving Linaro) to land SMMU support upstream. Page ownership tracking follows the same logic as the host CPU stage-2 tables: whenever the EL2 hypervisor updates host CPU permissions or mappings, it must walk and update the corresponding SMMU stage-2 translation tables to prevent rogue DMA access, depending in part on whether SMMU page faults can be fielded directly at EL2.

**Host Stage-2 Translation Overhead** Asked whether running the host operating system under stage-2 translation incurs noticeable performance penalties, Quentin explains that the theoretical overhead comes from increased Translation Lookaside Buffer (TLB) pressure and the cost of stage-2 TLB misses. However, in practice, the performance impact is nearly zero:

> “The host owns the vast majority of memory, and all the host mappings are identity mapped, which means we're in a position where we can very easily use really, really large block mappings to cover everything... which makes the overhead of the stage-2 practically impossible to actually measure.”

**Teardown Latency and Asynchronous Cleaning** An attendee asks about the overhead of reclaiming and zeroing pages one-by-one during teardown and whether Google has considered running this asynchronously, noting that a similar approach is being adopted for IBM s390 Secure Execution. Quentin acknowledges the s390 talk, agreeing that offloading the cleanup:

> “I think the idea of just forking that and having a separate process do the cleanup for us to hide the latency to...”

He notes that in mobile environments where VMs typically use around 1 GB of memory, synchronous incremental reclaim is not a bottleneck. However, if pKVM scales to server environments with terabytes of RAM, adopting an asynchronous background cleanup process will likely become necessary.

[41:37](https://www.youtube.com/watch?v=9npebeVFbFw&t=2497s) QEMU Memory Dumps and In-Place Page Conversion

An audience member opens the Q&A by clarifying host-side debugging behavior: if a user opens a QEMU console on the host and attempts to dump physical memory that belongs to a secure guest, QEMU crashes immediately because it hits an unmapped or restricted page, which Quentin Perret confirms with a simple "yes." Another attendee then follows up on an earlier observation regarding guest private memory, asking Quentin to explain why pKVM specifically requires in-place memory conversion rather than purely allocating fresh, out-of-band private pages.

Quentin explains that pKVM is designed to modernize and replace long-standing phone security patterns that have existed for over a decade. Android devices have executed workloads isolated from the host kernel for roughly fifteen years using Arm TrustZone, bringing along significant architectural history and technical baggage. Many modern workloads transitioning out of TrustZone into virtual machines involve massive data buffers—most notably digital rights management (DRM) and 4K media playback. As Quentin notes:

> “If you have like 4K video frames you're not gonna have megabytes... potentially it can be hundreds of megabytes of memory that are going to be passed around between the host kernel and whatever is going to be handling that into that that sort of secure Island which is TrustZone.”

To move these legacy TrustZone workloads into virtual machines efficiently without crippling performance, the hypervisor cannot afford expensive buffer copies. A zero-copy memory transfer mechanism is required between the host and the protected VM, making in-place page conversion an absolute necessity.

[43:40](https://www.youtube.com/watch?v=9npebeVFbFw&t=2620s) Proposed Upstream Mechanism for Guest Private Memory

An audience member steps up to pitch an upstream design proposal, stating they are "like 95% sure" it can reconcile pKVM's need for in-place conversion with the ongoing guest private memory work in Linux. The proposal leverages a shim around `memfd` where file operations (`fops`) bury the real operations inside an outer layer that omits the standard `mmap` wiring. Under this scheme, KVM's user-space VMM API would be extended beyond simply marking memory as shared or private by introducing a third flavor: user-space mappable memory.

```mermaid flowchart TD accTitle: In-Place Conversion Flow accDescr: Workflow showing host user space filling memory and converting it in place via KVM. subgraph HostSpace["Host User Space"] A["Allocate Memory via memfd shim"] --> B["Populate / Fill Data Buffer"] B --> C["Issue In-Place Convert ioctl"] end subgraph Hypervisor["KVM / pKVM Hypervisor"] C --> D{"Hypervisor Allows In-Place?"} D -- "Yes (pKVM)" --> E["Map into Guest & Zero Memory"] D -- "No (TDX / SEV-SNP)" --> F["Reject Conversion"] end ```

This user-space mappable state is permitted only while the page is not mapped into the guest. KVM can then manage the mapping internally, avoiding any `memslot` updates and circumventing Sleepable Read-Copy Update (SRCU) synchronization bottlenecks. The host user space fills the memory buffers while mapped, requests an in-place conversion, and—if the underlying hypervisor allows it—the memory is zeroed or transitioned directly into the guest. While hardware-isolated technologies like Intel TDX and AMD SEV-SNP disallow this style of in-place conversion due to their hardware tracking constraints, pKVM permits it. Quentin welcomes the idea enthusiastically, noting he has seen patches floating on the mailing lists and is eager to explore them.

[45:03](https://www.youtube.com/watch?v=9npebeVFbFw&t=2703s) Page Table Ownership and Fault Handling

A question is raised regarding the mechanics of pKVM's stage-2 page tables: since ownership IDs are stored exclusively inside invalid page table entries (PTEs), could a fault handler ever need to know the owner of a valid, currently mapped PTE? Quentin clarifies that if a page is validly mapped in the host's stage-2 page table, the host has legitimate access to it and will not trigger a stage-2 translation fault.

The questioner presses further, asking what occurs if a guest attempts to touch a page that is currently mapped into the host. Quentin clarifies that ownership ID tracking inside invalid PTEs is applied specifically to the host's stage-2 page tables. When a guest triggers an instruction or data abort on an invalid PTE, the hypervisor does not arbitrarily pull an unassigned physical page to resolve it. Instead, guest memory mappings require an explicit host donation directed at a specific intermediate physical address (IPA):

> “Every time we we hit an invalid PTE into into the guest we're not going to map some just a memory random pages into the guest we'll have to have the host tell us this is the page that you can map into the guest at that IPA right now.”

The hypervisor then performs strict access-control checks to ensure the host actually owns the page before transferring ownership and mapping it into the guest's IPA space. Crucially, memory sharing within pKVM is constrained strictly between two defined entities at any given moment.

[46:51](https://www.youtube.com/watch?v=9npebeVFbFw&t=2811s) Guest Attestation and Firmware Boot Flow

An attendee asks how guest payloads are attested. While the host kernel on Android is authenticated via the standard device bootloader verification chain, guest boot firmware requires an entirely independent chain of trust. Quentin explains that the host is intentionally blind to the guest's bootloader. Instead, the pKVM hypervisor directly copies a trusted, cryptographically signed bootloader image into the guest's memory and forces the guest vCPU to execute that bootloader first.

```mermaid flowchart TD accTitle: pKVM Guest Attestation Flow accDescr: Sequence showing device bootloader reserving firmware down to guest secret derivation. subgraph EarlyBoot["Early Device Boot"] A["Device Bootloader writes Guest FW to Carveout"] --> B["Hypervisor unmaps Carveout from Host"] end subgraph GuestInit["Guest Launch"] B --> C["Hypervisor copies FW into Guest Memory"] C --> D["Guest forces Execution of Trusted Bootloader"] D --> E["Bootloader loads Payload via virtio / RAM"] E --> F["Bootloader measures Payload & derives Identity Keys"] end ```

In the initial implementation, this trusted guest bootloader is based on U-Boot, though the team plans to rewrite it in a memory-safe, higher-assurance language. Once executing, the trusted bootloader receives the actual guest payload (for example, through `virtio` or direct memory inspection) and measures its contents. Because the trusted bootloader receives access to hardware-derived secrets that are completely hidden from the host kernel, it generates an authenticated, portable identity for the guest. The guest can subsequently present this identity to remote parties to prove that it booted an untampered payload inside an authentic pKVM enclave.

[48:15](https://www.youtube.com/watch?v=9npebeVFbFw&t=2895s) Hardware Root of Trust and Device Unlock / Rooting

The discussion concludes with an inquiry into the root of trust underpinning the guest bootloader: how does the hypervisor verify that the bootloader image it injects has not been tampered with if a device has been modified or rooted? Quentin explains that during early system boot, the primary device bootloader places the trusted guest firmware image into a dedicated physical memory carveout. The pKVM hypervisor immediately unmaps and isolates this carveout from the host kernel, ensuring the host OS cannot manipulate the binary.

When asked how DRM use cases remain secure if an end user unlocks the bootloader or roots their smartphone, Quentin explains the broader hardware security model used across Android:

> “If you root the device the the keys that the bootloader can use to sign whatever payload is done are removed so we just wipe the keys when you [unlock] the device.”

By intentionally erasing device-unique hardware attestation keys upon unlocking the bootloader, rooted devices lose the ability to forge valid attestation signatures. Furthermore, the hypervisor refuses to supply trusted bootloader secrets or signing keys to non-protected virtual machines. Without these burnt-in hardware credentials, a modified guest or rooted environment cannot masquerade as an authorized DRM endpoint. Quentin closes the session to applause.

## Notable quotes > [38:33](https://www.youtube.com/watch?v=9npebeVFbFw&t=2313s) The host owns the vast majority of memory, and all the host mappings are identity mapped, which means we're in a position where we can very easily use really, really large block mappings to cover everything... which makes the overhead of the stage-2 practically impossible to actually measure. — Quentin Perret

> [23:23](https://www.youtube.com/watch?v=9npebeVFbFw&t=1403s) The reason we take a long-term pin is to prevent swap and page migration because we are about to donate that page to the guest and lose access to it so we don't want KSM or whatever to mess with it. — Quentin Perret

## Mentioned Quentin Perret, Google, Protected KVM (pKVM), KVM, arm64, Linux Foundation, Android, Intel TDX, AMD SEV, AMD SEV-SNP, Arm CC-A, Arm TrustZone, Linaro, IBM s390, QEMU, U-Boot

## Video description Protected KVM on Arm64: A Technical Deep Dive - Quentin Perret, Google

Protected KVM (a.k.a. pKVM) is an extension of KVM/arm64 providing a Confidential Computing solution for Arm v8.0+ CPUs. pKVM targets SoCs that don't feature Confidential Computing hardware extensions, which makes it applicable to a wide spectrum of domain-spaces, including mobile (Android). pKVM extends the existing KVM/arm64 nVHE hypervisor with the ability to manage the CPU's stage-2 MMU, hence allowing the enforcement of access-control restrictions on host accesses to guest memory. In this talk, we will do a technical deep dive on pKVM, describe its architecture and implementation [1], and discuss opportunities for sharing core infrastructure (e.g. memory management) with other Confidential Computing solutions such as Intel TDX, AMD SEV or Arm CC-A. [1] https://lore.kernel.org/kvmarm/20220519134204.5379-1-will@kernel.org/

[Source](https://www.youtube.com/watch?v=9npebeVFbFw)