ACRN Security: A Journey into Fuzzing and Hardening Edge Hypervisors

### Overview Mustafa Saeed and Stefan Schulz present Intel's offensive security validation efforts focused on fuzzing and hardening ACRN, an open-source, lightweight Type-1 bare-metal hypervisor designed for edge and IoT use cases. Edge environments demand high responsiveness, low latency, and real-time execution, which prevents simply relying on cloud infrastructure. ACRN bridges data center and partitioning hypervisors by running heterogeneous workloads with mixed criticality (safety-critical, real-time, and general-purpose VMs) across automotive, industrial, and smart infrastructure deployments. To ensure robustness and meet functional safety standards, Intel incorporates negative security testing and fuzzing into its Security Development Lifecycle (SDL).

### Key Topics - **Edge Virtualization Architecture**: ACRN manages three VM categories—Service VM, User VMs, and Pre-launched VMs—running directly on hardware. The Service VM houses native drivers and a QEMU-like device model in user space, while the VirtIO and Hypervisor Service Module (VHM) acts as an intermediary kernel module communicating with the hypervisor via downcalls and upcalls. - **Trusted Computing Base (TCB) & Security Boundaries**: The hypervisor operates in privileged VMX root mode (treating all VMs as untrusted). The VHM trusts only the hypervisor, and the user-space device model trusts the hypervisor and VHM while treating guest VM data as untrusted. - **Interface Analysis**: Six core attack surfaces require negative testing: hypercalls between the VHM and hypervisor, system calls/IOCTLs between user space and the VHM, the device model's command-line configuration interface, VirtIO front-end/back-end communication, emulated MMIO/PIO memory regions, and passthrough devices.

### Technical Details To test these diverse interfaces, the team evaluated and applied several specialized fuzzing frameworks: 1. **syzkaller**: Applied to test IOCTL interfaces into the VHM kernel module using declarative descriptions in `syslang`. The team extended syzkaller by placing a test proxy inside the device model, generating fuzz inputs via `sys-executor` on the target VM, and propagating them through the VHM down into hypercalls (`create_vm`, IO request notifications). Coverage guidance worked effectively in the VHM kernel, but blind fuzzing occurred at the hypervisor level due to lack of hypervisor compiler coverage integration (e.g., GCOV). 2. **libFuzzer**: Employed as an in-process, coverage-guided fuzzer targeting the device model's command-line configuration parser. Fuzz inputs were passed via `LLVMFuzzerTestOneInput`, converting inputs into configuration parameters (memory size, display, VirtIO assignment) before executing the main function. While effective with sanitizers (ASan, MSan, UBSan), it required code refactoring to remove `exit()` statements, and using it on the emulation backend caused false positives because it bypassed upstream validation layers in the VHM and hypervisor. 3. **Hypercube OS**: Developed by Ruhr University Bochum, Hypercube was deployed as a custom guest OS running directly on ACRN. It automatically enumerates assigned PCI devices, MMIO, Port I/O regions, and APIC/IOAPIC registers, generating randomized inputs to fuzz low-level interfaces. Although easy to integrate, it functions as a blind fuzzer without coverage feedback. 4. **Future Work with kAFL and Nyx**: To achieve coverage-guided feedback for guest-side hypervisor testing, the team is exploring nested virtualization. By running ACRN inside modified QEMU/KVM alongside kAFL/Nyx, Intel processor trace (Intel PT) can capture hardware-assisted execution traces back to a kAFL server, enabling fast snapshotting and structured VM interface fuzzing.

### Takeaways Fuzzing low-level edge hypervisors cannot be solved by a single tool due to varied architectural boundaries spanning user space, kernel space, and bare-metal hypervisor contexts. While syzkaller and libFuzzer provide strong coverage guidance for kernel modules and configuration parsers, guest-to-hypervisor testing requires specialized tooling like Hypercube. Moving forward, combining research tools like kAFL/Nyx with Intel PT nested virtualization will enable coverage-guided feedback across the entire low-level ACRN stack.