PaperlayerView exact revision on arXiv

Source-linked AI summary

HOMARD: Hammering Off-chip Memory via Aggregate power Rail Disclosure

Eliott Quéré, Li-Chung Chiang, Carina Fiedler, Thomas Rokicki, Maria Méndez Real, Alessandro Palumbo, Lilian Bossuet, Rubén Salvador, Daniel Gruss

arXiv:2610.12621v1cs.CR

TL;DR

Software-based DRAM attacks have mainly relied on timing, but timing methods can fail to resolve mapping and data-dependent behavior. HOMARD reads DRAM activity through unprivileged power telemetry and uses it to recover address mappings and memory data. It recovers full mapping on a multi-chip LPDDR4 system where timing methods fail and leaks bytes from loaded or speculative victim memory blocks.

  • Problem

    Software-based DRAM attacks mainly rely on timing, yet timing signals can be too coarse or noisy to resolve mapping and data-dependent behavior.

    Source: §1 · p. 1, §2.4 · p. 4

  • Method

    HOMARD repeats structural or data-dependent memory stimuli and interprets aggregate rail current to recover DRAM hierarchy mappings or transferred data.

    Source: §1 · p. 2, §4.2 · p. 6, §5.1 · p. 6

  • Results

    HOMARD recovers full DRAM mapping on a multi-chip LPDDR4 system where timing methods fail, using 2.15× fewer address pairs than the state of the art, and recovers 63 of 64 bytes from a memory block.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Unprivileged low-resolution power telemetry can serve as an independent side channel for recovering DRAM hierarchy and data activity, including through speculative execution.

    Source: §8 · p. 14

    Applicability depends on a core-array rail with unprivileged telemetry, whose exposure varies across vendors and platforms.

    Source: §7.2 · p. 13

Abstract

from arXiv · show

Software-based microarchitectural attacks have mainly exploited timing differences to infer information from DRAM. However, defenses and optimizations can prevent timing-based approaches from resolving precise microarchitectural behaviors. We show that unprivileged millisecond- and milliampere-resolution power sensors on modern Arm SoCs can recover DRAM mapping functions and reveal the data dependence of memory accesses without timers. We present HOMARD, a methodology that reads DRAM activity from this telemetry, and two attack primitives. HOMARD-RE is a hierarchy-aware linear-algebraic method that reverse-engineers DRAM addressing functions from power alone. HOMARD-DATA recovers the Hamming weight of a fetched cache line through joint-power rail templating and secret byte values through correlation power analysis on the same rails. Across an AMD ZCU102, a Raspberry Pi 5, and a multi-chip-based LPDDR4 NVIDIA Jetson TX2, HOMARD-RE succeeds where row-buffer timing methods fail. On the Pi 5, HOMARD-DATA classifies 9 Hamming-weight levels at 81.5% accuracy and recovers secret bytes in minutes by correlating rail current with data-dependent bit toggling between neighbors in a row. Both primitives work with an architectural load or a mispredicted Spectre-RSB path on which no value is architecturally read. These results establish unprivileged power telemetry as an independent side channel for profiled microarchitectural attacks, particularly when timing falls silent.

1. Introduction

HOMARD uses unprivileged, low-resolution power telemetry to recover DRAM hierarchy and data activity where timing-based approaches are limited. Its contributions include timer-free mapping recovery, data leakage from DRAM, and a Spectre-RSB attack.

Contributions

  • HOMARD recovers the full DRAM mapping on a multi-chip LPDDR4 system where timing methods fail, using 2.15× fewer address pairs than the state of the art.Its hierarchy-aware method uses a multi-level oracle and nested hierarchy to replace rare collisions with cheaper conditional events.Source: §1 · p. 2, Contributions · p. 2

1. Introduction

  • HOMARD reads DRAM activity through unprivileged, low-resolution power sensors on modern Arm-based platforms.The paper presents this as a software-based power side channel that does not depend on timing measurements.Source: §1 · pp. 1–2

Contributions

  • HOMARD-DATA leaks DRAM memory-block values: 63 of 64 bytes are recovered, including from a victim address space through speculative execution.The attack combines concurrent accesses to secret and attacker-controlled data with correlation power analysis; the direct recovery takes 19 hours, and the speculative version achieves the same accuracy within 18 hours.Source: §1 · p. 2, Contributions · p. 2
  • HOMARD-DATA recovers both a memory block’s Hamming weight and its contents through software-only power analysis.The attack uses current correlated with bit toggling between consecutive memory transfers, then applies correlation power analysis to recover secret bytes.Source: Contributions · p. 2, §1 · p. 2
  • The Spectre-RSB attack uses HOMARD to extract arbitrary victim-space data without requiring a secret-dependent memory-access pattern.The authors state that this broadens the range of vulnerable applications.Source: Contributions · p. 2

2. Background and Related Work

The background describes DRAM’s command and hierarchy structure, prior software power-analysis and address-reverse-engineering work, and limits of row-conflict timing. These limits include noisy, mapping-dependent latency and reliance on fine-grained timers or restricted counters.

2.1. DRAM Fundamentals

  • DRAM organizes channels, ranks, chips, and banks hierarchically; bank operations have some independence but share channel-level resources.An ACT opens a bank row, RD and WR transfer data, and a same-bank access to another row requires PRE before another ACT.Source: §2.1 · pp. 2–3, Figure 1 · p. 3

2.2. Remote Power Analysis in SoC

  • Software-accessible power telemetry has supported power attacks on cryptography and processor-side microarchitectural activity, while DRAM contention on memory-subsystem rails remained largely unexplored.Prior approaches include Intel RAPL-based attacks, Arm userspace rail sensors, and microarchitectural templating with a TDC.Source: §2.2 · p. 3

2.3. Software-Based DRAM Address Reverse Engineering

  • Software DRAM mapping recovery has largely used row-buffer-conflict timing, with methods ranging from brute-force XOR-mask searches to null-space recovery and performance counters.Existing approaches either depend on latency gaps measurable with fine-grained timers or on vendor-specific counters; timing gaps can be small, noisy, coarsened, or absent.Source: §2.3 · p. 3

2.4. Row-Conflict Timing Side Channel Limitations

  • Row-conflict latency classes can reveal address mapping, but the signal is affected by device variation, row history, refresh, controller reordering, and system noise.On Arm, timing reveals only whether addresses collide at the deepest hierarchy level, discarding higher-level contention information.Source: §2.4 · p. 4

3. Threat Model

The attacker is an unprivileged user-space process on a shared SoC, seeking either DRAM mapping information or data-dependent state from memory accesses. The required telemetry and visibility of physical-address bits determine what can be recovered independently.

3. Threat Model

  • The threat model covers unprivileged attackers seeking either DRAM address mappings or data-dependent state from architectural or transient memory accesses.The victim may be another process, including a kernel or cryptographic process, on a commodity multi-user OS.Source: §3 · p. 4

3.1. Online Capabilities

  • The attacker needs chosen-address loads, cache-line eviction, and low-resolution unprivileged power telemetry covering the DRAM subsystem, but no high-resolution timer or physical access.Accessible interfaces may be world-readable or available through a standard non-administrative group, depending on the platform.Source: §3.1 · p. 4

3.2. Physical-Address Visibility and its Consequences

  • Large, aligned, contiguous pages can expose all hierarchy-relevant address bits through virtual addresses; otherwise, userspace can recover hierarchy structure but needs privileged offline translation to label physical levels.The offline profiling result depends on DDR-controller settings and can be reused; the authors state that prior software methods pay the same offline cost.Source: §3.2 · p. 5

4. DRAM Contention Power Side Channel

DRAM commands and data create distinct contributions to rail current, but userspace sees only a heavily averaged signal. HOMARD repeats a stimulus to amplify these contributions, then interprets the resulting mean current for either structural or data-dependent information.

4.1. Physical Mechanism

  • DRAM rail current varies with command density and transferred data: command mix reflects hierarchy contention, while Hamming weight and Hamming distance affect data-dependent current.A same-bank conflict adds PRE and ACT commands; reads also carry linear current terms related to line Hamming weight and toggles between consecutive transfers.Source: §4.1 · p. 5
  • User-visible sensor readings average rail current over conversion windows and multiple conversions, yielding millisecond-scale updates that erase individual command events.The Pi 5 sensor is not publicly documented; experiments suggest it follows the same two-stage sampling and averaging model.Source: §4.1 · p. 5

4.2. The HOMARD Primitive

  • HOMARD repeats a stimulus H for N iterations and reads the mean rail current, using repetition to raise the signal above sensor noise.N is adjusted to the platform’s resolution, sampling rate, noise floor, and target signal-to-noise requirements.Source: §4.2 · pp. 5–6
  • For structural probes, HOMARD flushes and reloads an address pair; the controller’s command stream yields a mean-current class for conflict, shared sub-channel, shared chip, or distinct addresses.PAIR-PROBE applies a lightweight classifier to the measured scalar.Source: §4.2 · p. 6
  • For data probes, a memory access with controlled content makes rail current reveal a line’s Hamming weight or exact bytes; the two attack families share the same loop but vary the stimulus and interpretation.The structural use reads hierarchy levels rather than only a same-bank bit, while the paper reports no counterpart for its data use in prior software-only channels on the studied platforms.Source: §4.2 · p. 6

5. HOMARD-RE: DRAM Hierarchy Recovery

HOMARD-RE infers DRAM hierarchy from aggregate rail current using a multi-level address-pair oracle and staged linear-algebraic recovery. On the Jetson TX2, this approach resolves hierarchy that timing cannot distinguish and reduces recovery measurements.

5.1. Attack Design

  • PAIR-PROBE flushes and loads an address pair, integrates the resulting command-density difference into mean rail current, and classifies the pair into four hierarchy labels.The stimulus fixes the data pattern across probes, making command-density variation the dominant signal source.Source: §5.1 · p. 6

5.2.1. From Binary to Multi-Level Oracles.

  • A multi-level oracle labels the deepest DRAM hierarchy level at which two addresses agree, preserving intermediate equalities that a binary same-bank oracle collapses.Source: §5.2.1 · pp. 6–7

5.2.2. Sequential Recovery.

  • Sequential recovery samples differences within the previously recovered kernel, filters for pairs agreeing through the next level, and solves for the new selectors.The recovered selectors may reuse address bits; only the rank increase at each level matters.Source: §5.2.2 · p. 7

5.2.3. Sample Bound.

  • Hierarchy-aware recovery replaces one rare deepest-level collision with conditional per-level events, and applies to noisy oracles when each level’s classification noise is below one.Its per-stage cost degrades as classification noise increases; the binary oracle is a special case.Source: §5.2.3 · p. 7

5.4. Timing Baseline and Where It Structurally Fails

  • On the ZCU102 and Raspberry Pi 5, power matched timing, with AUC = 1.0 on both and 99.6% blind-deployment accuracy on the Pi 5.The ZCU102 blind deployment reached 100% accuracy.Source: §5.4 · p. 8
  • On the Jetson TX2, power yielded 2.88 bits per pair across four hierarchy levels, while timing yielded 0.11 bits per pair.The power peaks correspond to same bank, same sub-channel, same chip, and distinct chip; TX2 timing pairs did not separate into classifiable populations.Source: §5.4 · p. 8, Figure 3 · p. 9

5.5. Reverse Engineering beyond Timing

  • Power-based null-space recovery found the contiguous 2-bit bank index on the ZCU102 and a 16-bank mapping on the Raspberry Pi 5.Recovery used 20,000 pairs on the ZCU102 and 500 on the Pi 5.Source: §5.5 · p. 8
  • 2.15× fewer measurements completed Jetson TX2 recovery with hierarchy-aware sampling than binary recovery.The procedures completed at NPr=1 after 221 and 476 measurements, respectively.Source: §5.5 · p. 9, Figure 4 · p. 10

6. HOMARD-DATA: DRAM Data Recovery

HOMARD-DATA uses DRAM rail current to estimate a fetched line’s Hamming weight and recover its bytes from data-dependent transitions. It also recovers lines fetched only on a mispredicted speculative path.

6.1. Setup

  • DDR_VDD2_A rises linearly with Hamming weight (R2 = 0.98), while DDR_VDDQ_A folds symmetrically around HW ≈256 under DBI.Source: §6.1 · p. 10

6.2. Shared primitive

  • The shared primitive reads attacker block G then victim V and averages rail response to their Hamming distance; G = 0 exposes weight, while random G supports byte recovery.The two blocks are placed in the same row at adjacent columns to maximize signal-to-noise ratio.Source: §6.2 · p. 10

6.3. Hamming-Weight Recovery

  • At N = 450 traces per line (≈150 s), the joint-rail template estimates Hamming weight across 0–512 with a mean absolute error of 5.1 bits.Source: Figure 6 · p. 11, §6.3 · p. 11
  • The joint two-rail template combines VDDQ’s discrimination with monotonic VDD2 readings to resolve DBI’s fold ambiguity across the weight range.It maps a reading to arc length along a calibrated curve of the two z-scored rail readings.Source: §6.3 · p. 11

6.4. Data Value Recovery

  • At ≈64.5k traces (≈19 h), blind CPA recovers 63/64 bytes at rank 1; the remaining byte is rank 2, leaving a 2-candidate secret.Re-pairing each attacker block with a reading from the wrong trace drops recovery to 0/64.Source: Figure 8 · p. 11, §6.4 · p. 12
  • Random-G transitions expose byte identity because each candidate byte predicts a different Hamming distance; per-byte CPA selects the best-correlated value.For each byte position, CPA compares measured readings with toggle counts predicted by candidate values.Source: §6.4 · p. 11

6.5. Recovery Under Speculative Execution

7. Discussion

The discussion delineates HOMARD’s hardware and placement requirements, reports portability and uncacheable-memory results, and considers its threat model and mitigations.

7.1. Generality of HOMARD-RE

  • HOMARD-RE requires separable current levels for each recovered hierarchy level; bank, sub-channel, and chip were demonstrated, while channels, ranks, and bank groups remain untested.The authors expect rank and bank-group levels to separate, but leave confirmation on multi-rank, bank-grouped DDR4/5 for future work.Source: §7.1 · pp. 12–13

7.2. Applicability of HOMARD-DATA

  • HOMARD-DATA needs an unprivileged core-array rail for full recovery; an I/O-only rail permits Hamming-weight leakage, while no exposed DRAM rail makes the attack inapplicable.Which platforms expose the required rail remains an open question.Source: §7.2 · p. 13

7.3. Portability

  • At 120k traces (≈34 h), the 2 GB Pi 5 recovered 47/64 bytes at rank 1 and the rest at rank ≤5; Hamming-weight recovery got 62/64 within ±1 bit (MAE 0.30 bit).The board’s weaker rail required more traces, but the primitive handled the shifted channel-select bit without manual input.Source: §7.3 · p. 13

7.4. Memory Block Placement Constraint

  • Cross-bank, same-channel placement recovered the secret at ρ ≈0.046 versus ρ ≈0.050 for same-row placement; leakage was γ = 78% across banks versus γ = 56% across rows.Different-channel placement yielded 0/64 recovery because the blocks no longer shared the DQ bus; same-channel placement is the key condition and is easier to satisfy than same-row placement.Source: Table 1 · p. 13, §7.4 · p. 13

7.5. Threat-model realism

  • HOMARD-DATA requires loading the victim line from DRAM; the discussion identifies kernel ioctls and speculative loads through Spectre gadgets as possible routes.Production-kernel Spectre gadgets have been found in prior work,, while their discovery is described as orthogonal to this work.Source: §7.5 · p. 13

7.6. Comparison Against Collide+Power

  • HOMARD-DATA’s DRAM-to-controller leakage can reach uncacheable lines, unlike Collide+Power, which observes transitions inside cache lines and reaches only cacheable data.The uncacheable-line experiment recovered Hamming weight at 85% exact and all 64 bytes at N ≈3.3 × 10^4 traces.Source: §7.6 · p. 13
  • 85% exact template recovery and 64/64-byte CPA recovery at N ≈3.3 × 10^4 traces demonstrate HOMARD-DATA on uncacheable memory.Figure 11 compares the flush-free template attack and CPA; HOMARD reaches uncacheable lines that Collide+Power cannot.Source: §7.6 · p. 13, Figure 11 · p. 14

7.7. Mitigations

  • Revoking unprivileged PMIC-register access removes the software attack path, but privileged, root-level, or physical measurement points retain access to DRAM activity.The passage also notes near-field EM probes and embedded SoC-FPGA circuits as measurement options.Source: §7.7 · p. 14

8. Conclusion

The conclusion presents unprivileged, low-resolution aggregate power sensors as a way to measure DRAM activity on modern Arm SoCs. HOMARD uses that signal for DRAM mapping and data recovery, directly or through a Spectre gadget.

  • Unprivileged low-resolution aggregate power sensors on modern Arm SoCs measure the power signature of DRAM activity.Source: §8 · p. 14
  • HOMARD-RE recovers complete DRAM addressing functions, including on platforms where timing channels fail, and exposes more hierarchy information than state-of-the-art methods.Source: §8 · p. 14
  • HOMARD-DATA recovers a transferred memory block’s Hamming weight or byte values, directly or by leveraging a Spectre gadget.Source: §8 · p. 14

Use of Generative AI.

The authors report using generative AI for editorial and light development purposes, with outputs reviewed for accuracy and coherence.

Appendix A. Recovered Bank-Selection Functions

The appendix lists recovered bank-selection functions using compact notation and specifies how the listed functions form the bank index.

  • The appendix uses compact DRAM-work notation for bank-selection functions.Source: Appendix A · p. 16
  • An entry [i, j] denotes PA[i] ⊕PA[j], while a single [i] denotes the direct selector PA[i].Source: Appendix A · p. 16
  • The bank index concatenates the listed functions in order.Source: Appendix A · p. 16

Appendix B. HOMARD-RE Genericity and Theoretical Applicability

HOMARD-RE applies to DRAM hierarchies with more than one level of agreement, and its per-trace savings grow with hierarchy depth.

Appendix B. HOMARD-RE Genericity and Theoretical Applicability

  • HOMARD-RE supports multi-level recovery for any controller exposing more than one level of agreement, with per-trace savings growing as hierarchy depth increases.Figure 12 projects the method onto the space of addressable DRAM hierarchies.Source: Appendix B · p. 16, Figure 12 · p. 16

Appendix C. Kernel Gadgets

The appendix describes three gadgets that drive a data-dependent G→V transfer and sink the loaded data. They differ in how the transfer reaches DRAM, including a squashed Spectre-RSB path.

Appendix C. Kernel Gadgets

  • All three gadgets drive one G→V bus transfer per iteration and sink the loaded data to defeat dead-code elimination.The reference, uncacheable, and speculative gadgets differ in how the transfer reaches DRAM.Source: Appendix C · p. 16
  • The reference gadget flushes G and V to DRAM and orders the flush so committed loads miss the cache and drive a clean bus transition.It is used for Hamming-weight and value recovery.Source: Appendix C · p. 16
  • The uncacheable gadget omits flushes and barriers; Normal non-cacheable mappings make every load reach DRAM while preserving the same bus transition.The passage identifies this as an alternative to cache maintenance.Source: Appendix C · p. 16
  • The speculative gadget issues G→V only on a mispredicted return path; its linefills complete on the rail even after the burst is squashed.A dependent ALU loop holds the speculation window until the return resolves to the architectural target.Source: Appendix C · pp. 16–17

Ethics Considerations

The authors conducted the experiments in a laboratory using hardware they owned, and the recovered secrets were planted measurement values. They describe coordinated disclosure and recommend an access-control mitigation.

Ethics Considerations

  • Experiments used author-owned hardware in a lab; recovered secrets were planted values, with no third-party users, production services, personal data, credentials, or keys involved.The authors state that no real credential or key was targeted.Source: Ethics Considerations · p. 17
  • The authors notified the national CERT and Raspberry Pi Ltd before publication, with disclosure to other affected vendors proceeding through CERT assistance.They recommend an access-control change that platform vendors and distributions can apply without hardware modification.Source: Ethics Considerations · p. 17
Loading 2610.12621v1…