Detecting speculative data flow vulnerabilities using weakest precondition reasoning

Abstract: Speculative execution is a hardware optimisation technique where a processor, while waiting on the completion of a computation required for an instruction, continues to execute later instructions based on a predicted value of the pending computation. It came to the forefront of security research in 2018 with the disclosure of two related attacks, Spectre and Meltdown. Since then many similar attacks have been identified. While there has been much research on using formal methods to detect speculative execution vulnerabilities based on predicted control flow, there has been significantly less on vulnerabilities based on predicted data flow. In this paper, we introduce an approach for detecting the data flow vulnerabilities, Spectre-STL and Spectre-PSF, using weakest precondition reasoning. We validate our approach on a suite of litmus tests used to validate related approaches in the literature.

• The paper presents a formal approach using weakest precondition reasoning to unify the detection of Spectre-STL, Spectre-PSF, and Spectre-PHT vulnerabilities.
• It introduces modified wp rules with ghost instructions and memory fences to enforce data security across speculative and non-speculative states.
• The method is validated on multiple litmus tests, demonstrating its potential for automated tool integration in speculative execution vulnerability analysis.

This paper (2504.19128) introduces a formal approach using weakest precondition (wp) reasoning to detect speculative execution vulnerabilities, specifically focusing on data flow variants like Spectre-STL and Spectre-PSF. It builds upon an existing wp-based method for detecting control flow variants like Spectre-PHT, providing a unified framework for analyzing these distinct but related vulnerabilities.

The core of the approach is a weakest precondition transformer, denoted $wp_s$, which operates over a pair of predicates $\langle Q_s, Q \rangle$. $Q_s$ represents the weakest precondition in a speculative context, and $Q$ the weakest precondition in a non-speculative context. The security of a program is guaranteed if the initial state satisfies the derived non-speculative precondition $Q$.

The paper defines rules for $wp_s$ over a simple assembly-like language including assignments, sequential composition, conditional statements, loops, and special instructions:

• $$`: A memory fence instruction that terminates current speculative execution, effectively resetting the speculative precondition$$Q_s$to</code>true`.</li> <li><code>${e}`: A ghost instruction inserted before a potential leak gadget. This instruction introduces a proof obligation: the security level of the expression `e` must be the lowest possible (`$\bot$) in both speculative and non-speculative states. This obligation ensures that any leaked information is non-sensitive.

A pre-pass identifies potential micro-architectural leak gadgets (like loads used to index publicly observable memory) and inserts the $${e}</code> instruction before them, where <code>e</code> is the value being leaked (e.g., the index value).</p> <p>The logic tracks the security level of data using expressions$$\Gamma_v$and security policies$(x)$for variables, forming a security lattice$(L, \sqsubseteq)$$. Proof obligations related to information flow are integrated into the wp rules. For example, a store <code>x := e</code> in the non-speculative state requires that the security level of <code>e</code> is not higher than the policy of <code>x</code> ($$\Gamma_E(e) \sqsubseteq (x)$$), and that updating <code>x</code> does not violate security policies for other variables.</p> <p>To handle speculative execution points, specifically branches (for Spectre-PHT) and stores (for Spectre-STL/PSF), proof obligations from the speculative state$$Q_s$are transferred to the non-speculative state$Q$$. This means if a vulnerable state is reachable speculatively from a certain point, the logic requires that this vulnerable state is non-threatening <em>in the non-speculative initial state leading to that point</em>.</p> <p><strong>Spectre-STL Detection:</strong></p> <p>Spectre-STL exploits the misprediction that a load is independent of an earlier store, leading to the load using a stale value. To model this, the standard$$wp_s$$rule for a store <code>x := e</code> is modified. In addition to the normal requirements, the speculative postcondition$$Q_s$$<em>before</em> the store is added as a conjunct to <em>both</em> the speculative and non-speculative preconditions <em>before</em> the store. This captures the possibility that the store is effectively bypassed (<code>Q_s</code> is transferred) while speculative execution continues (<code>Q_s</code> is maintained). Ghost variables tracking definedness (<code>def{y}</code>) and base state variables (<code>y^</code>) are handled during this transfer to correctly relate the speculative and non-speculative contexts.</p> <p>The modified Spectre-STL store rule <code>STL(x := e,$$\lseq Q_s, Q\rseq$$)</code> is:$$

$\lseq \M \underline{Q_s} \land Q_s[#1{x, \Gamma_x, def{x}{e, \Gamma_E(e), true},\ Q[#1{x, \Gamma_x}{e, \Gamma_E(e)} \land \Gamma_E(e) \sqsubseteq (x) \land & (1)\ (\all y \cdot \Gamma_y \sqcap (y) \sqsubseteq (y)[#1{x}{e})\land\ \underline{Q_s[#1{var^, d_1, ..., d_n}{var, false, ..., false}\,\rseq\O$

The underlined parts represent the addition for Spectre-STL, transferring the speculative postcondition (<code>Q_s</code> before the store) to the non-speculative and speculative preconditions (before the store).</p> <p>Applying this rule to the Spectre-STL litmus test (Case 4 in Appendix A) involving <code>secretarray[r0] := 0</code> followed by a load <code>r1 := secretarray[r0]</code> and a leak instruction <code>{r1}`, the logic derives a non-speculative precondition requiring `$$\Gamma_{secretarray[idx\,{content}\,(array\_size-1)]} = \bot$$`. This indicates a vulnerability if the value at the accessed index of `secretarray` is sensitive, as a bypassed store could lead to the original sensitive value being leaked. Inserting a fence after the store resets$Q_s$ totruebefore the store rule is applied, preventing the transfer of speculative obligations and resulting in a safe precondition (true`).

Spectre-PSF Detection:

Spectre-PSF relies on mispredicting that a load is dependent on an earlier store and speculatively forwarding the store's value, even if the addresses don't match. To model this, the Spectre-STL store rule is further extended. The speculative state can now be reached not just by bypassing the store, but also by speculatively forwarding the store's value (e) to any subset of variables ({y_1,...,y_m}) that appear in the speculative postcondition ($Q_s$ before the store).

The PSF(x := e, $\lseq Q_s, Q\rseq$) rule adds proof obligations for every subset of variables in the speculative postcondition, where those variables are replaced by the store value e. These obligations are added to both the speculative and non-speculative preconditions.

$PSF(x := e, \lseq Q_s, Q\rseq) =\ \t1 \lseq \M \underline{\forall \{y_1,...,y_m\}\subseteq vars(Q_s)\cdot}\ \t1 (Q_s \land Q_s[#1{x, \Gamma_x, def{x}{e, \Gamma_E(e), true})\underline{[#1{y_1,...,y_m}{e,...,e},\ Q[#1{x, \Gamma_x}{e, \Gamma_E(e)} \land \Gamma_E(e) \sqsubseteq (x) \land & (2)\ (\all y \cdot \Gamma_y \sqsubseteq (y)[#1{x}{e})\land\ \underline{\forall \{y_1,...,y_m\} \subseteq vars(Q_s) \cdot}\ \t1 Q_s[#1{var^, d_1, ..., d_n}{var, false, ..., false}\underline{[#1{y_1,...,y_m}{e,...,e}\,\rseq\O$

The underlined parts show the universal quantification over subsets of variables in $Q_s$ and their substitution with the store value e.

For the Spectre-PSF example (Section 3.2) where C[0] := 64 is followed by loads from C[r0] and A[r1*r0], and a final leak instruction based on the value from A, the logic analyzes the potential speculative forwarding of 64. For $idx=1$, if 64 is forwarded to the variable holding C[r0], the subsequent load becomes A[64*1], an out-of-bounds access. The derived non-speculative precondition includes $\Gamma_{A[64*r0]} = \bot$, which is not provably true if A[64] is sensitive data, indicating the vulnerability.

Practical Implementation and Application:

The proposed logic provides a formal basis for building automated analysis tools.

1. Language Abstraction: The assembly-like language is simple enough to represent typical vulnerable code patterns (gadgets). Real-world code would need to be translated to this intermediate representation.
2. Gadget Detection: A pre-analysis phase is required to identify potential leak gadgets and insert $${e}</code> instructions. This can be mechanized based on code patterns accessing publicly observable memory (like cache-timing channels).</li> <li><strong>Security Policy:</strong> Defining the security policy$$((x))$$for variables is crucial and requires programmer or system annotations. This defines what information is considered sensitive and where it is allowed to reside.</li> <li><strong>Automated Reasoning:</strong> The paper suggests that automated weakest precondition analyzers like Boogie or Why3 could be adapted to implement this logic. This would require encoding the$$wp_s$ rules and handling the security lattice and ghost variables within the prover's framework.
3. Scalability: While wp-based methods can handle non-determinism better than pure model checking, handling the full speculative window and complex program structures remains a challenge. The current approach approximates the speculation window by allowing speculation to continue indefinitely.
4. Combination of Attacks: The logic naturally handles combinations of Spectre variants by accumulating proof obligations from different sources of speculation (branches and stores). Case 9 in Appendix A and the example in Appendix B demonstrate this.
5. Integration with Other Techniques: The framework is designed to integrate with rely/guarantee reasoning for concurrent programs and reordering interference freedom for weak memory models, offering a path towards analyzing more complex real-world scenarios.

The approach has been validated on a suite of 13 Spectre-STL litmus tests and a Spectre-PSF test, successfully identifying known vulnerabilities and confirming that mitigations like fences are effective according to the logic. The main practical challenge for widespread adoption is the development of automated tooling based on the formal rules.