Where HyperAudit Draws the Line
HyperAudit is easiest to understand as a division of custody. The specific question is not which component appears in the architecture diagram, but which component is allowed to create, protect, process, and persist each part of an audit record. By following one system call through HyperAudit’s three main responsibilities—the injected Log Collection Module, the Secure Hypervisor, and the Secure VM—we can see why separating authority changes the need for frequent synchronous commits.
The design starts from a difficult constraint. The guest VM is where the workload runs and where the operating system kernel sees system calls, but that kernel is also the component the threat model allows an attacker to compromise. HyperAudit therefore keeps the workload in the guest while moving control of the collector’s code, memory, and downstream processing beyond the guest kernel’s authority. The result is not a remote logging service attached to the old path. It is a different ownership model for the evidence.
Three components, three authorities
The Log Collection Module is the part closest to the event. It is injected into a guest VM by the hypervisor during boot, rather than being loaded through the ordinary kernel-module interface. The module intercepts the guest’s system-call path, gathers the information needed for a record, lets the original system call execute, and records the result. It then writes the record to a shared buffer associated with the audited VM’s CPUs.
Calling this module “inside” the guest can be misleading. The paper describes it as occupying memory in the guest’s address space while remaining independent of the guest operating system. The guest is not told to treat the reserved region as ordinary usable memory, and the hypervisor controls the mapping that makes the module and buffer reachable. The module can therefore participate in the guest’s control flow without becoming another guest-owned service that a kernel attacker can simply disable or rewrite. The detailed memory protections that enforce this arrangement are important, but the architectural point comes first: proximity to the syscall does not imply ownership by the guest kernel.
The Secure Hypervisor is the authority that establishes and enforces this separation. It launches virtual machines, reserves the hidden region for the collector, injects the verified module, controls the relevant second-stage page mappings, and mediates the relationship between the audited VM and the Secure VM. The hypervisor is not merely a transport layer. It decides which memory is visible, which accesses are permitted, and which trusted components may start.
The Secure VM is a separate virtual machine used for receiving and processing logs. Its receiver pulls records from the shared buffer, compresses them, and passes them in batches to persistent storage. Its introspection logic can later organise low-level references into information that an administrator can query, such as process or file context reconstructed from related system calls. Processing and persistence are deliberately kept off the guest’s hot syscall path. That reduces the amount of mutable logging state the guest must own and avoids forcing the guest to synchronously ask a higher-privilege component to protect every event.
These roles form an authority chain. The guest kernel controls workload execution. The hypervisor controls the injected collector’s placement and access rules. The Secure VM controls the receiving and persistence pipeline. The shared buffer is the narrow interface across which evidence moves between the audited environment and the protected processing environment. A guest-level attacker may still control the workload and later kernel state, but under the model used by the paper they cannot automatically inherit the authority of the hypervisor or Secure VM.
The arrows also show what the architecture does not claim. The workload still crosses into the guest kernel. The collector still observes the guest’s syscall path. The shared buffer is still a communication interface, not a magical absence of state. What changes is that the most security-sensitive parts of the collection path are governed from outside the kernel that may later be compromised.
One system call, several custody changes
Consider the lifecycle of a single system call. A program in the guest first issues the call. At the entry point, HyperAudit’s injected module is redirected into the execution path. It captures the entry information, including the syscall’s identifying data and relevant arguments, then invokes the original syscall executor so the application’s operation can continue. After execution, control returns to the module, which records the return value and completes the record before placing it in the shared buffer.
This sequence matters because the collector must be close enough to the syscall to see facts that may not be available later. It cannot wait until the Secure VM receives a compact record and expect to recover every argument from the durable store. At the same time, it must not make the guest kernel responsible for protecting the record after capture. HyperAudit resolves that tension by splitting the event into a capture phase and a processing phase. The guest-side module records low-level facts; the Secure VM later performs work that does not have to delay the syscall itself.
The shared buffer is the handoff point. The collector writes into it, while a receiving process in the Secure VM pulls records proactively. The receiver compresses records and sends them in batches to secure storage. In this design, the guest does not need to call a protected service for every event and wait for a synchronous acknowledgement. The Secure VM can consume the buffer independently, and the record’s later processing does not hold open the original application call.
The final record is not necessarily born human-readable. System calls often expose numeric identities and references whose meaning depends on history. A file descriptor is useful only when it can be connected to the operation that created or changed it; a process identifier becomes more informative when it can be related to an execution event. HyperAudit’s log-introspection path reconstructs that context after collection by tracing relevant system calls and organising the relationships in the Secure VM. That is another custody change: the guest-side path captures evidence, while the protected side interprets it.
This separation has a practical consequence for failure analysis. If the guest kernel is later compromised, it may be able to alter future execution and future guest-visible activity. Under HyperAudit’s assumptions, however, it does not thereby gain authority over the collector’s protected code or the pre-compromise records already in the protected path. The architecture is designed around a time boundary: evidence generated before compromise can be preserved, while evidence generated after a kernel attacker takes control is not granted the same forensic status.
Why the Secure Hypervisor is more than a router
The hypervisor’s role is easy to underestimate if the system is described as “logs sent to another VM.” Ordinary virtual-machine networking or a remote logging channel would move data, but movement alone would not make the source trustworthy. HyperAudit uses the hypervisor to establish the source’s execution and memory conditions before the guest begins normal operation.
At startup, the design reserves space that the audited guest does not treat as available memory. The hypervisor places the collector’s code, data, page tables, and shared buffer in that protected arrangement, verifies the relevant images, and starts the Secure VM and audited VM through a chain of trust. During execution, the hypervisor’s second-stage mappings determine how the guest’s apparent addresses resolve to physical memory and what kinds of access are allowed. A later chapter will examine those protections in detail; here the important relationship is that the guest cannot unilaterally redefine the boundary.
This control also reduces coupling across kernel versions and architectures. A conventional collector can depend on kernel symbols, module interfaces, or data structures that change as the kernel changes. HyperAudit’s injected module still needs architecture-specific knowledge of the syscall path, but the hypervisor owns the injection point and the protected mapping. The paper implements prototypes on x86 and Arm using commodity virtualisation mechanisms, suggesting a deployment path that does not require a special audit appliance. That is evidence of adaptability in the prototypes, not proof that every production hypervisor exposes the same safe hooks or that future kernel changes will be maintenance-free.
The hypervisor is consequently part of the trusted computing base. It is the component that must remain intact for the memory boundary to mean anything. If a guest attacker could rewrite the hypervisor’s mapping decisions, inspect the Secure VM’s memory, or change which module is injected, the separation would be nominal. HyperAudit’s improvement is therefore conditional but concrete: it removes the guest kernel from control of selected evidence states by assigning that control to a higher-privilege component assumed to be trustworthy.
Why processing belongs in a separate VM
The Secure VM performs two jobs that would otherwise add pressure to the audited path. First, it receives and persists the records. Second, it organises them into queryable context. Both jobs require resources and both create state. Keeping them in the guest would increase the amount of logging machinery a kernel attacker could inspect, while performing them synchronously would make every syscall wait for work that is not necessary to complete the original operation.
A separate VM provides a place where those jobs can be isolated from the workload. The paper describes the audited VM and Secure VM as having isolated memory and resources, with communication through the shared log buffer. The Secure VM’s receiver can be dedicated to consuming records, while a separate persistence path batches writes and compresses data. This lets the collection module remain small and focused: capture the event, complete the original operation, and transfer the record.
The separation also makes a useful distinction between collection fidelity and query convenience. The collector’s first responsibility is to preserve the facts available at the syscall boundary. The administrator’s later need is to understand those facts as processes, files, and connections. If the collection path tries to produce a fully formatted human-readable explanation before it can release the syscall, it incurs more work and more dependencies at the most performance-sensitive point. If the Secure VM performs the interpretation later, it can use the sequence of records without making the guest kernel an interpreter the collector must trust.
There is still a capacity boundary. HyperAudit’s receiver is designed to pull records asynchronously, but the shared buffer is finite. If all downstream buffers fill, the system can invoke a commit path that temporarily blocks the audited VM while the Secure VM catches up. Asynchronous operation therefore changes the normal path; it does not promise that the system can absorb unlimited bursts without backpressure. The architecture makes blocking exceptional under the tested design, rather than pretending that resource limits do not exist.
Separation changes the security-performance trade-off
The relationship among the three components explains the design’s main trade-off. In a kernel-coupled architecture, the collector and its pending records are exposed to the same authority that may be compromised. Frequent or synchronous submissions are then used to reduce the time those records remain vulnerable. In HyperAudit, the collector and buffer are protected by a higher authority, so the normal path can leave records pending while the Secure VM consumes them asynchronously.
That does not mean HyperAudit removes all work from collection. It still intercepts calls, captures parameters, records returns, and writes to a buffer. It moves processing and persistence away from the guest and reduces the need for repeated cross-privilege commits. The gain comes from changing which work must happen before the application can continue, not from collecting less evidence by definition.
The architecture should therefore be judged by custody transitions, not by component count. At syscall entry, the collector has to see enough to form a record. At buffer handoff, the hypervisor has to prevent the guest from rewriting the protected state. At Secure VM reception, the consumer has to keep up with producers. At persistence, storage and access controls still matter. At query time, reconstruction must preserve the meaning of the raw sequence. Each transition has a different owner and a different failure condition.
HyperAudit draws its most important line between the guest kernel and the collection state it would otherwise control. The line is valuable because it breaks the causal loop diagnosed earlier: the guest can remain the place where work executes without also being the place that decides whether the account of that work survives. The next question is how the hypervisor makes that line hard to discover and cross without sacrificing the collector’s usefulness.