How the Hypervisor Keeps the Collector Out of Reach

HyperAudit’s central protection problem is straightforward to state and difficult to enforce: the collector must observe a guest system call while remaining outside the guest kernel’s authority. This article focuses on the mechanisms that make that separation more than a diagram—hidden loading, higher-privilege page permissions, guard pages, and verified startup—and on the attacker actions each mechanism is meant to stop. The useful judgment is conditional: HyperAudit makes a guest-level collector harder to discover and tamper with, but it does so by moving trust into the hypervisor and Secure VM rather than eliminating trust.

Loading a collector the kernel did not choose

A conventional kernel module is loaded through the kernel’s own interfaces. The kernel allocates or identifies memory for the module, incorporates it into the system’s execution environment, and participates in the chain by which the module becomes trusted. That arrangement is convenient because the module can use the kernel’s symbols, data structures, and services. It is also the wrong starting point for a collector whose purpose is to remain reliable after the kernel is compromised. The component being observed should not be the sole authority that decides whether the observer is present and intact.

HyperAudit reverses that order. When the audited virtual machine is created, the hypervisor reserves additional memory for the collector and its shared buffer. The guest is told that the surrounding usable memory is available, but the reserved region is kept outside the memory range that the guest treats as ordinary physical space. The hypervisor then places the collector’s code, data, page tables, and buffer in that hidden arrangement and injects it while the guest is booting.

“Hidden” here has a specific architectural meaning. The module is not relying on an application-level secret or an obscure file name. It is placed where normal guest interfaces and scans of the guest’s visible physical address space are not expected to find it. The guest’s kernel page tables contain the entries needed for execution, but the guest is not given a normal inventory of the underlying region. This reduces the obvious discovery routes available to a kernel attacker, including checking for a registered module or scanning the usable memory map.

The loading process also establishes a chain of trust above the guest. The bootloader verifies the hypervisor image before starting it. The Secure Hypervisor verifies the Secure VM and the logging module before launching the trusted processing environment and the audited VM. The point is not that a checksum makes a component permanently honest. The point is that the guest kernel is no longer the first and final authority on what code has been inserted into its execution path.

That difference matters at the moment of compromise. If an attacker gains kernel privilege after the guest has booted, they may be able to inspect ordinary kernel modules, disable a guest daemon, or alter guest-owned data structures. HyperAudit’s intended response is that the collector’s installation and protected memory are controlled by a higher layer that the guest attacker does not control under the threat model. The module participates in the guest’s syscall flow, but its existence is not granted the same visibility or ownership as a normal guest service.

The design is not magic invisibility.