PaperlayerView exact revision on arXiv

Source-linked AI summary

JENGA: Exploiting Counter-Based RowHammer Countermeasures to Break Real-Time Predictability

Valentin Abgrall, Marcello Traiola, Ruben Salvador, Maria Méndez Real, Alessandro Palumbo, Angeliki Kritikakou

arXiv:2609.01077v1cs.CRcs.AR

TL;DR

The paper addresses the limited study of RowHammer countermeasures’ worst-case timing effects in real-time systems. It develops and evaluates JENGA against PRAC-protected DRAM, finding delays up to 200% of WCET, and derives a safe analytical WCET bound.

  • Problem

    Worst-case timing effects of RowHammer countermeasures have not been thoroughly investigated, despite their relevance to real-time WCET guarantees.

  • Method

    The paper develops JENGA and a theoretical WCET analysis, evaluating PRAC-N with gem5, Ramulator 2.0, and TACLeBench workloads.

  • Results

    200% of WCET is the reported maximum task delay under adversarial conditions, while the derived bound safely exceeds observed attack execution times.

  • Takeaways & Limitations

    Countermeasure-induced delays must be incorporated into WCET analysis for DRAM systems protected against RowHammer.

  • Takeaways & Limitations

    The WCET analysis focuses on a simple architecture and omits effects from complex processor and memory hierarchies.

Abstract

from arXiv · show

Safety-critical real-time systems must satisfy multiple dependability requirements, notably time predictability and security. In such systems, tasks must complete within bounded and known execution times, typically characterised through Worst-Case Execution Time (WCET) analysis. At the same time, DRAM-based platforms are increasingly sensitive to the RowHammer read-disturbance security vulnerability, which has motivated the development of numerous hardware and software countermeasures in both academia and industry. However, the impact of these defences is generally evaluated in terms of average-case performance, a metric that is insufficient for safetycritical real-time systems, where worst-case behaviour is the primary concern. In this paper, we study the impact of RowHammer countermeasures based on hardware counters on the timing behaviour of real-time systems. We use a Per-Row-Activation-Counter (PRAC) countermeasure as a case study, standardised for recent DDR5 memories, and show that it can introduce significant timing variations. Based on this observation, we introduce JENGA, an attack in which an attacker-controlled task manipulates the internal state of the RowHammer countermeasure mechanism to increase the execution time of a victim real-time task beyond its expected WCET. We implement JENGA in a gem5 and Ramulator 2.0 simulation environment and evaluate its impact on TACLeBench workloads. We show that such an attack can delay tasks up to 200% of their WCET, making the initial timesafety assumptions unsafe. To address this issue, we derive a safe analytical bound that accounts for mitigation-induced delays in WCET analysis for DRAM systems protected by hardware countermeasures, such as PRAC-N.

I. INTRODUCTION

Safety-critical real-time systems must combine predictable execution with security, but RowHammer countermeasures can introduce timing variability that threatens WCET assumptions. This paper studies that risk through JENGA, evaluates it on PRAC-protected DRAM, and derives a safe WCET bound.

  • Security mechanisms can add computation, memory accesses, contention, and timing variability that may compromise schedulability in safety-critical systems.
  • RowHammer hardware countermeasures increasingly matter as lower detection thresholds require more frequent mitigations and increase memory interference.
  • JENGA manipulates hardware-counter state through an attacker-controlled task, causing cascading mitigations that delay a victim real-time task.
  • 200% of WCET is the maximum reported task delay under JENGA, making initial time-safety assumptions unsafe.
  • The paper develops a theoretical WCET analysis for single-core systems protected by hardware-counter-based RowHammer countermeasures and applies it to PRAC for DDR5.
  • Gem5 and Ramulator 2.0 simulations with TACLeBench workloads evaluate JENGA, while ten characteristic workloads empirically validate the analytical WCET bound.

B. The RowHammer attack

RowHammer exploits repeated aggressor-row activations to induce bit flips in neighbouring victim rows. Countermeasures monitor activations and trigger refresh-based mitigation, but their interference can affect worst-case timing.

  • Repeatedly activating an aggressor row can induce bit flips in neighbouring victim rows when the disturbance threshold is exceeded.
  • RowHammer and related read-disturbance vulnerabilities have enabled software attacks including privilege escalation, sandbox escape, and cross-VM compromise.
  • Hardware countermeasures monitor ACT commands with activation counters and trigger additional refreshes when predefined conditions are met.
  • PRAC-N assigns each DRAM row a hardware counter, sends an ABO alert after a manufacturer-defined condition, and then issues 1, 2, or 4 RFM commands.
  • RFM refreshes can increment the counters of refreshed rows and trigger additional mitigations, while at least N ACT commands must separate successive alert bursts.
  • Average performance degradation has been studied more than worst-case execution-time effects, motivating analysis of RowHammer countermeasures in real-time workloads.

D. DRAM in Critical Real-Time Systems

Safety-critical real-time systems prioritize predictable worst-case timing, yet RowHammer countermeasures have received limited attention in this setting. The paper evaluates PRAC-N under a representative single-core, closed-row system model and notes that open-row systems may experience reduced but fundamentally similar interactions.

  • D. DRAM in Critical Real-Time Systems: Real-time systems prioritize predictable worst-case memory latency over average-case performance, motivating closed-row policies for WCET analysis.Open-row policies improve throughput through locality but introduce data-dependent access latencies.
  • D. DRAM in Critical Real-Time Systems: RowHammer countermeasures have received very little attention in real-time systems, leaving their impact on timing predictability insufficiently studied.Prior work cited in the passage focuses on protecting execution against corruption through reactive fault tolerance.
  • D. DRAM in Critical Real-Time Systems: The paper asks whether counter-based RowHammer countermeasures affect, and to what extent they affect, WCET in typical safety-critical workloads.The research question directly targets worst-case execution-time impact.
  • D. DRAM in Critical Real-Time Systems: The system model uses a single-core processor, DRAM protected by counter-based mechanisms such as PRAC-N, and a closed-row memory-controller policy.The processor uses separate instruction and data memories.
  • D. DRAM in Critical Real-Time Systems: The analysis can extend to open-row controllers, where fewer activations may reduce mitigation impact while preserving the fundamental interaction between accesses and countermeasures.The stated extension is qualified as an expectation rather than a measured result.

A. System Setup and Threat Model

The paper models a preemptive fixed-priority real-time system with victim and attacker tasks. The attacker progressively manipulates persistent PRAC counter state across executions to trigger a mitigation cascade before the victim runs.

  • A. System Setup and Threat Model: The task model comprises sporadic tasks with period Pi, WCET C0_i, and deadline Di satisfying Di ≤ Pi.The schedule is preemptive and fixed-priority.
  • A. System Setup and Threat Model: The threat model contains a victim task τ1 and attacker-controlled task τ2, with no shared data or direct communication.The attacker interferes indirectly through the countermeasure’s internal state.
  • A. System Setup and Threat Model: JENGA prepares neighbouring rows with PRAC counters just below TRH, then deliberately triggers an alert to initiate a mitigation cascade before τ1 executes.The resulting DRAM state is intended to maximize τ1’s execution time.
  • A. System Setup and Threat Model: Because counter state persists across preemptions and resumptions, τ2 can extend the JENGA tower over multiple execution intervals.This allows preparation even when τ2 cannot run uninterrupted long enough to build the tower.
  • A. System Setup and Threat Model: Periodic REF commands independently increment PRAC counters and may prematurely collapse the tower, but the model assumes the attacker can compensate by adjusting row accesses.The impact of REF commands is not explicitly modeled.

C. Expected Impact of JENGA

The expected attack impact is bounded by the extra RFM commands that a prepared counter state and the victim’s ACT pattern can trigger. These mitigations add execution time and can also increase the number of periodic refreshes.

  • C. Expected Impact of JENGA: The attack can add mitigation delay by preparing k rows with PRAC counters equal to TRH − 1 before the tower collapses.The analysis bounds the resulting number of additional RFM commands.
  • C. Expected Impact of JENGA: Successive alert bursts require at least N ACT commands between them, so the victim’s nACT commands bound additional RFM activity.Under a strict closed-row policy with cap = 1, nACT = n1.
  • C. Expected Impact of JENGA: The attack-induced execution-time increase is bounded by the number of additional RFM commands multiplied by the worst-case latency tmax_RFM of one RFM command.RFM denotes the mitigation command whose latency contributes directly to the bound.
  • C. Expected Impact of JENGA: The bound conservatively assumes that no ACT command occurs during the 180 ns interval between an ABO alert and the first RFM command.This assumption can overestimate attack impact in practical scenarios.
  • C. Expected Impact of JENGA: Mitigative actions invalidate WCET estimates that omit RowHammer countermeasures, motivating analysis that includes mitigation-induced execution-time delays.The paper frames this as a theoretical analysis of mitigative operations in its system model.
  • C. Expected Impact of JENGA: Periodic refreshes are commonly ignored in WCET analysis because they contribute negligibly to memory latency, but event-driven mitigations are harder to analyze than periodic refreshes.The difficulty comes from determining when mitigation events occur.

B. Protected DRAM WCET

The protected-DRAM WCET analysis adds mitigation and refresh contributions to the baseline WCET. It bounds countermeasure activity using worst-case initial states, task access patterns, command limits, and per-action latency.

  • B. Protected DRAM WCET: The WCET decomposition includes baseline execution, mitigation cost, and refresh cost: WCET = C0 + Cmitig. + CREF.C0 is assumed to be known.
  • B. Protected DRAM WCET: Mitigative RFM actions can increase execution time and thereby trigger additional periodic refreshes, whose stalls are bounded by the program’s maximum nmem memory requests.Refreshes contribute only when they overlap memory requests and stall them.
  • B. Protected DRAM WCET: The proposed methodology determines a worst-case reachable counter state, simulates task execution, counts mitigations, and multiplies their maximum count by single-action worst-case latency.Only states reachable under the system and attacker models are considered for tighter bounds.
  • B. Protected DRAM WCET: For PRAC-N, the worst-case initial state sets all counters to TRH − 1, enabling mitigation cascades.The analysis assumes REF commands do not reduce activation counters.
  • B. Protected DRAM WCET: Total alerts are split into PRACinit from the initial state and PRACpattern from the task’s access pattern with counters initially at zero.This separates pre-existing counter state from alerts genuinely caused by task accesses.
  • B. Protected DRAM WCET: PRACinit is bounded by finite bank rows and the requirement that RFM bursts be separated by at least N ACT commands.Each alert issues N RFM commands, and each RFM resets nRFM counters.
  • B. Protected DRAM WCET: The initial-state bound can use rattacker instead of rbank when memory partitioning limits the attacker’s prepared rows, with rattacker ≤ rbank.rattacker denotes the number of rows the attacker can prepare.

CP RAC

Equations 4, 5, and 11 jointly provide a WCET bound for tasks executing on DRAM protected by PRAC-N.

  • Equations 4, 5, and 11 together provide a WCET bound for tasks executing on DRAM protected by PRAC-N.

VI. EXPERIMENTAL EVALUATION

The evaluation implements the JENGA attack across periodic TACLeBench workloads and measures how manipulating more PRAC-counter rows affects genuine-task execution time.

  • The experiments implement JENGA for three periodic TACLeBench workloads.
  • Execution-time impact is evaluated while varying the number of rows whose PRAC counters the attacker can manipulate.
  • A second experiment evaluates workloads under adversarial initial memory states and compares them with clean initial states.

A. The gem5 Simulator

The study combines gem5 and Ramulator 2.0 with bare-metal execution and TACLeBench workloads to evaluate DRAM-related timing variability and PRAC-aware WCET bounds.

  • A. The gem5 Simulator: gem5 models an in-order RISC-V core connected to local instruction memory and data DRAM backed by Ramulator 2.0.
  • A. The gem5 Simulator: Bare-metal full-system simulation avoids operating-system abstractions, including virtual-memory translation, and provides control over DRAM accesses.
  • C. TACLeBench Workloads: TACLeBench supplies self-contained, processor-independent embedded workloads for evaluating WCET analysis techniques.
  • C. TACLeBench Workloads: MBPTA estimates the attacker-free probabilistic WCET baseline pWCET_0 using block maxima and a fitted Gumbel distribution.
  • C. TACLeBench Workloads: 650 consecutive executions without DRAM-state resets isolate variability from refresh timing and PRAC-counter evolution rather than input-dependent behavior.
  • C. TACLeBench Workloads: The attacker-aware WCET bound is obtained by instantiating the theoretical model with the measured baseline.

VII. RESULTS

Across diverse TACLeBench workloads, adversarial PRAC-counter states substantially increase execution time, while the derived bound safely covers the observed attack times.

  • A. The JENGA Attack - Superloop Setup Results: Across all evaluated workloads, increasing manipulated PRAC-counter rows eventually makes execution time exceed the pWCET computed at confidence level 0.9999.
  • A. The JENGA Attack - Superloop Setup Results: Execution-time growth plateaus when workloads lack enough memory requests to trigger additional RFM commands.
  • A. The JENGA Attack - Superloop Setup Results: For all evaluated workloads, the derived PRAC-and-attacker-budget-aware WCET bound safely exceeds the maximum observed execution time under attack.
  • B. Adversarial Initial Memory State: Adversarial initial memory states systematically trigger more alerts, with the increase proportional to workload memory accesses.
  • B. Adversarial Initial Memory State: 65000 additional alerts saturate for workloads such as dijkstra and anagram when the entire RFM cascade is triggered.
  • B. Adversarial Initial Memory State: Filterbank triggers 4 additional alerts under the adversarial initial state after performing seven memory accesses.
  • B. Adversarial Initial Memory State: Execution-time increases range from nearly 0% to 249% for petrinet across evaluated benchmarks.
  • B. Adversarial Initial Memory State: Mitigation-induced delays substantially increase execution time for the majority of evaluated workloads.

3) Influence of TRH:

Adversarial PRAC states have a larger timing impact at higher TRH values, while several practical constraints complicate but do not eliminate JENGA’s feasibility.

  • 3) Influence of TRH:: Larger TRH values make adversarial memory states substantially more damaging to execution time.At low TRH, clean states already trigger many alerts, narrowing the difference from adversarial states.
  • Feasibility constraints: Counter-state inference requires monitoring memory latency to detect mitigative refreshes and identify when PRAC counters reset.PRAC counters are internal DRAM structures inaccessible directly from software, including the operating system.
  • Feasibility constraints: Subarray boundaries can stop RFM cascades and reduce rattacker below the total rows in a bank, but hundreds to nearly one thousand rows may remain available.The limitation reduces the maximum tower size without completely preventing sufficiently large cascades.
  • Feasibility constraints: Physical-to-DRAM mapping must be known to construct the tower, although prior work has shown that row-buffer conflict side channels can reverse-engineer such mappings.This requirement adds a practical challenge rather than invalidating the attack assumptions.
  • Implication: JENGA remains feasible overall, and stateful counter-based RowHammer defenses can introduce significant timing variations in real-time systems.The findings motivate designing more predictable real-time systems.

B. Mitigative Refresh Granularity and Memory Throttling

JENGA exploits memory-controller behavior and remains relevant under throttling and more complex platforms, while the present WCET analysis is limited to a simple architecture.

  • B. Mitigative Refresh Granularity and Memory Throttling: All-bank RFM commands can stall the entire memory subsystem, allowing an attacker’s tower to affect a victim without sharing its physical DRAM region.This system model follows the DDR5 behavior assumed for ABO alerts.
  • B. Mitigative Refresh Granularity and Memory Throttling: Same-bank RFMsb attacks require the attacker and victim to share the same bank index, even when they occupy different bank groups.The bank-index requirement defines the relevant placement constraint for this command granularity.
  • B. Mitigative Refresh Granularity and Memory Throttling: Memory throttling slows adversarial-state preparation but does not fundamentally prevent the attack.Progressive manipulation across multiple time windows would require tracking memory evolution while the attacker is not executing.
  • C. Complex Architectures: Multi-Core Systems and Memory Hierarchies: The study isolates countermeasure timing effects on a single-core, cacheless system without an operating system.These assumptions remain relevant to some predictability-focused embedded systems but do not cover many modern platforms.
  • C. Complex Architectures: Multi-Core Systems and Memory Hierarchies: Cache hierarchies may absorb accesses before DRAM, requiring practical techniques that ensure accesses reach DRAM.Possible techniques include cache flushing, eviction patterns, or uncached accesses.
  • C. Complex Architectures: Multi-Core Systems and Memory Hierarchies: The current WCET analysis omits complex hierarchy effects; cache hits, pipeline overlap, and out-of-order execution may reduce observable RFM-stall overhead.Extending the analysis could produce tighter and less pessimistic WCET bounds.
  • Implication: Countermeasure-induced timing overheads must be accounted for in WCET analysis, including for PRAC-N on DDR5 memories.The paper derives analytical bounds on mitigative refreshes that may occur during program execution.
  • Implication: Security mechanisms and timing guarantees should be considered jointly because protections may create timing-related attack surfaces.Future work extends the analysis to operating systems, caches, and multicore architectures with additional contention and interference.
Loading 2609.01077v1…