PaperlayerView exact revision on arXiv

Source-linked AI summary

DualGuard: Comprehensive and Efficient Memory Safety across Sequential and Speculative Execution

Sixuan Dang, Quan Zhou, Kaiming Huang, Jianan Zhu, Anitha Gollamudi, Trent Jaeger, Danfeng Zhang

arXiv:2610.39374v1cs.CRcs.PL

TL;DR

Sequential and speculative defenses can leave gaps when composed naively, while also adding overhead. DualGuard formalizes and selectively combines protections; it reports 3%–72% lower overhead than naive compositions, with lower overhead in some cases than single-mode approaches.

  • Problem

    Naively combining sequential and speculative defenses may fail to provide dual safety and can impose prohibitive overhead.

    Source: A. Composition Theorem · p. 7

  • Method

    DualGuard formalizes safety-preserving composition and selectively applies mechanisms to violation classes to avoid redundant checks.

    Source: §I · p. 2

  • Results

    3%–72% lower overhead than naive compositions; in some cases, DUALGUARD also costs less than approaches protecting only sequential or speculative execution.

    Source: §I · p. 2

  • Takeaways & Limitations

    The unified approach removes redundant protections while preserving dual memory safety.

    Source: §I · p. 2, §IX · p. 14

    The work is scoped to spatial dual safety under Spectre v1; broader threat models are future work.

    Source: §VIII · p. 14

Abstract

from arXiv · show

Although decades of research have yielded sophisticated mechanisms for enforcing memory safety, speculative execution can subvert these protections through transient memory operations. Conversely, defenses designed specifically for speculative safety, such as Speculative Load Hardening (SLH), cannot enforce memory safety during non-speculative execution. A naive combination of defenses from both domains raises two fundamental challenges: (1) which combination of otherwise fragmented defenses can ensure dual memory safety under speculative and non-speculative executions? (2) whether such combinations introduce redundant protections that incur unnecessary performance overhead? We present DualGuard, a unified framework for dual memory protection under non-speculative and speculative executions. DualGuard systematically analyzes memory behaviors, classifying them into four categories, and further identifies the minimal composition requirements for dual memory safety, which allow us to strategically combine existing mitigations and design new ones to avoid redundant or excessive protections. We implement DualGuard through a combination of static analysis and runtime enforcement within the LLVM infrastructure. Our evaluation demonstrates that DualGuard reduces overhead by 3%-72% compared to naive compositions of fragmented defenses. In some cases, it even incurs lower overhead than approaches that guarantee memory safety solely under either non-speculative or speculative execution.

I. INTRODUCTION

The introduction frames a gap between sequential and speculative defenses: naive composition may fail to provide dual safety while adding overhead. DualGuard formalizes their interaction, analyzes existing mechanisms, and selectively combines protections; its evaluation reports lower overhead than naive compositions.

I. INTRODUCTION

  • Prior work often assumes sequential and speculative defenses can be directly composed, but naive combinations may fail to provide dual safety and add overhead.The paper frames two questions: which combinations ensure dual safety, and how to avoid redundant protections.Source: §I · pp. 1–2
  • The formal framework associates program locations with violation regions and classifies their accesses as sequential-only, speculative-only, or both.This classification isolates minimal conditions needed to prevent each class of error.Source: §I · p. 2
  • A sound mechanism applied after another sound mechanism guarantees dual safety when it preserves safety in the opposite execution mode.The paper defines safety preservation as not introducing new violations in the other mode.Source: §I · p. 2
  • When both mechanisms are sound and safety-preserving, the corresponding mechanism can be omitted at locations initially free of its violations.This selective composition preserves dual safety while avoiding unnecessary protections.Source: §I · p. 2
  • SafeStack and SLH are safety-preserving, while Baggy and Delta Pointers are not; the paper also proves DUALBAGGY and DUALDELTAPOINTERS dual-safe individually.Baggy and Delta Pointers are unsafe after speculative defenses; the paper analyzes mechanisms including SpecASan and CHERI as well.Source: §I · p. 2
  • 3%–72% lower overhead than naive compositions; in some cases, DUALGUARD also costs less than approaches protecting only sequential or speculative execution.The introduction reports this comparison for standard security and performance benchmarks and real-world cryptographic libraries.Source: §I · p. 2

A. Memory Safety

  • The paper focuses on spatial memory safety, leaving temporal errors such as use-after-free for future work.Spatial mechanisms address illegal pointer dereferences during non-speculative execution.Source: A. Memory Safety · p. 3, C. Threat Model · p. 3

B. Memory Errors under Spectre v1

  • Spectre v1 can use speculative out-of-bounds accesses and cache effects to reveal values; half gadgets can also support Rowhammer or speculative ROP attacks.The threat model includes transient accesses even without an immediate cache side channel.Source: B. Memory Errors under Spectre v1 · p. 3, C. Threat Model · p. 3

D. Motivation

Naive compositions of sequential and speculative defenses can remain unsafe in either order while adding redundant protections; DualGuard treats both domains as a unified problem and seeks protection only where needed.

D. Motivation

  • Both Baggy-and-SLH composition orders remain unsafe, despite layering defenses intended for sequential and speculative memory safety.Baggy followed by SLH still leaves canonical-address checks unprotected against speculative bypass; SLH followed by Baggy can add branches.Source: D. Motivation · pp. 3–4
  • SLH hardens speculative accesses by adding branch-condition dependencies and masking addresses, but subsequent Baggy instrumentation adds branches for sequential safety.SLH’s mis register tracks mis-speculation status; Baggy then rewrites the access to protect against sequential errors.Source: D. Motivation · pp. 3–4
  • Up to 10X slowdown occurs when off-the-shelf Baggy and SLH are composed on a cryptographic-library benchmark.The paper describes the overhead of naive compositions as potentially prohibitive for real-world software.Source: D. Motivation · p. 4

A. Memory Safety in Spectre Era

  • Speculation can undermine existing memory-safety defenses and introduce memory errors absent from sequential execution, a gap that prior defense analyses often overlooked.The paper argues this oversight can lead to unsafe, redundant protection stacks.Source: A. Memory Safety in Spectre Era · p. 4
  • DualGuard integrates sequential and speculative safety to identify when and where protection is needed rather than treating speculative safety as a retrofit.This unified perspective targets unnecessary or redundant protection.Source: A. Memory Safety in Spectre Era · p. 4

B. Defenses against Spectre V1 Attacks

The paper reviews software defenses against Spectre V1 and formalizes program memory behavior across sequential and speculative execution. Its framework classifies access locations by the violation regions each can produce.

B. Defenses against Spectre V1 Attacks

  • Selective SLH variants reduce unnecessary instrumentation but do not protect against sequential memory errors; serialization primitives can incur prohibitive overhead when used pervasively.SLH-style defenses introduce dependencies between branch conditions and later memory operations; LFENCE, IBRS, and CSDB disable speculation through serialization.Source: B. Defenses against Spectre V1 Attacks · p. 4

A. Language Syntax

  • The formalization uses a simple imperative language with assignments, branches, sequential composition, and loads and stores, including nested array accesses.The paper chooses a source-level language for readability while conducting code analysis on lower-level intermediate representation.Source: A. Language Syntax · p. 5

B. Semantics

  • The semantics model predicted branches and a fixed transaction window, generating traces that include memory operations and speculative transaction events.Sequential projections exclude rolled-back speculative transactions, while speculative projections contain operations enclosed by such transactions.Source: B. Semantics · p. 5

C. Categorization

  • Each memory-access location is classified by whether its sequential and speculative violation regions are empty, yielding four safety categories.The categories distinguish locations safe in both modes, unsafe only sequentially, unsafe only speculatively, or unsafe in both.Source: C. Categorization · p. 6
  • The categories imply different minimum defenses: safe-in-both locations need none, sequential-only-unsafe locations need sequential protection, and speculative-only-unsafe locations need Spectre defenses.The stated minimums assume the instrumentation itself does not introduce additional memory-safety violations.Source: C. Categorization · pp. 6–7
  • Some locations are unsafe in both modes: the example has sequential accesses to A[8] and A[9] and a speculative access to A[10].This illustrates that sequential and speculative violation regions can contain different addresses for the same location.Source: C. Categorization · p. 7

V. DUAL MEMORY SAFETY

Dual memory safety is framed as freedom from all memory violation regions, with the formal definition enabling precise reasoning about that property.

V. DUAL MEMORY SAFETY

  • The formal definition makes dual memory safety a program-level property based on the absence of all memory violation regions.The paper identifies this definition as a basis for formal and precise reasoning about dual safety.Source: §V · p. 7

A. Composition Theorem

The composition theorem uses safety preservation to identify when sound sequential and speculative defenses can be composed for dual memory safety. Analysis of existing mechanisms shows that their guarantees differ: some introduce or rely on protections that remain vulnerable under speculation.

A. Composition Theorem

  • Safety preservation is defined by requiring that rewriting a program location does not increase violations in the other execution domain.The definition quantifies over program locations before rewriting; rewritten code may contain multiple instructions.Source: A. Composition Theorem · p. 7
  • Composing two sound defenses yields dual memory safety when the applied order includes a safety-preserving mechanism.Safety preservation means a mechanism does not introduce violations in the other execution domain.Source: A. Composition Theorem · p. 7

B. Systematic Analysis of Memory Safety Mechanisms

  • Baggy adds branches that can expand speculative violation regions, while Delta Pointers relies on canonical-address checks that speculation can bypass.For Delta Pointers, the cited analysis notes that Intel Spectre v2 is outside this paper’s scope.Source: B. Systematic Analysis of Memory… · p. 8
  • SafeStack and SLH are safety-preserving, but SLH is conditionally sound when its mis-speculation register accurately tracks branch-prediction status.SLH does not protect checks bypassed without branch misprediction, including canonical-address checks used by Baggy and Delta Pointers.Source: B. Systematic Analysis of Memory… · pp. 8–9
  • SpecASan extends MTE tag checks to speculative execution, while CHERI checks capability bounds during both execution modes; neither adds memory accesses.The cited passages identify both mechanisms as dual safe and safety-preserving.Source: B. Systematic Analysis of Memory… · p. 9

C. Dual safety properties.

The paper distinguishes dual-safe compositions from combinations whose protections fail across execution modes. It presents software variants of Baggy and Delta Pointers, then proves that selective application of sound, safety-preserving defenses can retain dual safety while omitting unnecessary checks.

C. Dual safety properties.

  • SafeStack + SLH is dual safe, whereas applying SLH after Baggy or Delta Pointers does not guarantee dual memory safety.SLH does not protect the canonical-address checks on which Baggy and Delta Pointers rely.Source: C. Dual safety properties · p. 9

D. Software-Based Dual Safe Mechanisms

  • DUALBAGGY replaces Baggy’s branch-based and hardware-based checks with a branchless select that sets out-of-bounds addresses to -1.This design is motivated by SLH and avoids Baggy’s problematic branch-based checks.Source: D. Software-Based Dual Safe Mechanisms · p. 9
  • DUALDELTAPOINTERS checks the most significant bit in software and selects address -1 when that bit is set.The select neutralizes an out-of-bounds address before the load, including during speculative execution.Source: D. Software-Based Dual Safe Mechanisms · p. 9

E. Selective Defense

  • At locations safe under speculative execution but unsafe sequentially, the sequential defense’s safety preservation permits omitting speculative defenses such as SLH.This targets sequential-only out-of-bounds accesses and avoids redundant speculative protection.Source: E. Selective Defense · p. 9
  • Selective composition omits a defense at locations already safe in its execution domain, and the theorem establishes dual safety for sound, safety-preserving mechanisms.The rule selects both defenses when neither violation set is empty, and omits them when both are empty.Source: E. Selective Defense · p. 10

F. Selective Dual Memory Safe Mechanisms

Selective dual-safe configurations assign defenses according to each location’s sequential and speculative risks. DUALGUARD uses two analyses to identify vulnerable locations, then applies dual-safe mitigations; its analyses differ in path sensitivity and treatment of speculation windows.

F. Selective Dual Memory Safe Mechanisms

  • Three selective configurations apply a dual-safe mechanism to U↠S and U↠U locations and SLH to S↠U locations.The configurations pair SLH with DUALBAGGY, DUALDELTAPOINTERS, or SafeStack; placing additional objects on SafeStack’s unsafe stack can weaken object-level isolation.Source: F. Selective Dual Memory Safe Mechanisms · p. 10

VI. DUALGUARD

  • DUALGUARD’s two analysis phases identify sequentially vulnerable locations, then locations vulnerable under either sequential or speculative execution, before passing findings to mitigation.The workflow is shown in Figure 4.Source: §VI · p. 10, Figure 4 · p. 10

A. Static Analysis

  • Each analysis collects pointer arithmetic and object sizes, computes variable ranges with forward data flow, and marks accesses unsafe when offset ranges exceed object bounds.When compile-time analysis cannot decide a range, it conservatively estimates it as unbounded.Source: A. Static Analysis · pp. 10–11

B. Path Sensitivity

  • DUALGUARD↠ uses path conditions to narrow ranges within branches, while speculative-aware DUALGUARD ignores path conditions to over-approximate possible values.The two analyses therefore use different assumptions about whether branch conditions constrain execution.Source: A. Static Analysis · p. 11, B. Path Sensitivity · p. 11

C. Out-of-Window Analysis

  • DUALGUARD’s out-of-window analysis uses reachability from each branch up to the speculation-window size to identify instructions that cannot execute speculatively.Instructions unreachable within all branch windows are reported as speculatively memory safe.Source: C. Out-of-Window Analysis · p. 11

VII. EVALUATION

DUALGUARD extends LLVM-based analysis and enforcement to identify unsafe locations and selectively apply dual-safe mechanisms. On SPEC CPU 2017, its Baggy- and Delta-Pointers-based configurations substantially reduce overhead compared with naive stacking.

A. Implementation

  • DUALGUARD extends an LLVM-based memory-safety analysis, adding roughly 1,500 lines of C++ and about 700 lines for out-of-window analysis.Its speculation window is configurable and set to 200 instructions for the evaluation.Source: A. Implementation · p. 11

B. Evaluation Setup

  • The evaluation covers 13 of 16 C/C++ SPEC CPU 2017 benchmarks and cryptographic libraries; three SPEC benchmarks are excluded for tool crashes or analysis scalability limits.imagick r crashes under Baggy and Delta Pointers because it intentionally performs out-of-bounds accesses; gcc r and blender r are excluded because analysis times out or exhausts memory.Source: B. Evaluation Setup · p. 11

C. The Overhead of DUALGUARD

  • Three evaluated dual-safe configurations use DUALBAGGY, DUALDELTAPOINTERS, or selective SafeStack plus SLH; naive compositions apply three mechanisms at all identified potentially unsafe locations.The other selective Baggy-plus-SLH and Delta-Pointers-plus-SLH variants are evaluated separately under Q4; the naive Baggy-plus-SLH and Delta-Pointers-plus-SLH combinations do not satisfy dual safety.Source: C. The Overhead of DUALGUARD · p. 12

1) SPEC CPU 2017:

  • On SPEC CPU 2017, DUALGUARD reduces overhead by 70.6% over BAGGY+SLH and 71.9% over DELTAPOINTERS+SLH; DUALDELTAPOINTERS has the lowest overhead overall.The reported average overheads are 148.4% versus 43.6% for BAGGY+SLH and DUALGUARD-DUALBAGGY, and 119.7% versus 33.6% for DELTAPOINTERS+SLH and DUALGUARD-DUALDELTAPOINTERS.Source: 1) SPEC CPU 2017 · pp. 12–13
  • DUALGUARD-SAFESTACKSLH has lower or comparable overhead than SAFESTACK+SLH across benchmarks, reducing average overhead from 103.2% to 99.5%.The paper reports that this reduction is smaller than in the Baggy- and Delta-Pointers-based comparisons.Source: 1) SPEC CPU 2017 · p. 12

2) Cryptographic libraries:

Across cryptographic libraries, DUALGUARD configurations outperform their naive counterparts, while also providing dual memory safety with modest overhead relative to partial protections. Selective composition reduces overhead, and the evaluation reports analysis times for real-world programs alongside scope boundaries and future directions.

2) Cryptographic libraries:

  • Across Baggy-, Delta Pointers-, and SafeStack-based protections, DUALGUARD configurations consistently incur lower overhead, with reduction rates of 16.8% to 71.8% across all configurations; DUALDELTAPOINTERS has the lowest overall overhead, 28.9%.Average overheads are 71.9% for DUALGUARD-DUALBAGGY, 28.9% for DUALGUARD-DUALDELTAPOINTERS, and 39.2% for DUALGUARD-SAFESTACKSLH.Source: 2) Cryptographic libraries · p. 13

D. Dual vs. Partial Memory Safety

  • DUALGUARD provides dual memory safety with modest overhead relative to Delta Pointers and, in some cases, lower overhead than Baggy, LLVM-SLH, and LightSLH.Among the compared approaches, only DUALGUARD variants offer dual memory safety; Baggy and Delta Pointers do not provide speculative memory safety, while LLVM SLH and LightSLH target Spectre V1.Source: D. Dual vs. Partial Memory Safety · p. 13, Table II · p. 13

E. Selective Defense

  • Selective composition reduces overhead by 5.4%, 4.3%, and 2.9% on SPEC CPU 2017 and by 8.4%, 0%, and 17% on cryptographic libraries for Baggy, Delta Pointers, and SafeStack, respectively.The results are summarized in Figure 7.Source: Figure 7 · p. 13, E. Selective Defense · p. 14

F. Scalability

  • DUALGUARD analysis completes within 8 seconds for the small cryptographic libraries, while SPEC analysis ranges from 51.23 seconds for xalancbmk r to 8254.01 seconds for perlbench r.xalancbmk r is the largest SPEC program at 520 KLoC; most cryptographic programs have fewer than 1 KLoC.Source: F. Scalability · p. 14

VIII. LIMITATIONS AND FUTURE WORK

  • The evaluated scope is spatial memory safety under Spectre v1; temporal memory safety and attacks such as Spectre v2 and Spectre-RSB remain future research directions.The paper describes temporal lifecycle invariants and dynamic control-flow redirection as distinct from the bounds-check bypass scenarios addressed here.Source: §VIII · p. 14

IX. CONCLUSION

  • The conclusion characterizes DUALGUARD as a unified approach that classifies memory behavior into four categories to identify minimal dual-protection requirements and remove redundant protections.The paper describes broader Spectre-attack generalization and framework scalability as future work.Source: §IX · p. 14

ETHICS CONSIDERATIONS

  • The authors report that their evaluation was conducted in an isolated laboratory and did not exploit or compromise production systems.They also state that they did not present end-to-end exploits or actionable attack primitives.Source: ETHICS CONSIDERATIONS · pp. 14–15

APPENDIX

The appendix formalizes speculative execution using a prediction oracle and a bounded transaction window, with traces recording memory events and transaction outcomes. It also presents value-range dataflow equations and explains why speculation requires analysis without branch path conditions.

A. Formalizing Program Semantics with Speculation

  • The speculative-aware semantics takes a prediction oracle O and transaction length w, and models execution as traces containing memory accesses and speculative transaction events.Transactions can commit or roll back, and the semantics is deterministic for a given oracle and window size.Source: A. Formalizing Program Semantics with… · pp. 16–17, Figure 8 · p. 17
  • The example with O(1) = true and w = 1 produces a trace that begins a transaction, accesses A[i], stores y, and rolls back.The trace illustrates a concrete speculative execution under the stated branch prediction and transaction length.Source: A. Formalizing Program Semantics with… · p. 17
  • The forward-may value-range analysis unions predecessor ranges at block entry and computes block output by removing killed ranges and adding generated ranges.If a variable's range is unavailable in any predecessor, the resulting range is infinite.Source: A. Formalizing Program Semantics with… · p. 17, value range analysis · p. 18
  • Path conditions can prove an access safe sequentially, but speculative analysis drops those conditions because a mispredicted branch can execute the access when they do not hold.For the example access at line 4, the path-sensitive sequential analysis marks it safe, whereas the path-insensitive analysis rejects it.Source: value range analysis · p. 18

B. Comparison with Partial Protections

Across SPEC and cryptographic benchmarks, DualGuard configurations often reduce overhead relative to partial defenses while providing dual-safety. The OpenSSL case study shows how branchless bounds checks can avoid layered instrumentation that still relies on hardware rejection.

B. Comparison with Partial Protections

  • 44% average overhead for DUALGUARD-DUALBAGGY versus 131% for Baggy on SPEC benchmarks, a 66% reduction relative to Baggy.DUALGUARD-DUALDELTAPOINTERS achieves overhead lower than or comparable to Delta Pointers while providing a stronger security guarantee.Source: B. Comparison with Partial Protections · p. 18
  • 71.9% average overhead for DUALGUARD-DUALBAGGY versus 146.6% for Baggy across cryptographic libraries, an approximately 51% reduction.DUALGUARD-DUALDELTAPOINTERS averages 28.9%, compared with 20.4% for Delta Pointers, due to the extra instructions for dual-safety.Source: B. Comparison with Partial Protections · p. 18
  • 33% and 37.9% average overhead reductions versus LLVM’s SLH are reported on SPEC for DUALGUARD-DUALBAGGY and DUALGUARD-DUALDELTAPOINTERS, respectively.LightSLH could not be evaluated on SPEC because of limited instruction support and scalability limitations.Source: B. Comparison with Partial Protections · p. 18
  • On cryptographic libraries, DUALGUARD-DUALDELTAPOINTERS averages 28.9% overhead, lower than both LLVM’s SLH at 45.6% and LightSLH at 30.6%, while providing dual-safety.DUALGUARD-DUALBAGGY averages 71.9%; its bounds-table memory loads primarily account for its higher overhead, though it is lower than LLVM’s SLH on 7 benchmarks and LightSLH on 4.Source: B. Comparison with Partial Protections · p. 18

C. Case Study

  • In the OpenSSL stack-push case, integer overflow can make the allocation smaller than required, allowing the line-17 store to go out of bounds.Naive BAGGY+SLH layering retains a hardware check after bounds and mis-speculation instrumentation; DUALGUARD-DUALBAGGY instead checks bounds branchlessly and removes reliance on that check.Source: C. Case Study · pp. 19–20

D. Selective Defense Overhead

Selective-defense comparisons for individual benchmarks are presented in Figures 11 and 12.

D. Selective Defense Overhead

  • Figures 11 and 12 show a detailed comparison of selective defenses for each benchmark, presenting benchmark-specific comparisons without identifying particular benchmark categories in the cited passage.Source: D. Selective Defense Overhead · p. 20

E. Analysis Running Time

The paper points to Table III for analysis running time and describes artifact access through source builds or a recommended pre-built Docker image. The artifact omits the SPEC CPU 2017 suite because of copyright restrictions.

E. Analysis Running Time

F. Artifact

  • The artifact repositories include DUALGUARD source and benchmarks except SPEC CPU 2017, which cannot be shared because of copyright restrictions.The tool can be run from source or through a pre-built Docker image, which the authors recommend to ease setup.Source: F. Artifact · p. 20

1) Using Pre-built DUALGUARD with Docker:

  • The pre-built workflow pulls the DUALGUARD image from DockerHub and starts a container; Docker must be installed on the test machine.When SPEC CPU 2017 is unavailable, the artifact instructions offer running the LightSLH benchmarks only.Source: 1) Using Pre-built DUALGUARD with Docker · pp. 20–21
Loading 2610.39374v1…