- The paper introduces the first VMI system for Arm CCA Realm VMs by moving introspection into the trusted Realm Management Monitor, enabling process-list and syscall-table checks without modifying the guest.
- RealmEye detects Diamorphine process hiding and syscall-table hooks with no observed false positives, while key operations remain predictable within roughly 3% of estimated costs on Arm FVP simulation.
- The system counters Hypervisor collusion and symbol tampering through autonomous scan scheduling and VBAR-based symbol discovery, but hardware performance, attested key exchange, and Stage-2 TLB coherence remain open challenges.
Motivation and problem statement
RealmEye addresses a gap in confidential computing security: the absence of any virtual machine introspection (VMI) capability for Realm VMs under Arm Confidential Compute Architecture (CCA). CVM platforms such as SEV-SNP, Intel TDX, and Arm CCA exclude the Hypervisor from the VM's trusted computing base (TCB) and enforce memory isolation in hardware, which simultaneously protects the VM from the cloud provider and prevents the VM owner from performing out-of-VM forensics against kernel rootkits planted via network or supply-chain attacks. Traditional VMI presupposes a trusted Hypervisor as both executor and privileged accessor of VM state; on CCA the Granule Protection Table (GPT) blocks the Hypervisor from Realm memory at every access, so this entire line of work is structurally inapplicable.
The state of the art for CVM introspection, 00SEVen [2406.xxxxx], restores VMI on AMD SEV-SNP by hosting an agent at VMPL0 inside the guest. This design depends on SEV-SNP's intra-VM privilege layering (VMPLs, RMPADJUST, SVSM), which has no counterpart in CCA: a Realm offers no hardware-isolated tier inside the VM in which such an agent could reside. Realm VMs therefore had no introspection solution at all prior to this work.
Design
The central design decision is placement: all introspection logic runs inside the Realm Management Monitor (RMM) at R-EL2. The RMM is already part of the Realm TCB, has hardware privilege over Realm memory and register state, and is unreachable by any software inside the Realm VM. This yields monitor–target separation enforced by CCA hardware rather than by software layering within a shared VM instance, and requires no modification of the monitored Realm.
Three CCA-specific challenges shape the implementation:
- No memory-introspection interface in the RMM specification. The RMM exposes neither a Realm-virtual-address read primitive nor an IPA translation helper. RealmEye implements a full read path manually: it reads TTBR1_EL1, VBAR_EL1, and SP_EL0 directly from the REC, performs a complete ARM64 four-level Stage-1 page-table walk (including block descriptors at levels 1–2 for 2 MB huge pages), translates IPA to PA via realm_ipa_to_pa, and transiently maps the target granule with buffer_granule_map.
- REC-lock concurrency conflict. A new SMC call for VMI would deadlock against the granule lock held by the in-flight RMI_REC_ENTER; KVM also cannot raise a new RMI call from within Realm-exit handling. RealmEye instead embeds the trigger in bit 63 of rec_run.enter flags, inspected by smc_rec_enter at entry. Because the scan completes before the Realm VM resumes, consistent snapshots are obtained by construction without separate suspension machinery.
- Stage-2 TLB coherence. Page-level trapping (clearing write bits in Stage-2 entries) is ineffective while stale TLB entries persist, and the Hypervisor cannot broadcast invalidations for Realm Stage-2 mappings. The paper identifies this challenge but defers its concrete resolution to interaction with existing RMM synchronization primitives; it is the least developed of the three mechanisms.
Two further mechanisms respond to threats that the stronger CVM threat model introduces. Against Hypervisor–rootkit collusion—the Hypervisor signaling scan timings so a rootkit can restore benign state—a periodic mode lets the RMM choose scan intervals autonomously, making every RMI_REC_ENTER indistinguishable to the Host. Against symbol-input tampering, the system resolves sys_call_table autonomously: it derives _stext from the CPU-maintained VBAR_EL1 plus the fixed compile-time offset 0x800, then scans a bounded range for dense runs of code-segment pointers characteristic of the syscall table, accepting no external input. Communication is closed end-to-end: results are AES-128 encrypted inside the RMM before entering rec_run.exit (shared memory readable by the Hypervisor), and the paper specifies binding session keys to CCA attestation via attested TLS, following established RA-TLS designs.
Finally, a new CCA driver backend added to LibVMI maps vmi_read_pa, vmi_read_va, vmi_get_vcpureg, vmi_pause_vm, and vmi_set_mem_event onto the same channel, allowing DRAKVUF and Volatility-style tooling to operate unchanged. The authors state this is the first LibVMI driver for Arm CCA.
Security analysis
The paper argues five goals are met. Hypervisor independence holds because the entire flow executes in the Realm world and the Hypervisor sees only ciphertext and opaque flags; suppression via dropped triggers is conceded as an availability issue outside scope. OS independence holds because all inputs come from CPU-maintained REC registers or direct memory walks, never through OS interfaces. Monitor–target separation is strictly stronger than 00SEVen's: no shared VM instance, cross-domain hardware isolation. Autonomous symbol resolution consumes only RMM-controlled inputs, so injected fake symbols never enter the localization procedure. Notably, the collusion and symbol-tampering defenses have no equivalent in 00SEVen, whose threat model does not assume them—the authors are careful to frame this as a response to CCA's stricter threat model rather than a criticism of 00SEVen.
Evaluation
All evaluation is on the Arm FVP (FVP_Base_RevC-2xAEMvA, 8 cores, 4 GB DRAM) running TF-RMM v0.1.0 extended with VMI, TF-A, and Linux 6.15.0-rc1, with CNTPCT_EL0 cycle counters. Functionally, RealmEye detects both process hiding and syscall-table hooking by Diamorphine: hidden processes appear fully in RMM-side task_struct traversal (with clean-kernel output matching ps exactly), and the tampered getdents64 and kill entries are correctly flagged, with no false positives observed and the autonomously derived sys_call_table base matching kallsyms.
Performance results emphasize predictability:
| Measurement |
Median |
Notes |
| vmi_read_pa |
1,061 cycles |
includes Stage-2 translation |
| result_encryption |
1,930 cycles |
AES-128, per-command |
| vmi_va_to_pa |
4,523 cycles |
within 6% of the 4× read estimate |
| Process-list walk (50 procs) |
1,161,396 cycles |
predicted ~1.13M, error 2.6% |
| Syscall-table integrity check |
192,246,222 cycles |
predicted ~194M, error ~1% |
IQRs across primitives stay within 60 cycles, indicating highly deterministic execution. End-to-end latency of higher-level strategies is thus linearly predictable from primitive invocation counts. However, the framework's fixed overhead dominates light commands: GET_VCPUREG costs a median of 502 µs end-to-end, almost entirely spent on SMC world switches and the KVM path rather than in-RMM logic. Reducing this floor would require batched commands or RMI extensions, which the authors leave open.
A significant caveat applies throughout: FVP is configured with cache_state_modelled=0 and models neither caches, TLBs, nor pipelines, so reported cycles reflect instruction-level relative cost only. Absolute latencies—including the SMC-switch-dominated 502 µs floor and the Stage-2 TLB-invalidation cost central to page trapping—are unknown until real-hardware measurement, proposed via OpenCCA on RK3588-class boards. OpenCCA emulates RME in software, so it supports performance validation but not the security argument, and no commercial CCA hardware was available to the authors.
Limitations and open questions
The paper is explicit about several constraints. All quantitative results come from simulation without cache/TLB modeling. The prototype uses a hard-coded pre-shared key; attestation-derived session keys are specified but not implemented in the evaluated prototype. The Stage-2 TLB coherence solution for page trapping is described only at the level of intent, and its cost cannot be measured on FVP. Denial-of-service by a malicious Hypervisor (suppressing or delaying scans) is accepted as out of scope, meaning the owner cannot distinguish "clean" from "not scanned." Attacks against the RMM itself are excluded by assumption. Finally, porting to Intel TDX—whose SEAM-mode module plays a role analogous to the RMM—remains unexplored, as does finer-grained semantic validation beyond process lists and syscall tables.
Conclusion
RealmEye establishes the first introspection capability for Arm CCA Realm VMs by relocating VMI execution into the RMM, reusing RMI_REC_ENTER as a non-intrusive trigger channel, encrypting results in-transit, and integrating with LibVMI. It extends threat-model coverage beyond 00SEVen with anti-collusion periodic triggering and autonomous symbol resolution rooted at VBAR_EL1. Detection of Diamorphine works as designed, and in-RMM costs are linearly predictable within roughly 3%. The principal open question is whether these results—and particularly the communication-path overhead and page-trap mechanism—hold on physical CCA hardware, which the evaluation could not yet exercise.