Towards Remote Attestation of Microarchitectural Attacks: The Case of Rowhammer

1. Problem Statement

The fundamental assumption in system security is that hardware serves as a reliable "root of trust," preserving memory integrity for software layers. However, microarchitectural vulnerabilities, particularly Rowhammer, undermine this foundation.

• The Vulnerability: Rowhammer exploits physical proximity in DRAM cells. Repeatedly activating "aggressor" rows causes charge leakage in adjacent "victim" rows, inducing bit-flips. These flips can corrupt critical data structures (e.g., page tables), allowing privilege escalation from unprivileged code to kernel-level execution.
• The Limitation of Prevention: Traditional defenses (e.g., Target Row Refresh, ECC, memory isolation) are often reactive, vendor-specific, and increasingly bypassed by advanced variants (e.g., Half-Double, Many-Sided, ECCploit, Rowpress).
• The Detection Gap: Once a system is compromised via Rowhammer, an attacker with kernel-level privileges can suppress or forge local software-based monitoring. Existing Remote Attestation (RA) protocols verify software state (firmware, OS, binaries) but fail to detect hardware-induced fault behaviors because they do not incorporate microarchitectural fault indicators into their integrity measurements.

2. Methodology: HammerWatch

The authors propose HammerWatch, a novel remote attestation protocol that shifts the paradigm from prevention to detection. It enables an external verifier to assess whether a system exhibits hardware-induced disturbance behavior, even if the local OS is compromised.

Core Architecture

HammerWatch integrates hardware-level evidence into a Trusted Platform Module (TPM)-anchored attestation workflow.

1. Measurement Sources:
   • Machine-Check Exceptions (MCEs): Derived from ECC DRAM. When the memory controller detects uncorrectable errors or repeated correctable errors (indicative of bit-flips), it logs an MCE.
   • Alert Back-Off (ABO) Events: Derived from Per-Row Activation Counting (PRAC), a DDR5 standard. If a row exceeds a predefined activation threshold, the DRAM triggers an ABO signal, indicating excessive hammering activity.
2. Protection Mechanism (Integrity & Authenticity):
   • Measurements are collected on the prover (the target system) but are not stored in volatile memory where they can be altered.
   • Instead, they are cryptographically bound to a TPM. The TPM maintains a cumulative hash chain (Platform Configuration Register - PCR) using the Merkle-Damgård construction.
   • Each new measurement is hashed into the previous PCR value. This creates an append-only log that cannot be forged or rolled back, even by a kernel-level adversary.
   • To prevent "replay" or "fabrication" attacks where an attacker might try to sign a clean log, the protocol uses a secret value issued by the verifier after every reboot, which is hashed into the PCR before any measurements are logged. The attacker cannot know this secret.
3. Protocol Flow (Challenge-Response):
   • Verifier: Sends a unique nonce to the Prover.
   • Prover: Halts measurement logging (to prevent race conditions), retrieves the current PCR value, signs the (Nonce + PCR) using the TPM's private key, and encrypts the measurement log using the Verifier's public key.
   • Verifier: Decrypts the log, verifies the signature, recalculates the PCR hash chain to ensure integrity, and applies heuristics to the measurements.

3. Key Contributions

• First Microarchitectural-Aware RA Protocol: HammerWatch is the first protocol to systematically incorporate hardware fault indicators (MCEs and PRAC counters) into remote attestation.
• TPM-Anchored Hash Chains: The design ensures that even if an attacker gains kernel privileges after an attack, the evidence of the attack remains permanently embedded in the TPM's hash chain, making it impossible to erase.
• Commodity Implementation: The system is implemented on standard Linux hardware using existing subsystems (EDAC for MCEs) and simulated PRAC behavior (using Ramulator 2.0), demonstrating feasibility without requiring custom hardware modifications.
• Defense Against TOCTTOU: The protocol mitigates Time-of-Check-to-Time-of-Use attacks by binding the attestation to a fresh nonce and a reboot-dependent secret.

4. Evaluation and Results

The authors evaluated HammerWatch using 20,000 simulated access patterns (10,000 benign, 10,000 malicious) on a simulated DDR5 environment with PRAC.

• Detection Accuracy:
  • Heuristics: The system classifies a system as compromised if it observes >3 MCEs or >3 ABO alerts (based on conservative thresholds suggested by prior research).
  • Performance: The protocol achieved 100% detection accuracy with zero false positives and zero false negatives in the simulated environment. It reliably distinguished Rowhammer-like behavior from benign operation.
• Overhead:
  • The runtime overhead is minimal because logging is workload-independent and cryptographic operations (RSA signing/encryption) are infrequent (only during attestation).
  • Memory overhead is dominated by the measurement log, which remains small for typical workloads.
• Scalability: The approach scales well for data centers, though the authors note that high-volume benign faults in data centers might require refined heuristics to avoid false positives.

5. Significance and Future Implications

• Paradigm Shift: The paper argues that since hardware vulnerabilities cannot be fully eliminated in deployed systems, security must evolve from "preventing all attacks" to "detecting and isolating compromised systems."
• Complementary Defense: HammerWatch does not replace prevention mechanisms (like TRR or ECC) but acts as a safety net. If prevention fails, the system is detected and isolated before it can interact with other critical infrastructure.
• Generalizability: While instantiated for Rowhammer, the framework is attack-agnostic. It can be extended to other microarchitectural attacks (e.g., Spectre/Meltdown, cache timing attacks) by integrating different hardware-side signals (e.g., performance counters, branch misprediction rates) into the TPM-anchored hash chain.
• Trust in Hardware: The work challenges the notion of hardware as a static root of trust, proposing a dynamic model where hardware behavior is continuously monitored and attested to maintain system-wide trust.

Conclusion

HammerWatch demonstrates that remote attestation can be successfully extended beyond software integrity to include microarchitectural fault behavior. By leveraging commodity hardware signals (MCEs and PRAC) and protecting them via TPM-anchored hash chains, it provides a robust mechanism to detect Rowhammer attacks even when the local system is fully compromised, offering a viable path forward for securing systems against evolving hardware threats.