SecDMP: Provably Secure Data Memory-Dependent Prefetching (Extended Version)

I. INTRODUCTION

• The classification covers architecturally loaded, adjacent cache-block, transient, and prefetcher-loaded data, finds selective disabling misses leakage classes, and formalizes DMP designs as speculative-semantics extensions.The paper reports implementing the first open-source DMPs and proof-of-concept attacks on RISC-V, demonstrating all DMP leakage classes.Source: §I · pp. 1–2
• SecDMP marks secrets in memory and prevents prefetches and state updates based on them, proving no additional leakage beyond a DMP-free baseline; with ProSpeCT, it restores security for constant-time cryptographic code.The paper evaluates SecDMP alone and in combination with ProSpeCT.Source: §I · pp. 1–2
• SecDMP increases chip area by 0.5 %, leaves the critical path unaffected, and incurs 0.36 % average performance overhead and 3.3 % maximum overhead while eliminating secret leakage across benchmark programs.The evaluation implements DMPs modeled on commercial designs and academic proposals on the Proteus RISC-V CPU.Source: §I · p. 2

A. Microarchitectural Side-Channel Attacks; 1) Constant-time programming:

• Microarchitectural attacks exploit secret-dependent effects on shared hardware, while constant-time programming requires memory accesses, control flow, and variable-latency operands to be secret-independent.Attack examples include cache, TLB, page-walk, and shared-interconnect attacks; prior work also shows cross-CPU leakage and recovery of fine-grained address bits.Source: A. Microarchitectural Side-Channel… · p. 2, 1) Constant-time programming · p. 2

2) Spectre:; 3) Spectre defenses:

• Spectre exploits persistent microarchitectural effects of transient instructions after misprediction; speculative constant-time extends protection to transient execution, and marked-data hardware defenses can protect secrets while preserving public-data performance.Enforcing speculative constant-time purely in software is extremely challenging.Source: 2) Spectre · p. 2, 3) Spectre defenses · p. 2

B. Hardware Prefetchers

• Hardware prefetchers reduce memory latency by bringing predicted data into cache; classical prefetchers use accessed-address history, whereas DMPs also use loaded data and are present in Apple, Intel, and Arm processors,,,,.DMPs can identify irregular patterns, such as pointer dereferences, that classical prefetchers may miss.Source: B. Hardware Prefetchers · pp. 2–3

1) Address heuristics:; 2) Recursion and chain prefetching:

• DMPs can use pointer heuristics to identify valid targets,, recursively scan their own prefetched data, or scan data prefetched by other prefetchers, a behavior termed chain prefetching.Recursive prefetching can traverse linked data structures ahead of time.Source: 1) Address heuristics · p. 3, 2) Recursion and chain prefetching · p. 3

3) Activation patterns:

• Some DMPs train on a specific memory-access pattern before prefetching ahead in it; the Intel DMP can traverse pointer arrays by prefetching ahead, reading returned pointers, and fetching their targets.Such pattern-triggered DMPs are often recursive because they read ahead to derive the next target.Source: 3) Activation patterns · p. 3

C. Security Risks of DMPs

• DMPs can leak scanned secrets through ordinary load-address side channels or internal-state attacks; prior work progressed from IMP out-of-bounds reads, to Apple and Intel attacks,,.GoFetch demonstrated secret-key leakage from constant-time code, while Peeka-Walk showed attacker-chosen address leakage under constraints, including inability to train the Intel DMP across processes.Source: C. Security Risks of DMPs · p. 3

III. THREAT MODEL

• The attacker may monitor microarchitectural side channels, including speculative-execution channels, from several execution contexts; protection is measured against a baseline with DMPs disabled.Full microarchitectural security additionally requires complementary software or hardware defenses against other leakage.Source: §III · p. 3

IV. CLASSIFICATION OF DMP LEAKAGE

• The paper classifies leakage by the data DMPs scan, categorizes existing attacks, devises new techniques, and finds selective disabling fails to mitigate all leakage classes.Its analysis covers commercial Apple and Intel designs and two academic designs, with empirical demonstrations on a RISC-V processor.Source: §IV · p. 3, A. DMP Leakage Classes · p. 4

A. DMP Leakage Classes; 1) Architecturally accessed data (Arch); 2) Indirectly accessed data (Ind):

• Arch leakage arises when DMPs scan architecturally accessed data, while Ind leakage covers data the program never architecturally accesses.The Ind subclasses are adjacent sub-cache-block data (Sub), data from transient loads (Trans), and prefetched data (Pref), reached through recursion or chain prefetching. Distinguishing transient from non-transient loads would require complex hardware and reduce performance.Source: A. DMP Leakage Classes · p. 4, 1) Architecturally accessed data (Arch) · p. 4, 2) Indirectly accessed data (Ind) · p. 4

B. DMP Designs and Classification; 1) Apple DMP; 2) Intel DMP

• The Apple DMP scans L1-loaded blocks, including transient loads, leaking through Arch, Sub, and Trans; the Intel DMP’s pointer-array training leaks through Arch and recursively prefetched data through Pref.Apple checks candidate pointers against the current block address; Intel learns array stride from load-PC bits and constrains prefetches to a 256 KiB region and user memory. Intel Trans leakage is presumed, not confirmed.Source: 1) Apple DMP · p. 4, 2) Intel DMP · p. 4

3) CDP; 4) IMP

• CDP scans load- and prefetch-request blocks, leaking through Arch, Sub, Pref, and Trans; IMP’s recursive pattern leaks through Arch, Pref, and Trans.CDP uses configurable pointer matching, next-line prefetching, and recursion depth; IMP has two- and three-level variants and no pointer heuristic.Source: 3) CDP · p. 4

C. Exploiting Leakage Classes

• The authors extended Proteus RISC-V with models of Apple, Intel, CDP, and IMP DMPs and crafted programs to demonstrate leakage classes and attacks in practice.Table II identifies the leakage classes targeted by each test program; the supplied passage does not provide individual test results.Source: C. Exploiting Leakage Classes · p. 5, Table II · p. 5

1) Classification of existing attacks:

• Existing attacks expose Pref leakage through out-of-bounds or attacker-triggered scans, while GoFetch leaks through Arch when a secret resembles a valid pointer,,,,.Recursive pattern-activated DMPs can use out-of-bounds data to derive further prefetch targets; Peek-a-Walk induces scanning at an attacker-influenced address.Source: 1) Classification of existing attacks · p. 5

2) Novel attacks exploiting leakage classes:

• DMP-Spectre replaces Spectre’s follow-up instruction with DMP scanning, while recursive and chained prefetching can make secrets loaded from attacker-controlled input or by a mistrained prefetcher leak.The attacks exploit Trans leakage via transient secret loads and Pref leakage via recursive or chained prefetching.Source: 2) Novel attacks exploiting leakage… · p. 5

3) General tests:

• General tests isolate Arch, Sub, and Trans leakage using a secret load, public data sharing a cache block with a secret, and a transient secret load, respectively.Co-location can occur naturally when compilers reuse stack space after secrets become unused.Source: 3) General tests · p. 5

D. Proposed DMP Mitigations; 1) Permanent disabling:; 2) Selective disabling:; E. Classification of DMP Mitigations

• Permanent DMP disabling mitigates all DMP leakage but loses performance benefits; selective disabling protects Arch leakage in security-critical regions but leaves indirect leakage possible in public code,.Permanent disabling can penalize programs whose security-critical code is only a small region; selective disabling cannot safely leave DMPs enabled while secrets remain accessible in memory.Source: 1) Permanent disabling · pp. 5–6, 2) Selective disabling · p. 6, E. Classification of DMP Mitigations · p. 6

3) Preventing secret extraction:; 4) Interleaving:

• Flushing prefetcher state may not secure all channels and can fail against intra-process or concurrent monitoring, while interleaving secrets incurs 274% overhead and applies only to pointer-heuristic DMPs,,.Interleaving must be adapted to each DMP’s heuristic; permanent disabling therefore remains the focus of the mitigation analysis.Source: 3) Preventing secret extraction · p. 6, 4) Interleaving · p. 6, E. Classification of DMP Mitigations · p. 6

E. Classification of DMP Mitigations

• The analysis identifies a defense gap: selective disabling leaves indirect leakage avenues, while permanent disabling sacrifices DMP performance, forcing users to trade security for performance.Attackers can deliberately induce Trans and Pref leakage in public regions, and Sub leakage can arise when public and secret data are mixed.Source: E. Classification of DMP Mitigations · p. 6

V. OVERVIEW OF SECDMP; A. Software Changes

• SecDMP marks secret data in software and blocks only prefetches depending on secrets, preserving public-data prefetches; its proof assumes a static memory partition with correctly labeled secrets.The partitioning method may vary if labeling is correct; the proof relies on static partitioning, implemented with coarse-grained static secret regions.Source: §V · p. 6, A. Software Changes · p. 6

B. Hardware Changes

• Hardware SecDMP uses a taint bit to identify secret data and modifies the DMP to ignore tagged data, without requiring secrets to be tracked throughout the core.These local, lightweight changes prevent secret data from entering DMP state or initiating prefetches; dynamic secret tracking is optional.Source: B. Hardware Changes · p. 6

C. Security of SecDMP

• For a static secret partitioning, SecDMP closes all DMP leakage channels for marked data and provides the same security guarantees as a baseline without a DMP.The property is formally proved in Theorems 1 and 2.Source: C. Security of SecDMP · p. 7
• SecDMP must be combined with defenses against other side channels and Spectre; with speculative constant-time defenses, it closes the additional DMP channel and restores their security guarantees.The paper says that programs secure in the baseline without a DMP remain secure with a SecDMP-secured DMP, and describes combinations with hardware- and software-based Spectre defenses.Source: C. Security of SecDMP · p. 7

VI. FORMALIZATION OF DMPS AND SECDMP

• The formalization defines a baseline out-of-order semantics, extends it to model DMP behavior, and formalizes SecDMP as an extension of an arbitrary base semantics.These are the three semantics introduced in Sections VI-A, VI-B, and VI-C.Source: §VI · p. 7

1) Language: / 2) Configurations:

• The assembly ISA includes register-memory moves, jumps, and conditional branches; configurations pair memory and register maps with a reorder buffer and observable microarchitectural state.Direct assignments to the program counter are disallowed.Source: 1) Language · p. 7, 2) Configurations · p. 7

3) Attacker strategies: / 4) Leakage model:

• Attacker strategies choose the initial microarchitectural state and execution functions, while the baseline leakage model exposes fetched and executed program counters and addresses accessed by speculative loads and stores.Source: 3) Attacker strategies · p. 7, 4) Leakage model · p. 7

5) Semantics:

• The deterministic baseline models direct and indirect control-flow speculation (Spectre-v1 and Spectre-v2), but interaction with memory disambiguation and load value or address prediction is unknown.Source: 5) Semantics · p. 7

B. DMP Extensions ({|·|}DMP and {|·|}B+DMP)

• DMP semantics parameterize training and prefetching over state, instruction location, memory, and loaded address; the generalized model adds base-defined PC, address, and activation functions.The DMP functions can be instantiated for different implementations, and their access to the whole memory permits recursive prefetching based on loaded values.Source: B. DMP Extensions ({|·|}DMP and… · pp. 7–8, 1) Modeling existing implementations · p. 8

1) Modeling existing implementations

• The Apple DMP model captures Arch, Sub, and speculative-load Trans leakage, but not Pref leakage because its mechanism is unknown.It models no training phase: Apple's pointer heuristic checks words in the loaded cache block, dereferences passing candidates, and prefetches the following cache block; the paper also presents models of Intel DMP, CDP, and IMP in an appendix.Source: 1) Modeling existing implementations · p. 8

1) Memory partitioning:

• SecDMP assumes a fixed memory partition between public and secret data; storing a secret to a public address declassifies and leaks its value, but never speculatively.Source: 1) Memory partitioning · p. 8

2) Securing existing DMPs with

• For the Apple DMP, SecDMP checks whether each analyzed address is public and only then applies the existing pointer heuristic and prefetches its target.Secret addresses are not analyzed; secure models of the Intel DMP, CDP, and IMP are described in Appendix A.Source: 2) Securing existing DMPs with · p. 9

3) Generalization:

• SecDMP generalizes to any DMP by restricting training and prefetching to public memory, while still allowing use of the entire public region.The abstract {|·|}SECDMP model captures individual DMP designs; {|·|}B+SECDMP applies the restriction to an arbitrary hardware semantics B.Source: 3) Generalization · p. 9

VII. SECURITY THEOREMS AND PROOFS

• SecDMP instantiations do not leak more than the baseline semantics they extend already leaks or declassifies.Source: §VII · p. 9

1) Public equivalence:

• Two configurations are public-equivalent when they agree on the program counter, public memory, and public registers.The partition covers both memory addresses and registers.Source: 1) Public equivalence · p. 9

2) Microarchitectural security:

• A program leaks when an attacker can produce distinct observations from two public-equivalent initial configurations; it is secure when no such pair leaks.Source: 2) Microarchitectural security · p. 9

3) Comparing the security of hardware semantics:

• The semantics comparison relation means an optimized semantics leaks no secret information not already leaked by the baseline.If the optimized semantics is at least as secure as the baseline, every program secure on the baseline is also secure on the optimized semantics.Source: 3) Comparing the security of hardware… · p. 9

1) Security of {|·|}SECDMP:

• SECDMP’s speculative semantics leaks no more than the baseline: any divergence it causes reflects information already leaked through program counters, accessed addresses, or public memory.The proof matches architectural state and reorder buffers at each step while restricting training and prefetching to the public projection.Source: 1) Security of {|·|}SECDMP · pp. 9–10

2) Instantiating SecDMP implementations:

• The proposed SECDMP implementations satisfy the formal semantics because they use only public memory for training and prefetching, so they are as secure as baseline speculative semantics.This follows directly from Theorem 1.Source: 2) Instantiating SecDMP implementations · p. 10

C. Generalization

• The proof generalizes to any baseline B satisfying natural assumptions, showing that adding SECDMP is at least as secure as B.The assumptions constrain how microarchitectural state is updated and observed, and require a constant-time leakage model that exposes program counters, accessed addresses, and public-memory writes.Source: C. Generalization · p. 10

2) Security of {|·|}B+SECDMP:

• Under assumptions A1–A3, adding SECDMP to a baseline speculative semantics does not increase leakage relative to that baseline.A1 routes microarchitectural updates through update; A2 requires predict or next to encode microarchitectural information into architectural state or the reorder buffer; A3 exposes at least program counters and accessed addresses and declassifies writes to public memory.Source: 2) Security of {|·|}B+SECDMP · p. 10, 1) Assumptions over {|·|}B · p. 10

3) Instantiation with sequential CT:

• With sequential constant-time semantics as the baseline, adding SECDMP leaks no more than sequential execution that exposes program counters, accessed addresses, and public-memory writes.The sequential semantics satisfies assumptions A1–A3.Source: 3) Instantiation with sequential CT · p. 10

4) Instantiation with ProSpeCT:

• Combined with ProSpeCT, SECDMP does not leak more than sequential constant-time semantics, providing guarantees against speculative-execution and DMP attacks on constant-time programs.ProSpeCT satisfies the assumptions of the generalized theorem and is itself at least as secure as sequential constant-time semantics.Source: 4) Instantiation with ProSpeCT · p. 10

VIII. IMPLEMENTATION AND EVALUATION

• The implementation and evaluation section assesses SECDMP, permanent disabling, and selective disabling for security, performance, and hardware cost.It also evaluates combining SECDMP with ProSpeCT to measure the cost of integrating it into existing Spectre defenses that use secret partitioning.Source: §VIII · p. 10

A. Implementation; 1) Proteus+DMP:

• The Proteus RISC-V implementation provides four open-source DMP baselines modeled on prior designs, including IMP’s default A[B[i]] variant and recommended CDP and IMP parameters.The Apple DMP’s unknown Pref mechanism was not modeled, so its implementation and CDP are similar except that CDP is recursive.Source: A. Implementation · p. 10, 1) Proteus+DMP · p. 11

2) Permanent and selective disabling:

• Permanent disabling uses Proteus without a DMP, while selective disabling adds a software-toggle CSR and requires a fence after each CSR write.The fence prevents instructions from executing speculatively with incorrect CSR values.Source: 2) Permanent and selective disabling · p. 11

3) SecDMP:

• SecDMP partitions memory into public and secret regions and prevents DMP scanning of marked secret data, using CSRs configured at program start and unchanged thereafter.Only the DMP distinguishes public from secret data; the processor pipeline requires no secret tracking.Source: 3) SecDMP · p. 11

4) ProSpeCT+SecDMP:

• The ProSpeCT+SecDMP prototype is implemented by adding the SecDMP extension to the upstream ProSpeCT implementation.Source: 4) ProSpeCT+SecDMP · p. 11

B. Evaluation:

• Evaluation runs each prototype against all four DMPs in Verilator simulations using a configured Proteus RISC-V processor.The configuration includes a 4-way 16set cache, a 64-cycle miss penalty, a 32-entry reorder buffer, 8 arithmetic units, 3 load units, and 2 multiplication/division units.Source: B. Evaluation · p. 11

1) Security:

• SecDMP prevents all DMP secret leakage, and ProSpeCT+SecDMP prevents all leakage from both Spectre-PHT and DMPs.Permanent disabling prevents all tested leakage, while selective disabling prevents only architectural leakage; ProSpeCT alone still leaks secrets architecturally loaded before speculative accesses.Source: Table IV · p. 11, 1) Security · p. 11

2) Performance:

• On HACL* cryptographic benchmarks, permanent disabling’s highest overhead is 2.9% on Salsa20 for Apple DMP and CDP, while partitioning costs −0.9% to +4.8% (average +1.15%).Selective disabling matches permanent disabling on cryptographic functions; SecDMP and ProSpeCT add no cost beyond partitioning.Source: Figure 5 · p. 12, 2) Performance · p. 12
• On DMP-Bench, SecDMP averages 0.36% overhead (maximum 3.3% at 25% work) and leaves public-work performance unaffected, unlike permanent disabling’s 59.9% maximum at 90% work.SecDMP’s overhead comes solely from secret partitioning; it does not hinder prefetching on public data. The reported maxima are 3.3% on CoreMark-Salsa20 for CDP and 59.9% on AoP-Salsa20 for the Intel DMP.Source: Figure 7 · p. 13, 2) Performance · p. 13

3) Hardware cost:

• 12.43 ns is the critical path across all prototypes; area overhead is 29.7% for IMP, 2.0% for Apple DMP, 5.1% for Intel DMP, and 2.7% for CDP.Selective disabling adds at most 0.2% area and SecDMP at most 0.5%; ProSpeCT alone reaches 2.4% for the Apple DMP, while adding SecDMP to ProSpeCT increases area by at most 0.3%.Source: 3) Hardware cost · p. 13

A. Practicality of Secret Partitioning

• Coarse-grained static partitioning makes heap allocation and stack-resident secrets practical challenges, but these stem from the partitioning method rather than SecDMP itself.A public/secret heap split can distinguish allocations through annotations or a secure allocation function,; stack partitioning may require marking the whole stack secret, and compiler spills remain a concern,,. SecSep tracks secrets and rewrites stack data, and could be integrated into compilers,,.Source: A. Practicality of Secret Partitioning · p. 13

B. Marking Secrets

• Requiring software to mark secrets in memory enables a security/performance trade-off and could also secure memory optimizations such as silent store suppression.For silent store suppression, writes to addresses holding secret data could simply never be suppressed,.Source: B. Marking Secrets · p. 13

C. Relation to ProSpeCT

• ProSpeCT protects constant-time programs against speculative leakage but not DMP leakage; SecDMP reuses secrecy tracking to address that gap and formally covers arbitrary baselines.The combined SecDMP and ProSpeCT defense mitigates both leakage channels. SecDMP requires taint tracking in memory and the DMP, unlike ProSpeCT’s precise pipeline taint tracking.Source: C. Relation to ProSpeCT · p. 14

D. Reverse-Engineering of Commercial DMPs

• Commercial DMP models reflect imperfect reverse engineering, but SecDMP’s proofs rely on an abstract DMP model intended to capture commercial designs.The Apple DMP’s Pref leakage mechanisms are unknown, and it is unclear whether Intel’s DMP leaks during speculation; reverse-engineering Arm’s potentially recursive DMP and model-based testing are proposed next steps.Source: D. Reverse-Engineering of Commercial… · p. 14

E. Secure Selective Disabling

• Secure selective disabling requires removing all secrets from memory before re-enabling DMPs, since public code can trigger scans of secrets.Unmapping secret data when leaving security-critical regions can secure selective disabling across leakage classes, but may cause significant performance overhead.Source: E. Secure Selective Disabling · p. 14

7: return µ

• SecDMP requires secrets to be tagged in memory, prevents DMP leakage across designs, and preserves prefetching performance for public data; the supplied “7: return µ” excerpt contains only a prefetch function signature.The paper also presents a leakage classification and open-source DMP implementations for future research.Source: §X · p. 14, §7 · p. 16

ETHICS CONSIDERATIONS

• The work demonstrates attacks only on the Proteus research core, not production systems, and reports notifying Intel about ambiguity in DOIT-bit documentation.The notification followed the first concrete demonstration that selective disabling does not prevent all DMP leakage.Source: ETHICS CONSIDERATIONS · p. 14

1) Insecure model:

• Intel DMP training detects array-of-pointers patterns by relating loaded values to later load addresses, leaking through the Arch class and learning an instruction-specific stride.The model also remembers the triggering instruction location to derive the stride.Source: 1) Insecure model · p. 16
• After learning a stride, Intel DMP prefetches and dereferences a candidate pointer that passes its heuristic, leaking data ahead through the Pref class.The heuristic requires the upper 17 bits to be zero, or with LAM enabled checks bits 63 and 47; this restricts prefetching to user memory.Source: 1) Insecure model · pp. 16–17

2) Applying SecDMP:

• SecDMP modifies Intel DMP training and prefetching so the DMP neither trains on nor dereferences secrets.The modifications are depicted in Figure 8.Source: 2) Applying SecDMP · p. 17

1) Insecure model:

• CDP’s recursive model scans each loaded cache block for pointers, prefetches matching targets and adjacent blocks, and recurses, capturing Arch, Sub, Trans, and Pref leakage [19].Recursion stops when it exceeds maxRecursionDepth.Source: 1) Insecure model · p. 17

2) Applying SecDMP:

• SecDMP secures CDP by scanning only public data and proceeding with prefetching only when the address holds public data.The model checks this condition before the prefetch operation.Source: 2) Applying SecDMP · p. 17

1) Insecure model:

• IMP detects indirect array patterns by correlating non-stride loads with earlier index-array accesses; pattern registration and confidence updates leak through the Arch class.It tests candidate bases across several shifts because the indirect array’s element size is unknown.Source: 1) Insecure model · p. 17

2) Applying SecDMP:

• IMP activates on sufficiently confident index-array patterns and prefetches a computed indirect target, capturing Pref and Trans leakage; SecDMP prevents analyzing secrets or deriving targets from them.Activation uses the index-load program counter and a learned indirect pattern.Source: 1) Insecure model · p. 18, 2) Applying SecDMP · p. 18

A. Baseline Speculative Semantics

• The baseline semantics models out-of-order execution with direct and indirect control-flow speculation, building on prior microarchitectural semantics,.Expression evaluation is undefined when a required register value is undefined.Source: A. Baseline Speculative Semantics · p. 18

B. Semantics of SecDMP

• SecDMP semantics matches baseline speculative semantics except for modifications to EXECUTE-LOAD.Figure 17 presents evaluation rules for EXECUTE-LOAD in the SecDMP semantics.Source: B. Semantics of SecDMP · p. 20, Figure 17 · p. 20
• Figure 17 gives the evaluation rules for EXECUTE-LOAD in the SecDMP semantics.Source: Figure 17 · p. 20

A. Definitions and Notations

• Proof notation uses SDMP as shorthand for SecDMP semantics and β[0..i] for the first i + 1 instructions in a reorder buffer.Source: A. Definitions and Notations · p. 20
• Two configurations are π-equivalent when their program counters match, low-security registers match, and their public memories match.Source: A. Definitions and Notations · p. 20
• Strong public equivalence requires matching program counters in register maps and across every reorder-buffer prefix.Source: A. Definitions and Notations · p. 20
• Strong public equivalence also requires equal low-security memory and identical microarchitectural states.Source: A. Definitions and Notations · p. 20

B. Proof of Theorem 1

• Assuming a maximally leaking update function does not restrict the proof, because any divergence produced by an update function is also captured by such a function.The proof treats the update function as leaking all its arguments to the microarchitectural state.Source: B. Proof of Theorem 1 · pp. 20–21
• The induction constructs a baseline attacker that matches SecDMP’s architectural states and reorder buffers while preserving divergence and strong public equivalence.At each step, the proof matches directives and shows that differences in load behavior affect microarchitectural context rather than architectural state or the reorder buffer.Source: B. Proof of Theorem 1 · p. 21
• The induction proves every SecDMP microarchitectural divergence can be reproduced at the same step in the baseline semantics, completing the proof.The proof concludes that a divergence at step n + 1 in SecDMP also occurs at step n + 1 in the baseline.Source: B. Proof of Theorem 1 · p. 22

C. Proof of Theorem 2

• The proof relies on A2, which prevents information from microarchitectural state entering architectural state or the reorder buffer except through prediction or next directives.A3 additionally assumes the base semantics satisfies a constant-time leakage model with declassification to public memory.Source: C. Proof of Theorem 2 · pp. 22–23
• DMP-ACTIVATE changes only microarchitectural state, leaving architectural state and the reorder buffer unchanged relative to the base semantics.The proof uses this property, alongside matching predictions and directives, to preserve architectural-state and reorder-buffer agreement.Source: C. Proof of Theorem 2 · pp. 23–24
• Theorem 2 states that, for a base speculative semantics satisfying A1–A3, {|·|}B+SECDMP ⊒ {|·|}B.The proof aims to reproduce in the base semantics any attacker-induced divergence from the same pair of publicly equivalent initial configurations.Source: C. Proof of Theorem 2 · p. 23
• The induction constructs a base-semantics attacker that matches architectural states and reorder buffers while preserving microarchitectural divergence at each step.The proof also tracks equal public memory before divergence.Source: C. Proof of Theorem 2 · p. 23

• B denotes the microarchitectural states produced by the {|·|}B step.Source: B and µ′B+SDMP · p. 24

D and µ′B+SDMP

• For DMP-ACTIVATE, a divergence requires a difference in the base-step result, training result, prefetching result, or loaded address.The proof separates a base-step difference from differences in the training result, prefetching result, or loaded address.Source: D and µ′B+SDMP · p. 24
• Differences in training, prefetching, or the loaded address imply a difference in get pc or get addr, which A3 rules out in this case.Therefore, this case cannot produce a divergence.Source: D and µ′B+SDMP · p. 24
• Thus any DMP-ACTIVATE divergence must already be reflected by the base step, allowing an attacker strategy that also produces divergence under B.The proof extends this implication to each rule to establish (IH2) at step i+1.Source: D and µ′B+SDMP · p. 24
• Equal incoming microarchitectural states and equal current locations make next and dmp activate select the same directive and DMP rule in both executions.The induction assumption (IH3) is applied at step i.Source: D and µ′B+SDMP · pp. 24–25

B and µ′B+SDMP

• Because DMP rules preserve the base step’s memory, any public-memory difference must arise in that step; A3 then rules it out when the resulting microarchitectural states are equal.This establishes (IH3), which the proof maintains for all steps.Source: B and µ′B+SDMP · p. 25
• Any microarchitectural divergence at step n+1 under B+SDMP also occurs at step n+1 under B, completing the proof via (IH2).The proof establishes (IH1)–(IH3) for all steps, then applies (IH2) to obtain the result.Source: D and µ′B+SDMP · p. 24, B and µ′B+SDMP · p. 25

APPENDIX D EVALUATION RESULTS

• The performance evaluation reports HACL* cryptographic, work-benchmark, and DMP-Bench results relative to the corresponding Proteus+DMP baseline.Work benchmarks include Sglib, CoreMark, Array-of-Pointers, and SpMV; DMP-Bench results cover the Apple DMP, Intel DMP, CDP, and IMP.Source: A. HACL* Cryptographic Benchmarks · p. 25, B. Work Benchmarks · p. 25, C. DMP-Bench · p. 25

APPENDIX E ARTIFACT APPENDIX

• The artifact provides the Proteus RISC-V processor, four open-source DMP implementations, SecDMP and comparison defenses, benchmarks, evaluation scripts, and a Docker build environment.Its benchmarks include nine DMP leakage programs, five Spectre-PHT tests, five HACL* primitives, Embench, CoreMark, SpMV, AoP, and DMP-Bench.Source: Appendix E · p. 25, 4) Benchmarks · p. 25, 3) Software dependencies · p. 25

B. Artifact Installation & Configuration

• Artifact setup requires Docker and about 20 GB of disk space; building processor prototypes and compiling benchmarks takes about 75 compute-minutes.The evaluation can be run experiment by experiment or with one script, and running all experiments takes around 17 compute-hours; deterministic simulation outputs match the provided expected results, while hardware numbers fluctuate negligibly.Source: 3) Software dependencies · p. 25, B. Artifact Installation & Configuration · pp. 25–26, D. Evaluation · p. 26

C. Major Claims

• SecDMP mitigates all DMP secret leakage, whereas selective disabling prevents only architectural DMP leakage; together with ProSpeCT, it prevents both Spectre-PHT and DMP leakage.The claim is supported by E1 and reported in Table IV, Section VIII-B1.Source: C. Major Claims · p. 26
• Permanently disabling DMPs causes up to 66.4% overhead on work benchmarks and 59.9% on DMP-Bench, while SecDMP and selective disabling preserve DMP performance.SecDMP’s overhead comes solely from secret partitioning: at most 4.8% and an average of 1.15% on cryptographic benchmarks.Source: C. Major Claims · p. 26

5) Experiment (E5):

• SecDMP increases hardware area by at most 0.5%, leaves the critical path unchanged at 12.43 ns, and adds 0.3% area when combined with ProSpeCT.Selective disabling increases area by 0.2%; the hardware evaluation’s area numbers can fluctuate negligibly at the 10^-4 mm^2 level between runs.Source: C. Major Claims · p. 26, 5) Experiment (E5) · p. 26

1) Experiment (E1):

• E1 verifies non-interference across programs and prototypes, checking attacker-observable signals and internal DMP signals for leakage tests.Its results mark each program as secure or leaking per DMP and prototype, corresponding to Table IV.Source: 1) Experiment (E1) · p. 26

2) Experiment (E2):

• E2 measures five HACL* primitives and checks secret annotations; E3 measures work benchmarks, E4 measures DMP-Bench combinations, and E5 synthesizes prototypes for area and critical path.E2 results report cycle counts and relative overheads; E3 and E4 support performance claims, while E5 supports the hardware-cost claim.Source: 2) Experiment (E2) · p. 26, 3) Experiment (E3) · p. 26, 4) Experiment (E4) · p. 26