Pith. sign in

REVIEW 4 major objections 5 minor 65 references

Analyzing and Exploiting Branch Mispredictions in Microcode

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Mispredicted branches inside Intel microcode can bypass privilege checks and leak secrets.

desk verdict The Goldmont result is real and important, but the cross-core scope and the reclassification of known attacks are inferences, not demonstrations; referee it with that distinction enforced. read the letter →

arxiv 2501.12890 v1 pith:ET7LK6LJ submitted 2025-01-22 cs.CR cs.AR

Nicholas Mosier , Hamed Nemati , John C. Mitchell , Caroline Trippel This is my paper · ORCID
classification cs.CRcs.AR
keywords microcodetransientexecutionµSpectrebranchmispredictionIntelGoldmontspeculativeRogueSystemRegisterReadµSLH
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that a new class of transient-execution attacks, called µSpectre, arises from mispredicted conditional branches inside Intel microcode, the internal microprograms that implement complex instructions. Because Intel processors statically predict these microcode branches as not-taken, a microcoded instruction that should raise an exception or take a slow path can transiently execute its fast path and then several following macro-ops as if the check had passed. An unprivileged program can therefore transiently read privileged architectural state, and in one demonstrated case, internal control registers that no architectural instruction can access. The authors show that several attacks previously classified as Spectre or Meltdown variants are actually µSpectre instances on some Intel cores, and they propose a microcode-patchable defense, µSLH. If the paper is right, the boundary between microarchitectural speculation and architectural security needs to include the processor's own microcode.

What carries the argument

The central object is the conditional microcode branch (µbranch), a branch inside an MSROM microprogram whose direction depends on runtime data and which Intel statically predicts not-taken on all tested cores. Misprediction of a µbranch opens a transient window that spans many macro-ops because correction happens in-order at retirement while the microsequencer stops issuing along the wrong path only on detection. The paper's other machinery is µSLH, a defense that places SELECTcc micro-ops after each vulnerable µbranch so that any register holding possibly invalid or privileged data is zeroed unless the branch's predicate resolved to the not-taken prediction.

What would settle it

Run the paper's std; lfence; cld microbenchmark on a microarchitecture whose microcode can be inspected; if the issued micro-op count equals the retired count while the branch's predicate resolves taken, then conditional µbranches are not statically predicted not-taken on that core and the reclassification collapses for it.

Watch

Extended reading notes

Core claim

On every Intel microarchitecture tested (Goldmont, Goldmont Plus, Haswell, Kaby Lake, Golden Cove), conditional microcode branches are statically predicted not-taken, even when the correct direction is taken. When such a branch is mispredicted, the core transiently executes the not-taken remainder of the microprogram and then up to 12 macro-ops (or more, depending on the predicate latency) before correcting at retirement. This turns any microcoded instruction whose microprogram checks a condition by branching to an exception routine into a potential exception bypass: rdfsbase/rdgsbase, xgetbv, rdpmc, bound, and into on Goldmont all transiently skip their checks. The paper reclassifies Rogue System Register Read, Meltdown-BND, Zero Dividend Injection, and String Comparison Overrun as µSpectre variants, and discloses µSpectre-MEB-PCIDX, which leaks all 256 control registers in the 0x2200–0x2300 range, including registers that correspond to no architectural state. It also proposes µSLH, which inserts conditional-select micro-ops that zero registers that could hold unauthorized data after a mispredicted branch.

Load-bearing premise

The load-bearing premise is that the static not-taken prediction and the multi-macro-op transient windows measured on Goldmont, together with inferences from performance-counter counts on other cores, hold across all modern Intel microarchitectures, even though the paper has a microcode dump only for Goldmont.

Editorial extensions

If this is right

  • Rogue System Register Read, previously classified as Meltdown, is on Goldmont a µSpectre-MEB exception bypass in rdfsbase, xgetbv, and rdpmc, so fixing it requires hardening microcode branches rather than fault-delay mitigation.
  • Zero Dividend Injection and String Comparison Overrun, previously attributed to value prediction and speculative string overrun, are reclassified as µSpectre-MVI and µSpectre-MIL respectively, changing where mitigations must be inserted.
  • µSpectre-MEB-PCIDX shows that an unprivileged program can read all 256 control registers in the 0x2200–0x2300 range on Goldmont, including registers with no architectural meaning, and the paper argues one different micro-op would have exposed a vastly larger control-register space.
  • µSLH, deployed by microcode update, fully closes the µSpectre-MEB attacks reported and gives all MVI attacks a uniform transient zero value; µSpectre-MIL requires avoiding the vulnerable instructions.
  • No CVE or microcode update has been released in response to disclosure, and non-Goldmont microcode remains opaque, so the same vulnerability class may persist in other Intel cores.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next step is to turn the paper's issue/retire nanobenchmark into a black-box oracle: run it on every Intel and AMD core, and a nonzero issue/retire gap after std; lfence; cld would signal a statically predicted not-taken µbranch even without a microcode dump.
  • The µSLH pattern generalizes beyond the reported bugs: any microcode branch whose not-taken path touches privileged state is a candidate for the same conditional-select hardening, effectively defining a compiler-like pass over microcode.
  • If the lack of a CVE or patch reflects a disclosure policy gap, the paper implies that vulnerability researchers should treat microcode updates as a primary disclosure channel rather than relying on hardware errata.
  • The undocumented-instruction analysis suggests that other undocumented or privilege-gated microcode may contain similar not-taken transient paths, making microcode transparency itself a security property.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper introduces µSpectre, a class of transient execution attacks that exploit conditional microcode branch mispredictions on Intel processors. The central claim is that a conditional µbranch can be statically mispredicted not-taken, creating a transient execution window that spans several macro-ops and can leak sensitive architectural or microarchitectural state. The authors provide microcode-level analyses for Goldmont (cld, bound, rdpmc), a demonstrated exploit (µSpectre-MEB-PCIDX) that leaks control registers in the range 0x2200–0x2300 on Goldmont, reclassifications of known attacks (Rogue System Register Read, Meltdown-BND, Zero Dividend Injection, String Comparison Overrun) as µSpectre variants, and a proposed microcode-level defense called µSLH.

Significance. If the central claims hold, this is a genuinely new class of transient execution attacks distinct from Spectre and Meltdown, with the notable property that it can leak internal microarchitectural state that is not architecturally accessible at any privilege level. The paper's strengths are its use of publicly available Goldmont microcode disassembly, targeted nanobenchmarks, and a proof-of-concept for µSpectre-MEB-PCIDX. The authors are transparent about several limitations, including the lack of demonstrated leaks for µSpectre-MEB-OF and the µSpectre-MVI-DF/ARPL/ENTER primitives. However, the paper's scope-level claims—particularly Observation 1 as a statement about all Intel cores and the reclassification of ZDI on Haswell—rest on inferences from only one or two microcoded instructions on non-Goldmont cores. The Goldmont demonstrations can stand on their own, but the broader claims need to be either supported with additional evidence or explicitly reframed as hypotheses.

major comments (4)
  1. [§3.3.1, Observation 1] The claim that 'Intel cores statically predict that conditional microcode branches are not-taken' is load-bearing for the paper's scope, but the evidence outside Goldmont is an inference from the cld nanobenchmark. The paper itself concedes 'We cannot be certain that this is also the case for the other cores' and justifies the universal claim with 'we see no reason why Intel would make this opposite design choice.' The 17/13 vs 7/7 issue/retire delta on non-Goldmont cores is consistent with a statically not-taken µbranch, but it is also consistent with other microarchitectural explanations, such as a different fast-path length, extra serialization, or a taken-predicted branch with a shorter slow path. Since Observation 1 is used to reclassify ZDI in §5.3 and to frame µSpectre as a class-wide phenomenon, the authors should either restrict the class-level claims to Goldmont or provide independent cross-core evidence for the prediction policy, e.g., several microcoded instructions with known fast/slow path lengths or direct microcode disclosure.
  2. [§5.3, Figure 11] The ZDI reclassification rests on a hypothesized microprogram structure. The nanobenchmark data (39/39 vs 61/49 issued/retired micro-ops) show that more micro-ops are issued than retired when rdx is nonzero, but they do not establish that the extra transient micro-ops arise from a conditional µbranch that is statically predicted not-taken. The authors infer the entire div microprogram structure from these counts by analogy to Observation 1. If Observation 1 does not hold on Haswell, or if the extra issued micro-ops come from value prediction or another transient mechanism, the claim that ZDI is 'an instance of µSpectre-MVI' is unsupported. Please mark this reclassification as a hypothesis or provide direct evidence, such as microcode tracing or additional discriminating experiments.
  3. [§3.4, Observation 2] The claim that Goldmont Plus 'may transiently execute up to 22 macro-ops' is reported without supporting traces or a described measurement procedure. This is one of the two observations that motivate the attack model. Please provide the raw data, the nanobenchmark used, and the method for counting macro-ops in the transient window, or downgrade the claim to a preliminary observation.
  4. [§6.1 and §6.3] Two of the claimed new vulnerabilities are not demonstrated. For µSpectre-MEB-OF (§6.1), no proof-of-concept is given; for the new MVI instances (§6.3), the text says 'we have so for not been able to demonstrate attacks exploiting this fact to transiently leak sensitive data.' The contributions list and Figure 5 present these as new vulnerabilities, which overstates the evidence. Please relabel them as candidate vulnerabilities or provide demonstrations.
minor comments (5)
  1. [§4.4] The sentence 'In §4.4, we provide an example of a microcode-internal leak' is incorrect: the example appears in §5.4 (µSpectre-MIL-SCO), not §4.4.
  2. [Throughout] There are several typos: 'microseqeuncer' in §2.3, 'so for' in §6.3, 'occurence' in §7, 'phyiscal' in §6.4, and 'µSpectre-MEC-PCIDX' in §6.2.4.
  3. [§5.1.1] The text says 'we find that three instructions are vulnerable' and then 'we find that three of these implement privilege checks'; since the list has exactly three items, 'three of these' should be 'all three'.
  4. [Figure 5] It is unclear which entries are demonstrated versus inconclusive. The legend says demonstrated attacks are red and inconclusive results are gray, but the new MVI candidates from §6.3 appear in bold without a color, and µSpectre-MEB-OF is listed without a demonstrated leak.
  5. [References] References [54] and [55] are identical (same title, authors, and venue); one should be removed or the numbering corrected.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the Goldmont results are derived from public microcode and direct performance-counter measurements, and the cross-core generalizations are hedged empirical inferences rather than definitional reductions.

full rationale

The paper's central derivation chain is self-contained. The existence claims for µSpectre on Goldmont rest on (i) Ermolov et al.'s externally published MSROM disassembly, (ii) the authors' own performance-counter nanobenchmarks (e.g., the cld experiments reporting 7/7 vs 17/13 issued/retired µops), and (iii) reproduced microprogram listings that show vulnerable UJMPcc branches guarding exception paths. None of these steps fits a parameter to the target result and then reports it as a prediction; the observed issue/retire deltas are independent measurements used to infer branch direction, not outputs of a fitted model. The reclassification of Rogue System Register Read, Meltdown-BND, ZDI, and SCO is an interpretive argument supported by microcode inspection on Goldmont and by instrumentation on other cores; it is not a definitional identity. The only load-bearing weakness is the generalization of Observation 1 beyond Goldmont from a single inferred cld µbranch, which the paper explicitly hedges ('We cannot be certain that this is also the case for the other cores... However, we see no reason why Intel would make this opposite design choice'). That is an evidentiary limitation (correctness risk), not circularity. No self-citation chain is load-bearing; the cited prior work on Goldmont microcode is external and independently published, and no uniqueness theorem or ansatz is imported from the authors' own prior work. Accordingly, no step reduces by construction to its inputs, and the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The analysis rests on the correctness and representativeness of the public Goldmont microcode dump, on the semantic accuracy of performance-counter measurements used to infer microcode behavior on cores without public dumps, and on the extrapolation of static not-taken prediction from five tested microarchitectures. No quantitative free parameters are fitted; all numbers are direct observations or derived from counter arithmetic. No new physical or microarchitectural entities are postulated; µSLH is a modification to existing microprograms, not a new component.

assumptions (4)
  • domain assumption The public Goldmont microcode disassembly by Ermolov et al. is accurate and representative of other Intel efficiency cores.
    All microprogram listings and vulnerability explanations for Goldmont derive from this dump. For Goldmont Plus, Tremont, and Gracemont the paper only infers similarity from matching micro-op counts on uops.info and does not verify control-flow structure directly (§2.3.1, §2.3.2).
  • domain assumption Conditional microcode branches are statically predicted not-taken on Intel microarchitectures beyond the five tested.
    Observation 1 generalizes from Goldmont, Goldmont Plus, Haswell, Kaby Lake, and Golden Cove to 'Intel cores'. The paper explicitly hedges this as high-confidence extrapolation (§3.3.1), but the reclassification of Rogue System Register Read and other attacks on untested cores depends on it.
  • domain assumption Performance-counter issue and retire counts unambiguously distinguish transiently issued micro-ops and reveal microcode branch structure.
    Used to infer cld's µbranch on all tested cores and div's two-path structure on Haswell. No control experiments for counter noise, interrupts, or other microarchitectural interference are reported (§3.3.1, §5.3).
  • domain assumption Intel's microcode patch for rdpmc, identified by comparing patched and unpatched firmware, is the effective cause of the PCIDX fix.
    The paper attributes the fix to the inserted SELECTcc micro-op (Figure 15) but cannot rule out other microcode changes or microarchitectural effects influencing the observed behavior (§6.2.3).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Analyzing and Exploiting Branch Mispredictions in Microcode." pith.science (2026). https://pith.science/paper/ET7LK6LJ

@misc{pith2026250112890,
  author       = {Pith},
  title        = {Pith review of: Analyzing and Exploiting Branch Mispredictions in Microcode},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ET7LK6LJ}},
  note         = {Machine review of arXiv:2501.12890}
}
read the original abstract

We present uSpectre, a new class of transient execution attacks that exploit microcode branch mispredictions to transiently leak sensitive data. We find that many long-known and recently-discovered transient execution attacks, which were previously categorized as Spectre or Meltdown variants, are actually instances of uSpectre on some Intel microarchitectures. Based on our observations, we discover multiple new uSpectre attacks and present a defense against uSpectre vulnerabilities, called uSLH.

Figures

Figures reproduced from arXiv: 2501.12890 by the authors.

Figure 1
Figure 1. Microprogram implementing cld on Goldmont, located at MSROM address U06d0 in Goldmont’s microcode disassembly [18]. We use CustomProcessingUnit [12] to ver￾ify this mapping. that it is statically (i.e., always) predicted not-taken. To prove this, we run nanobenchmark 2 “std; lfence” and nanobench￾mark 3 “std; lfence; cld.” By comparing the difference in issued/retired micro-ops between these two nanobench￾marks, we … view at source ↗
Figure 2
Figure 2. Structure of µSpectre-MEB (a) vulnerabilities and (b) attacks. 4 µSpectre Attacks We present µSpectre, a new class of transient execution at￾tacks that exploit transient execution following conditional µbranch mispredictions to leak sensitive or unauthorized data. Many existing Spectre and Meltdown attacks are ac￾tually instances of µSpectre attacks on some or all the Intel microarchitectures we study; we will discu… view at source ↗
Figure 3
Figure 3. Structure of µSpectre-MVI (a) vulnerabilities and (b) attacks. other MEB vulnerabilities, which allow subsequent macro￾ops to both transiently access and leak sensitive architec￾tural state (e.g., secret memory locations) that they otherwise would not. The variable idx represents any invalid data that (a) triggers the exception in the MEB-vulnerable macro-op and (b) is used to transiently access out-of-bounds secret… view at source ↗
Figures from the paper (13 more)
Figure 4
Figure 4. Figure 4: Structure of a µSpectre-MIL (a) vulnerabilities and (b) attacks. 4.4 µSpectre-MIL: Microcode-Internal Leaks The final µSpectre variant we consider is microcode-internal leaks, or µSpectre-MIL for short, in which a vulnerable micro￾program both transiently accesses (lin…
Figure 5
Figure 5. Figure 5: Transient execution attack classification tree, sim￾plified from prior work [14] and adapted to include µSpec￾tre and other Spectre variants that have been since discov￾ered [6, 7, 58]. Demonstrated attacks are in red. Presently inconclusive results are in gray. Bolded…
Figure 6
Figure 6. Figure 6: MEB-vulnerable microprogram implementing rdfsbase/rdgsbase on Goldmont. Register Read, i.e., µSpectre-MEB-REG: rdfsbase/rdgsbase, xgetbv, and rdpmc. By examining the microprograms im￾plementing them, we find that three of these implement privilege checks using a vulner…
Figure 7
Figure 7. Figure 7: MEB-vulnerable microprogram implementing xgetbv on Goldmont. instead transiently executes the rest of the microprogram and then subsequent attacker macro-ops as if CR4.FSGSBASE were set. The transiently executed attacker macro-ops can then leak the value of the FS/GS b…
Figure 8
Figure 8. Figure 8: MEB-vulnerable microprogram implementing rdpmc on Goldmont. Per our naming convention, we call this attack µSpec￾tre-MEB-OSXSAVE. xgetbv’s microprogram contains a sec￾ond conditional µbranch (line 5 in Figure 7a); however, this branch does not introduce any additional …
Figure 9
Figure 9. Figure 9: MEB-vulnerable microprogram implementing bound on Goldmont. Canella et al. concluded that both Meltdown-BND and Meltdown-MPX arise due to Meltdown-style lazy handling of the #BR exception. To evaluate these claims, we perform a case study on the Goldmont microarchitect…
Figure 10
Figure 10. Figure 10: Non-µSpectre-vulnerable microcode implement￾ing bndcn on Goldmont, which gives rise to Meltdown vari￾ant Meltdown-MPX [14]. checked against a 32-bit lower and upper bound stored at *m32 and *(m32+4), respectively. Goldmont’s microprogram implementing bound contains tw…
Figure 12
Figure 12. Figure 12: MIL-vulnerable microprogram implementing repne scasb on Goldmont, giving rise to µSpectre-MIL￾SCO. we conclude that the microprogram must taken one of two different control-flow paths. This implies the presence of a conditional µbranch that depends on the value of rdx…
Figure 13
Figure 13. Figure 13: MEB-vulnerable microprogram implementing into on Goldmont (simplified), giving rise to µSpectre-MEB￾OF (§6.1). exception. This branch is statically predicted not-taken (per Observation 1, §3.3.1) and thus allows transient execution of subsequent macro-ops despite an o…
Figure 14
Figure 14. Figure 14: a computes the physical performance counter in￾dex from the logical index provided in architectural regis￾ter rcx and assigns it to scratch register tmp3. To compute the address of the control register holding the performance counter data corresponding to the physical…
Figure 15
Figure 15. Figure 15: Intel’s mitigation of µSpectre-MEB-PCIDX on Goldmont, plus our extension 1 rdfsbase / rdgsbase r64 : 2 tmp0 = RDCREG64(CR4) 3 BT_UJMPNC(tmp0, 16, #GP) 4 tmp2 = RDSEG(FS/GS, BASE) 5 tmp2 = SELECTC(tmp0, tmp2) 6 r64 = ZEROEXTN(tmp2) 7 SEQW UEND0 8 9 # GP : 10 SIGEVENT (…
Figure 16
Figure 16. Figure 16: Our proposed µSLH mitigation for µSpectre-MEB￾SEGBASE transiently pass the corresponding control register’s data to subsequent macro-ops. To prevent this, we can simply insert a second conditional select directly following the second one (line 13).2 7.1.2 Mitigating R…
Figure 17
Figure 17. Figure 17: Our proposed µSLH mitigation for µSpectre-MVI￾ZDI. contain tight loops ( [PITH_FULL_IMAGE:figures/full_fig_p019_17.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

65 extracted references · 60 canonical work pages

  1. [1]

    https://www.amd.com/system/files/documents/security-analysis- predictive-store-forwarding.pdf , 2021

    Security analysis of amd predictive store forwarding. https://www.amd.com/system/files/documents/security-analysis- predictive-store-forwarding.pdf , 2021. Accessed: 2022-10-18

    work page 2021

  2. [2]

    uops.info: Characterizing latency, throughput, and port usage of instructions on intel microarchitectures

    Andreas Abel and Jan Reineke. uops.info: Characterizing latency, throughput, and port usage of instructions on intel microarchitectures. In ASPLOS, ASPLOS ’19, pages 673–686, New York, NY, USA, 2019. ACM

    work page 2019

  3. [3]

    nanobench: A low-overhead tool for running microbenchmarks on x86 systems

    Andreas Abel and Jan Reineke. nanobench: A low-overhead tool for running microbenchmarks on x86 systems. In 2020 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) , August 2020

    work page 2020

  4. [4]

    Predicting secret keys via branch prediction

    Onur Aciicmez, Jean-Pierre Seifert, and Cetin Kaya Koc. Predicting secret keys via branch prediction. IACR’06, 2006

    work page 2006

  5. [5]

    Port contention for fun and profit

    Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Ce- sar Pereida García, and Nicola Tuveri. Port contention for fun and profit. IACR’18, 2018

    work page 2018

  6. [6]

    Security analysis of amd predictive store forwarding

    AMD. Security analysis of amd predictive store forwarding. Whitepa- per, AMD, March 2021

    work page 2021

  7. [7]

    Techincal guidance for mitigating branch type confusion

    AMD. Techincal guidance for mitigating branch type confusion. Whitepaper, AMD, November 2022

    work page 2022

  8. [8]

    Andrysco, D

    M. Andrysco, D. Kohlbrenner, K. Mowery, R. Jhala, S. Lerner, and H. Shacham. On subnormal floating point and abnormal timing. In 2015 IEEE Symposium on Security and Privacy , 2015

    work page 2015

Show all 65 references
  1. [9]

    Straight-Line Speculation

    Arm. Straight-Line Speculation. Technical report, Arm, 2020. Ac- cessed: October 29, 2024

    2020

  2. [10]

    Acoustic side-channel attacks on printers

    Michael Backes, Markus Dürmuth, Sebastian Gerling, Manfred Pinkal, and Caroline Sporleder. Acoustic side-channel attacks on printers. 19th USENIX Security Symposium , 2010

    2010

  3. [11]

    Bernstein

    Daniel J. Bernstein. Cache-timing attacks on aes. Technical report, The University of Illinois at Chicago, 2005.https://cr.yp.to/antiforgery/ cachetiming-20050414.pdf

    2005

  4. [12]

    Customprocessingunit: Reverse engineering and customization of intel microcode

    Pietro Borrello, Catherine Easdon, Martin Schwarzl, Roland Czerny, and Michael Schwarz. Customprocessingunit: Reverse engineering and customization of intel microcode. In2023 IEEE Security and Privacy Workshops (SPW), pages 285–297. IEEE, 2023

    2023

  5. [13]

    Wenisch, Yu- val Yarom, and Raoul Strackx

    Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein, Thomas F. Wenisch, Yu- val Yarom, and Raoul Strackx. Foreshadow: Extracting the keys to the Intel SGX kingdom with transient out-of-order execution. 27th USENIX Security S...

    2018

  6. [14]

    A systematic evaluation of transient execution attacks and defenses

    Claudio Canella, Jo Van Bulck, Michael Schwarz, Moritz Lipp, Ben- jamin Von Berg, Philipp Ortner, Frank Piessens, Dmitry Evtyushkin, and Daniel Gruss. A systematic evaluation of transient execution attacks and defenses. In 28th USENIX Security Symposium (USENIX Security 19), p...

    2019

  7. [15]

    Speculative load hardening

    Chandler Carruth. Speculative load hardening. https://llvm.org/docs/ SpeculativeLoadHardening.html. Accessed: 2024-05-15

    2024

  8. [16]

    Intel® 64 and IA-32 Architectures Software Devel- oper’s Manual, 2024

    Intel Corporation. Intel® 64 and IA-32 Architectures Software Devel- oper’s Manual, 2024

    2024

  9. [17]

    glm-ucode

    Mark Ermolov, Maxim Goryachy, and Dmitry Sklyarov. glm-ucode. https://github.com/chip-red-pill/glm-ucode , 2020

    2020

  10. [18]

    ucodedisasm

    Mark Ermolov, Maxim Goryachy, and Dmitry Sklyarov. ucodedisasm. https://github.com/chip-red-pill/uCodeDisasm, 2024. Accessed: 2024- 05-18

    2024

  11. [19]

    Undocu- mented x86 instructions to control the cpu at the microarchitecture level in modern intel processors

    Mark Ermolov, Dmitry Sklyarov, and Maxim Goryachy. Undocu- mented x86 instructions to control the cpu at the microarchitecture level in modern intel processors. Journal of Computer Virology and Hacking Techniques, 19(3):351–365, 2023

    2023

  12. [20]

    Branchscope: A new side-channel attack on direc- tional branch predictor

    Dmitry Evtyushkin, Ryan Riley, Nael CSE Abu-Ghazaleh, ECE, and Dmitry Ponomarev. Branchscope: A new side-channel attack on direc- tional branch predictor. 23rd International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS) , 2018

    2018

  13. [21]

    Trans- lation Leak-aside Buffer: Defeating Cache Side-channel Protections with TLB Attacks

    Ben Gras, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida. Trans- lation Leak-aside Buffer: Defeating Cache Side-channel Protections with TLB Attacks. In USENIX Security’18, 2018. 19

    2018

  14. [22]

    Side-channel analysis of cryptographic software via early-terminating multiplications

    Johann Großschädl, Elisabeth Oswald, Dan Page, and Michael Tunstall. Side-channel analysis of cryptographic software via early-terminating multiplications. In ICISC’09, 2009

    2009

  15. [23]

    Cache games— bringing access-based cache attacks on AES to practice

    David Gullasch, Endre Bangerter, and Stephan Krenn. Cache games— bringing access-based cache attacks on AES to practice. 2011 IEEE Symposium on Security and Privacy (S&P) , 2011

    2011

  16. [24]

    Homma, T

    N. Homma, T. Aoki, and A. Satoh. Electromagnetic information leak- age for side-channel analysis of cryptographic modules. 2010 IEEE In- ternational Symposium on Electromagnetic Compatibility (EMC) , 2010

    2010

  17. [25]

    Speculative execution, variant 4: Speculative store by- pass, 2018

    Jann Horn. Speculative execution, variant 4: Speculative store by- pass, 2018. https://bugs.chromium.org/p/project-zero/issues/detail? id=1528

    2018

  18. [26]

    Rogue system register read / cve-2018-3640 / intel-sa-00115

    Intel Corporation. Rogue system register read / cve-2018-3640 / intel-sa-00115. https://www.intel.com/content/www/us/en/ developer/articles/technical/software-security-guidance/advisory- guidance/rogue-system-register-read.html , 2018. Accessed: 2024-05-14

    2018

  19. [27]

    Intel® 64 and IA-32 Architectures Optimization Reference Manual, 2021

    Intel Corporation. Intel® 64 and IA-32 Architectures Optimization Reference Manual, 2021. Available at: https://www.intel.com/content/ www/us/en/developer/articles/technical/intel-sdm.html

    2021

  20. [28]

    Earlier Generations of Intel ® 64 and IA-32 Processor Architectures, Throughput, and Latency, 2024

    Intel Corporation. Earlier Generations of Intel ® 64 and IA-32 Processor Architectures, Throughput, and Latency, 2024. Accessed: 2024-06-09

    2024

  21. [29]

    Instructions affected by rogue system register read

    Intel Corporation. Instructions affected by rogue system register read. https://www.intel.com/content/www/us/en/developer/articles/ technical/software-security-guidance/resources/instructions- affected-rogue-system-register-read.html , 2024. Accessed: 2024-05- 18

    2024

  22. [30]

    Dawg: A defense against cache timing attacks in speculative execution processors

    Vladimir Kiriansky, Ilia Lebedev, Saman Amarasinghe, Srinivas De- vadas, and Joel Emer. Dawg: A defense against cache timing attacks in speculative execution processors. In 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) , 2018

    2018

  23. [31]

    Speculative buffer over- flows: Attacks and defenses

    Vladimir Kiriansky and Carl Waldspurger. Speculative buffer over- flows: Attacks and defenses. CoRR, abs/1807.03757, 2018. http: //arxiv.org/abs/1807.03757

    2018 arXiv

  24. [32]

    Spectre attacks: Exploiting speculative execution

    Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, et al. Spectre attacks: Exploiting speculative execution. Communications of the ACM, 63(7):93–101, 2020

    2020

  25. [33]

    Kocher, Joshua Jaffe, and Benjamin Jun

    Paul C. Kocher, Joshua Jaffe, and Benjamin Jun. Differential power analysis. In CRYPTO’99, 1999

    1999

  26. [34]

    Khasawneh, Chengyu Song, and Nael B

    Esmaeil Mohammadian Koruyeh, Khaled N. Khasawneh, Chengyu Song, and Nael B. Abu-Ghazaleh. Spectre returns! Speculation attacks using the return stack buffer. 12th USENIX Workshop on Offensive Technologies (WOOT), 2018

    2018

  27. [35]

    Meltdown

    Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg. Meltdown. arXiv preprint arXiv:1801.01207, 2018

    2018 arXiv

  28. [36]

    A simple power-analysis (SPA) attack on imple- mentations of the aes key expansion

    Stefan Mangard. A simple power-analysis (SPA) attack on imple- mentations of the aes key expansion. 5th International Conference on Information Security and Cryptology (ICISC) , 2003

    2003

  29. [37]

    Fallout: Reading kernel writes from user space

    Marina Minkin, Daniel Moghimi, Moritz Lipp, Michael Schwarz, Jo Van Bulck, Daniel Genkin, Daniel Gruss, Frank Piessens, Berk Sunar, and Yuval Yarom. Fallout: Reading kernel writes from user space. arXiv preprint arXiv:1905.12701, 2019

    1905 arXiv

  30. [38]

    MemJam: A False Dependency Attack Against Constant-Time Crypto Implementations

    Ahmad Moghimi, Jan Wichelmann, Thomas Eisenbarth, and Berk Sunar. MemJam: A False Dependency Attack Against Constant-Time Crypto Implementations. International Journal of Parallel Program- ming, 47(4), 2019

    2019

  31. [39]

    Revizor: testing black-box cpus against speculation contracts

    Oleksii Oleksenko, Christof Fetzer, Boris Köpf, and Mark Silberstein. Revizor: testing black-box cpus against speculation contracts. In ASP- LOS ’22: 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Lausanne, Switzer- ...

    2022

  32. [40]

    Hide and seek with spectres: Efficient discovery of speculative infor- mation leaks with random testing

    Oleksii Oleksenko, Marco Guarnieri, Boris Köpf, and Mark Silberstein. Hide and seek with spectres: Efficient discovery of speculative infor- mation leaks with random testing. In2023 IEEE Symposium on Security and Privacy (SP), pages 1737–1752. IEEE, 2023

    2023

  33. [41]

    Cache attacks and countermeasures: The case of AES

    Dag Arne Osvik, Adi Shamir, and Eran Tromer. Cache attacks and countermeasures: The case of AES. 2006 The Cryptographers’ Track at the RSA Conference on Topics in Cryptology (CT-RSA) , 2006

    2006

  34. [42]

    DRAMA: Exploiting DRAM Addressing for Cross- CPU Attacks

    Peter Pessl, Daniel Gruss, Clémentine Maurice, Michael Schwarz, and Stefan Mangard. DRAMA: Exploiting DRAM Addressing for Cross- CPU Attacks. In USENIX Security’16, 2016

    2016

  35. [43]

    Rage against the machine clear: A systematic analysis of machine clears and their implications for transient execution attacks

    Hany Ragab, Enrico Barberis, Herbert Bos, and Cristiano Giuffrida. Rage against the machine clear: A systematic analysis of machine clears and their implications for transient execution attacks. In 30th USENIX Security Symposium (USENIX Security 21) , pages 1451–1468, 2021

    2021

  36. [44]

    I see dead 𝜇ops: Leaking secrets via intel/amd micro-op caches

    Xida Ren, Logan Moody, Mohammadkazem Taram, Matthew Jordan, Dean M Tullsen, and Ashish Venkat. I see dead 𝜇ops: Leaking secrets via intel/amd micro-op caches. In 2021 ACM/IEEE 48th Annual Inter- national Symposium on Computer Architecture (ISCA) , pages 361–374. IEEE, 2021

    2021

  37. [45]

    Sayakkara, Nhien-An Le-Khac, and Mark Scanlon

    Asanka P. Sayakkara, Nhien-An Le-Khac, and Mark Scanlon. A survey of electromagnetic side-channel attacks and discussion on their case- progressing potential for digital forensics. CoRR, abs/1903.07703, 2019

    1903 arXiv

  38. [46]

    Zombieload: Cross- privilege-boundary data sampling

    Michael Schwarz, Moritz Lipp, Daniel Moghimi, Jo Van Bulck, Julian Stecklina, Thomas Prescher, and Daniel Gruss. Zombieload: Cross- privilege-boundary data sampling. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security , pages 753–768, 2019

    2019

  39. [47]

    Spectre declassified: Reading from the right place at the wrong time

    Basavesh Ammanaghatta Shivakumar, Jack Barnes, Gilles Barthe, Sunjay Cauligi, Chitchanok Chuengsatiansup, Daniel Genkin, Sioli O’Connell, Peter Schwabe, Rui Qi Sim, and Yuval Yarom. Spectre declassified: Reading from the right place at the wrong time. In 2023 IEEE Symposium on...

    2023

  40. [49]

    Inception: Expos- ing new attack surfaces with training in transient execution

    Daniël Trujillo, Johannes Wikner, and Kaveh Razavi. Inception: Expos- ing new attack surfaces with training in transient execution. In 32nd USENIX Security Symposium (USENIX Security 23) , pages 7303–7320, 2023

    2023

  41. [50]

    Uhsadel, A

    L. Uhsadel, A. Georges, and I. Verbauwhede. Exploiting hardware performance counters. In 2008 5th Workshop on Fault Diagnosis and Tolerance in Cryptography, 2008

    2008

  42. [51]

    Lvi: Hijacking transient execution through microar- chitectural load value injection

    Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lippi, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss, and Frank Piessens. Lvi: Hijacking transient execution through microar- chitectural load value injection. In 2020 IEEE Symposium on Security and Pr...

    2020

  43. [52]

    Ridl: Rogue in-flight data load

    Stephan Van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Giorgi Maisuradze, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida. Ridl: Rogue in-flight data load. In 2019 IEEE Symposium on Security and Privacy (SP), pages 88–105. IEEE, 2019

    2019

  44. [53]

    Fletcher, and David Kohlbrenner

    Jose Rodrigo Sanchez Vicarte, Michael Flanders, Riccardo Paccagnella, Grant Garrett-Grossman, Adam Morrison, Christopher W. Fletcher, and David Kohlbrenner. Augury: Using data memory-dependent prefetchers to leak data at rest. In IEEE Symposium on Security and Privacy (SP). IE...

    2022

  45. [54]

    Opening pandora’s box: A systematic study of new ways microarchitecture can leak private data

    Jose Rodrigo Sanchez Vicarte, Pradyumna Shome, Nandeeka Nayak, Caroline Trippel, Adam Morrison, David Kohlbrenner, and Christo- pher W Fletcher. Opening pandora’s box: A systematic study of new ways microarchitecture can leak private data. In 2021 ACM/IEEE 48th Annual Internat...

    2021

  46. [55]

    Opening pandora’s box: A systematic study of new ways microarchitecture can leak private data

    Jose Rodrigo Sanchez Vicarte, Pradyumna Shome, Nandeeka Nayak, Caroline Trippel, Adam Morrison, David Kohlbrenner, and Christo- pher W Fletcher. Opening pandora’s box: A systematic study of new ways microarchitecture can leak private data. In 2021 ACM/IEEE 48th Annual Internat...

    2021

  47. [56]

    Wenhao Wang, Guoxing Chen, Xiaorui Pan, Yinqian Zhang, XiaoFeng Wang, Vincent Bindschaedler, Haixu Tang, and Carl A. Gunter. Leaky Cauldron on the Dark Land: Understanding Memory Side-Channel Hazards in SGX. In CCS ’17, 2017

    2017

  48. [57]

    In31st USENIX Security Symposium (USENIX Security 22) , pages 3825–3842, 2022

    Johannes Wikner and Kaveh Razavi.{RETBLEED}: Arbitrary specu- lative code execution with return instructions. In31st USENIX Security Symposium (USENIX Security 22) , pages 3825–3842, 2022

    2022

  49. [58]

    Phantom: Ex- ploiting decoder-detectable mispredictions

    Johannes Wikner, Daniël Trujillo, and Kaveh Razavi. Phantom: Ex- ploiting decoder-detectable mispredictions. In Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, pages 49–61, 2023

    2023

  50. [59]

    Y. Xu, W. Cui, and M. Peinado. Controlled-channel attacks: Deter- ministic side channels for untrusted operating systems. 2015 IEEE Symposium on Security and Privacy (S&P) , 2015

    2015

  51. [60]

    Attack Directories, Not Caches: Side Channel Attacks in a Non-Inclusive World

    Mengjia Yan, Read Sprabery, Bhargava Gopireddy, Christopher Fletcher, Roy Campbell, and Josep Torrellas. Attack Directories, Not Caches: Side Channel Attacks in a Non-Inclusive World. In IEEE S&P, 2019

    2019

  52. [61]

    In 23rd USENIX security symposium (USENIX security 14) , pages 719–732, 2014

    Yuval Yarom and Katrina Falkner.{FLUSH+ RELOAD}: A high res- olution, low noise, l3 cache{Side-Channel} attack. In 23rd USENIX security symposium (USENIX security 14) , pages 719–732, 2014

    2014

  53. [62]

    FLUSH+RELOAD: A high resolu- tion, low noise, L3 cache side-channel attack

    Yuval Yarom and Katrina Falkner. FLUSH+RELOAD: A high resolu- tion, low noise, L3 cache side-channel attack. 23rd USENIX Security Symposium, 2014

    2014

  54. [63]

    CacheBleed: A Timing Attack on OpenSSL Constant Time RSA

    Yuval Yarom, Daniel Genkin, and Nadia Heninger. CacheBleed: A Timing Attack on OpenSSL Constant Time RSA. IACR’16, 2016

    2016

  55. [64]

    Speculative taint tracking (stt) a comprehensive protection for speculatively accessed data

    Jiyong Yu, Mengjia Yan, Artem Khyzha, Adam Morrison, Josep Tor- rellas, and Christopher W Fletcher. Speculative taint tracking (stt) a comprehensive protection for speculatively accessed data. In Pro- ceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchite...

    2019

  56. [65]

    Ultimate{SLH}: Taking speculative load hardening to the next level

    Zhiyuan Zhang, Gilles Barthe, Chitchanok Chuengsatiansup, Peter Schwabe, and Yuval Yarom. Ultimate{SLH}: Taking speculative load hardening to the next level. In 32nd USENIX Security Symposium (USENIX Security 23), pages 7125–7142, 2023. 21

    2023

  57. [2018]

    http://arxiv.org/abs/1806.07480

    arXiv

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.