Devlore: Extending Arm CCA to Integrated Devices A Journey Beyond Memory to Interrupt Isolation

TL;DR

DevLore addresses the limitation of Arm CCA that forbids realm VMs from directly accessing integrated devices, which is necessary for on-device inference, authentication, and accelerators. It introduces a two-GPT memory-isolation design to allow devices to access realm memory while preserving confidentiality and integrity, and a novel interrupt isolation framework that delegates management to the hypervisor but verifies all actions via the Realm Management Monitor. The approach supports a diverse set of devices with configurable protection (MMIO, DMA, and interrupts) and requires only modest firmware/hypervisor changes (~5K LoC). Evaluation on Arm FVP with five devices demonstrates compatibility and meaningful runtime overheads under stress, highlighting a trade-off between security and performance that is acceptable for confidential computing in practice. Overall, DevLore extends Arm CCA to integrate peripherals securely, preserving compatibility and performance while broadening the applicability of confidential computing to real-world device-rich platforms.

Abstract

Arm Confidential Computing Architecture (CCA) executes sensitive computation in an abstraction called realm VMs and protects it from the hypervisor, host OS, and other co-resident VMs. However, CCA does not allow integrated devices on the platform to access realm VMs and doing so requires intrusive changes to software and is simply not possible to achieve securely for some devices. In this paper, we present Devlore which allows realm VMs to directly access integrated peripherals. Devlore memory isolation re-purposes CCA hardware primitives (granule protection and stage-two page tables), while our interrupt isolation adapts a delegate-but-check strategy. Our choice of offloading interrupt management to the hypervisor but adding correctness checks in the trusted software allows Devlore to preserve compatibility and performance. We evaluate Devlore on Arm FVP to demonstrate 5 diverse peripherals attached to realm VMs.

Figures (8)

• Figure 1: (a) Types of devices and CCA's GPC and PAS filters for memory protection (b) Arm's interrupt architecture (with and without CCA) where the hypervisor maintains the GIC configuration, creates and maintains vGIC configuration for VMs, and programs vGIC system registers. The GIC fires physical interrupts and virtual interrupts programmed in the vGIC system registers.
• Figure 2: DevLore Design. (a) Isolation of devices attached to realm VMs (b) DevLore's interrupt isolation flow where a realm VM has turned on interrupt isolation for interrupt 44. 1. Interrupt 44 traps to monitor 2,3. monitor writes 44 to RMM and Hypervisor data structures. 4. monitor notifies the hypervisor using an interrupt. 5. monitor returns to the interrupted app. 6. Hypervisor sends virtual interrupt configuration to the RMM. 7. RMM checks the virtual interrupt configuration 8. and programs the vGIC system registers 9. and enters the Realm VM 10. On VM entry the GIC fires interrupt 44 to the VM.
• Figure 3: DevLore's two GPTs. t0: DevLore creates and populates 2 GPTs at platform boot. t1: DevLore updates GPT$_{d}$ when the first device is attached to the VM. t2: DevLore does not need to update the GPTs on subsequent device attach. t3: When the devices are detached, DevLore marks all realm VM memory back to Realm world.
• Figure 4: Device interrupts 1-9 are registered by a realm VM for DevLore's secure interrupt delivery. For simplicity, interrupt number = interrupt priority and vGIC window size $n$=3. (a) Counting: Detects if hypervisor injects too few interrupts but not which interrupts are injected. (b) Tie virt. to phys.: Detects if hypervisor injects fake interrupts but not if the interrupts are reordered. (c) Ordering: Detects if hypervisor reordered interrupts but does not consider priority. (d) Priority: Detects if hypervisor injects lower priority interrupts when higher priority interrupts are pending. Scheduling: if the hypervisor maliciously stalls the realm VM, the interrupt injection behavior is equivalent to a possible benign scheduling case.
• Figure 5: DevLore's Hypervisor GIC config. flow. 1. Hypervisor tries to configure GIC 2. This operation tries to access root memory so the hardware raises a Granule Protection Fault (GPF) 3. that the hypervisor traps on. In the trap handler, reconstructs the faulting instruction and invokes the monitor to perform the GIC config. operation 4. The monitor checks the hypervisor's request and then performs the GIC config. operation.