This post is a review of BlueGuard: Accelerated Host and Guest Introspection Using DPUs, a USENIX Security 2025 paper. The paper asks a direct but important question: can we run security introspection outside the monitored system, away from the host CPU, while still keeping it fast enough to catch short-lived malware artifacts?

BlueGuard’s answer is the DPU, or Data Processing Unit, often discussed as a SmartNIC. Instead of treating the DPU as only a faster network adapter, BlueGuard uses it as an isolated security observation point for VMs, hypervisors, and bare-metal hosts. In that sense, the system extends classic VMI, or Virtual Machine Introspection, toward HGI: Host and Guest Introspection.

Paper link: USENIX Security 2025 - BlueGuard

Why DPUs

The appeal of VMI has always been the idea of looking from outside. Malware inside a VM may hide processes, tamper with files, or disable in-guest security tools. An external monitor can instead read memory and reconstruct higher-level state such as process lists, kernel modules, credentials, and suspicious memory patterns.

Existing approaches have awkward tradeoffs. Host-based VMI runs in the hypervisor or on the host CPU, so it competes with tenant workloads and may become less trustworthy if the host side is compromised. Traditional out-of-band approaches improve isolation, but they often struggle with latency, scalability, or the exposure of memory traffic over external paths.

BlueGuard chooses the DPU for three reasons.

1. A DPU is physically separated from the host CPU, which gives the monitor a stronger isolation boundary.
2. A DPU provides hardware engines such as DMA, hashing, and regex matching, which can accelerate memory acquisition and malware scanning.
3. A DPU sits on the network path, so it can also enforce containment by moving an infected VM or host into a restricted VLAN.

The attractive part is that BlueGuard combines observation, acceleration, and response in one device.

Architecture

BlueGuard is implemented on an NVIDIA BlueField-2 DPU. It uses SR-IOV to expose virtual DPUs, or vDPUs, to VMs or the hypervisor. For each introspection target, BlueGuard creates a VMI context that holds queues for DMA, SHA, and regex engines, completion queues, address translation caches, kernel symbol information, and related metadata.

VMI applications do not need to directly manage DPU queues. They submit jobs through BlueGuard’s interface: what address to read, how many bytes to access, and which operation to apply. For example, pslist traverses Linux task_struct lists, modules reconstructs the kernel module list, and check_creds looks for processes sharing credential structures.

The design is interesting because BlueGuard is not merely “VMI code moved to a DPU.” DPU general-purpose cores are limited compared with server CPUs, so the runtime has to be careful. BlueGuard uses non-blocking memory access and a cooperative N:M threading model based on C++ coroutines. When a VMI application issues a memory request, it yields, and the scheduler runs another VMI task while the DPU processes the request.

That matters because many VMI applications are pointer-chasing workloads. They read one address, compute the next address, read again, and repeat. Blocking on every access would waste DPU cores and make context-switch overhead expensive. BlueGuard tries to overlap waiting time with useful work.

The Hard Part: Address Translation

External memory introspection always runs into address translation. Analysts care about kernel objects such as task_struct, but the hardware ultimately reads physical addresses. In VMs, guest virtual addresses, guest physical addresses, and host physical addresses all get involved.

BlueGuard performs software page-table walks for x86 four-level page tables. Because it cannot directly read CPU registers such as CR3, it uses kernel symbols and known memory contents to locate the kernel root page table. For VM introspection, GPA-to-HPA translation can be offloaded to the IOMMU; for hypervisor and bare-metal introspection, BlueGuard can work more directly with physical addresses.

This comes with an important trust model. BlueGuard trusts the DPU, the DPU software, and the initialization phase. The target VM or hypervisor is assumed to start from a valid state, after which the attacker may compromise it at runtime. Hypervisor-controlled IOMMU manipulation and translation redirection attacks are considered out of scope. That is not unique to BlueGuard; it is a shared challenge for many out-of-band introspection systems.

Delta Introspection

The most practical idea in the paper is delta introspection.

A VMI application ultimately consumes memory reads. During the first full run, BlueGuard records the remote addresses, sizes, and values that the VMI application accessed. Later, instead of re-running the whole application, BlueGuard batches reads to the same memory locations and compares their digests. If nothing changed, the expensive plugin can be skipped. If a delta appears, the full plugin runs again to reconstruct the new state.

This is especially useful for stealthy malware. Some malicious processes or kernel modules leave visible artifacts for only a few milliseconds. If full introspection is too slow, the monitor can miss that short window. Delta introspection lets BlueGuard check for changes quickly and only pay the full reconstruction cost when the input changed.

The paper models the time window needed for 100% detection as 2 * delta latency + VMI app latency. For the modules application, the paper reports an average delta introspection latency of 108.2 microseconds and a plugin latency of 1.38 milliseconds. That implies a required artifact window of about 1.59 milliseconds under the model.

Evaluation

The authors evaluate BlueGuard on a server with two Intel Xeon Gold 6130 CPUs, 204GB RAM, KVM/QEMU VMs, and an NVIDIA BlueField-2 DPU. They run up to 16 real VMs and simulate larger scale by creating more VMI contexts, up to 64 VMs.

The key results are strong.

1. For memory access latency, BlueGuard is about 3x faster than LibVMI for small buffers, and about 27x to 33x faster for 1MB and 2MB buffers.
2. When reading full VM memory in 2MB chunks, BlueGuard reaches about 53Gbps of introspection bandwidth, roughly 27x higher than the prior HGI baseline cited by the paper.
3. In the check_creds comparison with RDMI, BlueGuard needs 2.08ms for the paper’s 100% detection model, compared with 8.94ms for RDMI, a 4.3x speedup.
4. modules_integrity becomes about 12x faster with the DPU hashing engine than with software hashing.
5. regex_scan improves by roughly two orders of magnitude with the DPU regex engine compared with the software implementation.
6. BlueGuard scales to 64 VM contexts with graceful degradation rather than a sudden collapse.

The workload isolation result may be the most important part for cloud operators. In the Redis experiment, LibVMI-based pslist can significantly reduce Redis throughput when it competes for the same CPU. BlueGuard avoids that because the introspection work runs on the DPU. The point is not only faster security scanning; it is security scanning that does not steal tenant CPU.

Malware Detection and Isolation

The paper evaluates BlueGuard against open-source rootkits and real malware families. Diamorphine and Reptile are Linux kernel module rootkits that hide themselves after loading. BlueGuard uses the modules VMI application with delta introspection to detect changes in the module list.

The reported detection rates are 91% for Diamorphine and 100% for Reptile. The Diamorphine result is useful because it shows the difference between average-latency reasoning and tail-latency reality. Even if the model suggests full detection, short artifact windows can still be sensitive to P90 latency or shorter-than-measured visibility.

The real malware evaluation includes Cl0p, Gafgyt, Mirai, XMRig, DinodasRAT, AresRAT, Babuk, and Kaiji. BlueGuard uses regex_scan for indicators such as onion addresses and pslist for suspicious parent-child process relationships. The paper reports detecting 108 of 132 sh child processes and identifying onion-address indicators for every executed malware sample.

The containment experiment is also notable. Once BlueGuard detects a suspicious process, it changes OVS configuration on the DPU and moves the VM into a containment VLAN. In the paper’s ping-based experiment, isolation happens after 27.7ms on average, with a minimum of 12.19ms and a maximum of 83.04ms.

What I Like

The strongest idea in BlueGuard is viewing the DPU as a cloud security control point rather than just a network offload device. The DPU has access to memory movement, inline computation, and network policy enforcement. BlueGuard uses all three.

I also like that the paper keeps compatibility with the VMI ecosystem in mind. It discusses how tools such as Volatility could be integrated by exposing a suitable memory-read interface. In practice, the ease of adding new detection logic matters as much as raw performance.

Delta introspection also feels reusable beyond this paper. Any external observer that repeatedly runs expensive analysis over changing state can benefit from a “full run first, fast input-change check later” pattern.

What To Be Careful About

BlueGuard is not a universal monitor. Its threat model draws clear boundaries.

First, the DPU and BlueGuard software are trusted. A compromised DPU firmware or DPU runtime is outside the model.

Second, initialization is trusted. The system assumes BlueGuard can set up memory access while the VM or hypervisor is still in a valid state. If the platform is already compromised before initialization, the story gets harder.

Third, BlueGuard cannot observe CPU-internal state such as registers or TLB entries. That leaves room for CR3 manipulation and translation redirection issues, which are hard problems for out-of-band introspection more generally.

Fourth, consistency remains challenging. BlueGuard does not pause VMs during introspection because pausing is too expensive. The paper mentions an earlier cooperative design that trapped CR3 updates, but KPTI made this approach extremely costly for Redis throughput. That explains why BlueGuard favors a non-cooperative design even though it leaves some consistency limitations.

Conclusion

BlueGuard is a compelling answer to the question of where security introspection should run. Running inside the host competes with tenant workloads and shares more trust assumptions with the attacker. Running far outside the host can be slow or operationally awkward. A DPU sits in a useful middle ground: physically separated from the CPU, yet close to memory movement and network enforcement.

What makes the paper convincing is not simply that the authors moved introspection to a DPU. It is that the runtime design acknowledges the DPU’s constraints. Non-blocking scheduling, batching, address translation caches, delta introspection, and inline accelerator abstractions all serve one goal: continuously monitoring many VMs with limited DPU resources.

To me, BlueGuard is a small preview of where cloud security architecture may keep moving. Security functions are shifting away from the guest OS, away from the hypervisor, and toward the boundary where networking, acceleration, and isolation meet. In that world, the DPU becomes more than an offload device. It becomes a security plane.