RealmEye: Virtual Machine Introspection for Arm CCA Realm VMs

RealmEye is the first Virtual Machine Introspection (VMI) system for Arm CCA Realm VMs. It places the entire VMI logic inside the Realm Management Monitor (RMM) at R-EL2, achieving hardware-enforced separation between the monitor and the monitored VM: no agent runs inside the Realm, and the Realm itself remains unmodified. From this vantage point, RealmEye reads Realm memory and registers, suspends the VM for consistent snapshots, and traps page-level accesses, all without relying on any interface the in-VM OS exposes. The authors extend the Realm Management Interface (RMI) to carry VMI triggers and encrypted results between the Host and the RMM, bind the result channel to a hardware-attested session with the remote owner, and add a CCA driver backend to LibVMI so that existing tools such as DRAKVUF interoperate with RealmEye unchanged. RealmEye is therefore isolated from the cloud platform—including a malicious Hypervisor—by Arm CCA’s own hardware mechanisms, and isolated from in-Realm rootkits by the R-EL2 boundary of the RMM. A periodic, self-driven trigger mode keeps scan timing internal to the RMM, preventing the Hypervisor from colluding with in-Realm rootkits. On the Arm FVP, RealmEye detects both process hiding and syscall-table hooking by Diamorphine, a real-world ARM64 rootkit, and its in-RMM cost is linearly predictable from primitive invocation counts—laying the foundation for the first introspection ecosystem on Arm CCA.

The paper identifies three CCA-specific challenges for VMI: the absence of memory-introspection interfaces in the RMM, the REC-lock concurrency conflict with VMI triggers, and Stage-2 TLB coherence. Each is addressed with a systematic solution. The design goals are organized into functional and security categories. Functional goals include: F1 (State access) allowing the VM owner to read memory contents and register state of a Realm VM; F2 (Suspension) pausing the Realm VM during a VMI scan to obtain a consistent state snapshot; F3 (Page-level trapping) monitoring read/write accesses to specific memory pages; and F4 (API compatibility) exposing a LibVMI-compatible interface. Security goals include: S1 (Hypervisor independence), S2 (VM OS independence), S3 (Secure communication), S4 (Monitor–target separation), and S5 (Autonomous symbol resolution).

The design places VMI logic in the RMM because it is the only component that both has the hardware privilege to access Realm-internal state and lies beyond the reach of any in-VM attacker. The Hypervisor is barred by the GPT from Realm memory, and the Realm VM itself lacks any VMPL-style intra-VM privilege layering. The end-to-end pipeline reuses the rec run shared-memory structure already used by RMI REC ENTER as the communication carrier, with the enter field embedding trigger flags and command parameters, and the exit field carrying encrypted scan results.

For state access and consistent snapshots, register access is straightforward since the RMM reads directly from the REC, which is maintained by CPU hardware and holds key system registers including TTBR1 EL1, VBAR EL1, and SP EL0. Memory access builds a complete two-stage read path inside the RMM: manually walking the Realm VM’s kernel page tables for Stage-1 translation, invoking the existing RMM helper realm ipa to pa for Stage-2 translation, and bringing the target physical page into the RMM’s own address space through a transient mapping. VM suspension is achieved naturally because every VMI scan executes inside RMI REC ENTER before the Realm VM is allowed to resume.

For page-level trapping, the basic mechanism is to clear the write bit in the corresponding Stage-2 page-table entry of the Realm VM, so any subsequent write triggers a Stage-2 fault that exits to the RMM. The CCA-specific challenge is TLB coherence, since the Hypervisor is excluded from the Realm TCB and has no authority to invalidate Realm Stage-2 TLBs.

For Host–RMM communication, introducing a new SMC call would deadlock because the granule lock of the REC is already held by the in-flight RMI REC ENTER call. RealmEye therefore reuses the existing RMI REC ENTER call and embeds the trigger signal in its rec run.enter parameter. The Host-side KVM module checks for pending VMI requests and sets a trigger bit in the parameter; the RMM inspects this bit at entry and performs the VMI scan before resuming the Realm VM. Two triggering modes are offered: on-demand mode where the VM owner issues requests through the Hypervisor, and periodic mode where the trigger decision is made entirely inside the RMM at autonomously chosen intervals, preventing Hypervisor–rootkit collusion.

Scan results are encrypted with AES-128 inside the RMM before being written to rec run.exit, so neither the Hypervisor nor the Host kernel ever sees plaintext. The current implementation uses a pre-shared key with the VM owner; a production deployment should derive a session key through CCA attestation. End-to-end trust is established by binding remote attestation to the secure-channel protocol, building on RA-TLS and related work.

The implementation spans three layers: user space, the Host kernel, and the RMM. At the user level, the VM owner issues VMI requests through a debugfs interface exposed by KVM. The Host KVM module records the request as a pending flag on the target vCPU, and raises bit 63 in the enter.flags field of rec run as the VMI trigger signal. The RMM examines bit 63 at entry and enters the VMI scan path before restoring control to the Realm VM.

The read path in the RMM starts with register access from the plane sysregs structure stored in the REC, then manually implements the full ARM64 four-level Stage-1 walk, decoding page-table descriptors at levels 0 through 3, including block descriptors at levels 1 and 2 for huge-page mappings. Process-list traversal uses SP EL0 to find the task struct of the currently running process, walks the doubly-linked tasks list, and reads the pid and comm fields of each task. Syscall-table integrity checking localizes sys call table autonomously: the RMM reads VBAR EL1 from the REC, derives the kernel text base stext from the fixed compile-time offset of 0x800, then scans a bounded address range past stext looking for runs of eight consecutive function pointers that all fall within the kernel code segment.

The LibVMI-compatible interface adds a CCA driver backend to LibVMI that implements the core API including vmi read pa, vmi read va, vmi get vcpureg, vmi pause vm, and vmi set mem event. Each API call issues a KVM ARM CCA VMI ioctl carrying the command type and parameters to the Host KVM module, which encodes them into the general-purpose register fields of rec run.enter and raises the trigger flag.

The security analysis argues that each of the five security goals is met. S1 is met because the Hypervisor plays no role in anything that affects detection correctness. S2 is met because RealmEye reads all data directly from RMM-controlled sources without invoking any interface provided by the Realm VM’s OS. S3 is met because result encryption happens inside the RMM and plaintext never leaves the Realm world. S4 is met because the VMI logic resides entirely in the RMM in an execution domain distinct from the monitored Realm VM, with isolation enforced by CCA hardware. S5 is met because the symbol localization path consumes no symbol tables or symbol addresses supplied by either the Realm VM or the Hypervisor.

Evaluation on the Arm FVP shows that RealmEye effectively detects both process hiding and syscall-table hooking by Diamorphine. For process-list traversal, when Diamorphine marks a process as hidden, RealmEye’s traversal of the task struct list from the RMM reveals the hidden process’s pid and comm fields in full. For syscall-table integrity checking, after loading Diamorphine, the getdents64 and kill entries are replaced by hook-function addresses in the module-loading region, and the check correctly flags them as tampered.

Microbenchmarks measure three RMM-internal primitives: result encryption at 1930 cycles median, vmi va to pa at 4523 cycles median, and vmi read pa at 1061 cycles median. The cost composition of vmi va to pa is verified independently: a four-level walk dominated by four underlying physical-memory reads should cost approximately 4 × 1061 = 4244 cycles, and the measured median of 4523 cycles deviates by only about 6%.

Macrobenchmarks show that process list walking with 50 processes has a measured median latency of 1,161,396 cycles, predicted at 1,130,750 cycles (2.6% error). Syscall table integrity check has a measured total latency of 192,246,222 cycles, predicted at approximately 194,000,000 cycles (about 1% error). The prediction error stays within 3% in both cases, confirming that the latency of higher-level VMI operations is linearly predictable from the invocation counts of the underlying primitives.

The per-command framework cost, measured using the lightest fine-grained command GET VCPUREG, has a measured median latency of 502 µs, with the bulk of the cost spent outside the RMM on the SMC world switch and the KVM path. This imposes a approximately 502 µs floor on every VMI command; pushing this floor down further requires batched commands or extensions to the RMI interface.

The paper discusses future work including real-hardware evaluation via OpenCCA, extension to TDX, and finer-grained kernel-data semantic validation.

Improvements to AI Systems:

1. Hardware-Enforced Introspection for AI/ML Workloads: Integrate RealmEye-style VMI into AI systems running in confidential computing environments (e.g., Arm CCA Realms) to provide tamper-proof monitoring of AI model execution. This allows AI systems to detect and respond to kernel-level rootkits or hypervisor-level attacks that attempt to manipulate model weights, inference logic, or training data in real time, without relying on in-VM agents that could be compromised.

2. Autonomous Symbol Resolution for Kernel Integrity: Use RealmEye’s symbol-localization technique (deriving kernel text base from VBAR EL1 and scanning for function-pointer patterns) to build AI-based anomaly detectors that autonomously validate kernel data structures (e.g., syscall tables, process lists) without external symbol tables. This enables AI systems to self-verify their runtime environment integrity and flag deviations caused by malware, even in the absence of OS cooperation.

3. Predictable Performance Modeling for AI Operations: Apply RealmEye’s linear latency-prediction methodology (based on primitive invocation counts) to AI inference pipelines. This allows AI systems to estimate the computational cost of security checks or introspection tasks before execution, enabling dynamic resource allocation and scheduling that balances security overhead with performance guarantees in real-time AI applications.

4. Secure Result Channel for AI Telemetry: Adopt RealmEye’s encrypted result channel (AES-128 inside the RMM, bound to hardware attestation) to securely transmit AI system telemetry (e.g., model behavior logs, anomaly scores) from confidential execution environments to remote owners. This ensures that AI monitoring data remains confidential and tamper-evident, even when the host hypervisor is malicious, enabling trustworthy federated learning or distributed AI auditing.

5. Page-Level Trapping for AI Memory Protection: Leverage RealmEye’s Stage-2 page-level trapping (with TLB coherence handling) to implement fine-grained memory access control for AI models. This allows AI systems to detect and block unauthorized writes to critical model parameters or inference buffers, preventing memory-corruption attacks or adversarial perturbations injected via DMA or hypervisor-level interference.

6. Collusion-Resistant Periodic Scanning: Integrate RealmEye’s self-driven periodic trigger mode (where scan timing is internal to the RMM) into AI systems to autonomously schedule integrity checks at unpredictable intervals. This prevents an attacker (e.g., a malicious hypervisor or in-VM rootkit) from timing attacks to evade detection, ensuring continuous and reliable security for AI operations in untrusted cloud environments.

7. LibVMI-Compatible AI Monitoring Interface: Extend AI frameworks to use the LibVMI-compatible CCA driver backend, allowing existing AI security tools (e.g., DRAKVUF-based malware analysis) to interoperate with confidential AI systems without modification. This enables AI systems to leverage a rich ecosystem of introspection tools for threat hunting, incident response, and forensic analysis of AI workloads.

What the Improved AI System Can Do:

• Run AI inference and training in Arm CCA Realms with hardware-isolated, agentless introspection that detects and mitigates kernel-level attacks in real time.

• Self-verify its own runtime integrity (e.g., syscall tables, process lists) autonomously, without relying on OS-provided interfaces or external symbol data.

• Predict and optimize the performance overhead of security checks, ensuring low-latency AI responses even under continuous monitoring.

• Securely stream AI telemetry and anomaly reports to remote owners over attested, encrypted channels, resistant to hypervisor compromise.

• Block unauthorized memory writes to model parameters or critical buffers at the hardware level, preventing adversarial manipulation.

• Schedule integrity scans at unpredictable, RMM-controlled intervals to defeat timing-based evasion attacks.

• Seamlessly integrate with existing VMI-based security tooling, enabling comprehensive monitoring and forensic analysis of AI workloads in confidential cloud environments.