{"id":"5ae8d091-d90a-4c7d-9861-c445b2e600fe","arxiv_id":"2501.12890","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"µSpectre is a new class of transient execution attacks that exploits statically-not-taken microcode branches in Intel CPUs, reclassifies known attacks, and adds a microcode defense.","lead":"This paper shows that Intel chips' internal microcode branches sometimes guess wrong, and these wrong guesses can briefly leak secret data. Some well-known Spectre and Meltdown attacks turn out to be this new µSpectre class, and the authors propose a microcode fix.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The scope of the µSpectre class rests on a one-instruction inference of static not-taken µbranch prediction beyond Goldmont; if that inference fails, the reclassifications and cross-core claims fall.","rationale":"The Goldmont demonstrations are independently strong: Ermolov et al.'s public microcode, the cld issue/retire counts, the microcode-patch verification of unconditional branch behavior, and the PCIDX control-register leak with Intel's own patch as existence proof. I therefore would not argue for rejection. The concern that lands is narrower but load-bearing for the paper's stated scope: Observation 1 is stated as a property of \"Intel cores\" (§3.3.1) and is used in §5 to reclassify prior attacks. The evidence outside Goldmont is the single cld instruction, and the paper explicitly flags its uncertainty. That is exactly the kind of self-reported limitation the review should weigh. The concrete test above would either strengthen the generalization or expose it as unsupported. The reader's weakest_assumption pointed to the same generalization; I agree, with the added observation that the cld predicate is special (DF is serializing and non-renamable), so even the \"similar results on all other cores\" statement may not cover ordinary data-dependent µbranches. Verdict remains CONDITIONAL: accept the Goldmont result conditionally, but require either broader cross-core evidence or a scoped claim. I do not elevate the missing-artifact concern over this one because the mechanism is otherwise specified with enough detail to reproduce on Goldmont; the cross-core inference is the place where the argument's reach exceeds its evidence.","tokens_in":28288,"tokens_out":10847,"duration_ms":111186,"concrete_test":"Run the cld-style nanobenchmark on Goldmont Plus, Haswell, Kaby Lake, and Golden Cove for several additional microcoded instructions with qualitatively different µbranch predicates, e.g., into (OF), rdpmc (CR4.PCE and index bounds), div (rdx-dependent), and repne scasb (loop and comparison branches), measuring IDQ.MS_UOPS/UOPS_RETIRED deltas under taken and not-taken conditions. If the issue/retire signatures across all instructions are consistent with a single static not-taken policy, the generalization gains support; if any instruction shows a divergent signature (e.g., no transient excess issue when the taken path is required, or a signature matching dynamic prediction), Observation 1 is falsified and the cross-core claims must be retracted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central existence claim is supported on Goldmont. The load-bearing weakness is Observation 1's extension beyond Goldmont. The only direct cross-core evidence is the cld nanobenchmark in §3.3.1, which checks one conditional direct µbranch whose predicate is DF, a non-renamable, serializing flag; on cores with no public microcode the 17/13 issue/retire delta is attributed to a statically not-taken µbranch by analogy to Goldmont. 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.\" That is plausibility, not evidence. The same gap underlies the reclassification of ZDI on Haswell in §5.3, which infers the entire div microprogram structure from 39/49 vs 61/49 issue/retire counts, and the claim of a 22-macro-op window on Goldmont Plus in §3.4, reported without supporting traces. If some non-Goldmont cores use per-branch static prediction, dynamic prediction for some µbranches, or different recovery timing, then the paper's taxonomy-level claims and the reclassification of known attacks are unsupported, although the Goldmont attacks could remain valid.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":28436,"tokens_out":4959,"duration_ms":48407,"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":[{"comment":"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.","section":"§3.3.1, Observation 1"},{"comment":"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.","section":"§5.3, Figure 11"},{"comment":"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.","section":"§3.4, Observation 2"},{"comment":"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.","section":"§6.1 and §6.3"}],"minor_comments":[{"comment":"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.","section":"§4.4"},{"comment":"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.","section":"Throughout"},{"comment":"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'.","section":"§5.1.1"},{"comment":"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.","section":"Figure 5"},{"comment":"References [54] and [55] are identical (same title, authors, and venue); one should be removed or the numbering corrected.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The Goldmont results are solid and publishable, but the paper currently frames unproven cross-core generalizations as established results. I recommend a major revision that narrows the title/abstract claims to demonstrated findings and clearly separates hypotheses from evidence. The paper would also benefit from a reproducibility appendix with the nanobenchmark code and raw counter values for the transient-window measurements."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The one thing you should know: the paper's core existence claim is demonstrated on Goldmont, and that alone is a real result. Using the public microcode, the authors show that conditional microcode branches are statically predicted not-taken and that mispredictions create transient windows spanning many macro-ops. The rdpmc-based leak of architecturally inaccessible control registers (µSpectre-MEB-PCIDX) is a concrete proof of concept and, to my knowledge, new. They also document things nobody else had: window sizes, out-of-order detection with in-order retirement, and the fact that indirect µbranches are not predicted. Credit where due: the Goldmont microprogram analysis is careful, the cld nanobenchmark is clever, and the paper is unusually honest about what is and is not demonstrated. The µSLH defense is a sensible idea and plausibly deployable via microcode updates.\n\nThe soft spots are real but localized. The broad claim that all Intel cores statically predict conditional µbranches not-taken rests on a one-instruction inference from the cld nanobenchmark on non-Goldmont cores. The paper itself says 'we cannot be certain' and then leans on 'we see no reason why Intel would make this opposite design choice.' That is plausibility, not evidence, and the same gap underlies the Haswell ZDI reclassification (inferred from 39/49 vs 61/49 issue/retire counts) and the 22-macro-op window on Goldmont Plus (reported without traces). Some new vulnerabilities—MEB-OF and the cld/arpl/enter MVI primitives—are asserted without demonstrated leaks. The paper also ships no code or data artifacts, which hurts reproducibility for the performance-counter measurements.\n\nNone of this overturns the Goldmont result. The mechanism is real, and the PCIDX leak is a serious finding regardless of what other cores do. But the taxonomic sweep and the 'µSpectre on all Intel cores' framing currently outrun the evidence. The paper would be stronger if it either narrowed the scope claims to Goldmont or backed the cross-core inferences with more than one instruction and a hope about Intel's design philosophy.\n\nBottom line: this deserves a serious referee. Send it out, but require artifacts and either more cross-core measurements or a modest rewrite that separates 'demonstrated on Goldmont' from 'inferred elsewhere.' The central mechanism should survive review; the scope claims need to be disciplined.","headline":"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.","tokens_in":29049,"tokens_out":1196,"would_cite":true,"duration_ms":14690,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Mispredicted branches inside Intel microcode can bypass privilege checks and leak secrets.","keywords":["microcode","transient execution","µSpectre","microcode branch misprediction","Intel Goldmont","speculative execution","Rogue System Register Read","µSLH"],"falsifier":"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.","tokens_in":27996,"feed_emoji":"🔓","tokens_out":7988,"duration_ms":76677,"temperature":0.7,"pith_summary":"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.","feed_headline":"Microcode branch mispredictions leak data on Intel CPUs","feed_subtitle":"Intel's own microcode branches can be mispredicted, letting unprivileged code read protected data and internal registers","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the public Goldmont microcode dump and disassembler from which the paper's microprogram listings are taken.","marker":"[18]"},{"why":"Documents the Goldmont µbranch types and microsequencer directives that the paper's characterization builds on and partly refines.","marker":"[19]"},{"why":"Provides the nanobenchmark harness used to measure micro-op issue and retirement counts for the prediction experiments.","marker":"[3]"},{"why":"The microcode tracing technique adapted to verify which microprogram implements a given macro-op.","marker":"[12]"},{"why":"The transient-execution taxonomy the paper extends; also the source of the Meltdown-BND and Meltdown-MPX classifications being tested.","marker":"[14]"},{"why":"Intel's Rogue System Register Read advisory, the long-known vulnerability reclassified as µSpectre-MEB-REG.","marker":"[26]"},{"why":"Reports Zero Dividend Injection and String Comparison Overrun, which the paper reclassifies as µSpectre-MVI-ZDI and µSpectre-MIL-SCO.","marker":"[40]"},{"why":"Speculative load hardening, the defense whose pattern inspires µSLH.","marker":"[15]"},{"why":"The instruction-level micro-op counts used to infer that microcode is shared across efficiency cores and that the tested instructions are microcoded.","marker":"[2]"},{"why":"Intel's list of instructions affected by Rogue System Register Read, used to scope which remaining attacks likely share the µSpectre-MEB root cause.","marker":"[29]"}],"fun_headline_variants":["Microcode branch mispredictions leak CPU secrets","uSpectre: New attacks via microcode mispredictions","Intel microcode bug lets attacks bypass checks","Mispredicted microcode branches expose data"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Microcode branch mispredictions leak CPU secrets","uSpectre: New attacks via microcode mispredictions","Intel microcode bug lets attacks bypass checks","Mispredicted microcode branches expose data"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000482,"raw_usage":{"total_tokens":2338,"prompt_tokens":857,"completion_tokens":1481,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":473,"completion_tokens_details":{"reasoning_tokens":1429}},"tokens_in":473,"tokens_out":1481,"duration_ms":10983,"temperature":1.0,"reasoning_tokens":1429,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T16:41:01.585581+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"ucodedisasm","cited_arxiv_id":null,"evidence_quote":"Supplies the public Goldmont microcode dump and disassembler from which the paper's microprogram listings are taken."},{"cited_title":"Undocu- mented x86 instructions to control the cpu at the microarchitecture level in modern intel processors","cited_arxiv_id":null,"evidence_quote":"Documents the Goldmont µbranch types and microsequencer directives that the paper's characterization builds on and partly refines."},{"cited_title":"nanobench: A low-overhead tool for running microbenchmarks on x86 systems","cited_arxiv_id":null,"evidence_quote":"Provides the nanobenchmark harness used to measure micro-op issue and retirement counts for the prediction experiments."},{"cited_title":"Customprocessingunit: Reverse engineering and customization of intel microcode","cited_arxiv_id":null,"evidence_quote":"The microcode tracing technique adapted to verify which microprogram implements a given macro-op."},{"cited_title":"A systematic evaluation of transient execution attacks and defenses","cited_arxiv_id":null,"evidence_quote":"The transient-execution taxonomy the paper extends; also the source of the Meltdown-BND and Meltdown-MPX classifications being tested."},{"cited_title":"Rogue system register read / cve-2018-3640 / intel-sa-00115","cited_arxiv_id":null,"evidence_quote":"Intel's Rogue System Register Read advisory, the long-known vulnerability reclassified as µSpectre-MEB-REG."},{"cited_title":"Hide and seek with spectres: Efficient discovery of speculative infor- mation leaks with random testing","cited_arxiv_id":null,"evidence_quote":"Reports Zero Dividend Injection and String Comparison Overrun, which the paper reclassifies as µSpectre-MVI-ZDI and µSpectre-MIL-SCO."},{"cited_title":"Speculative load hardening","cited_arxiv_id":null,"evidence_quote":"Speculative load hardening, the defense whose pattern inspires µSLH."},{"cited_title":"uops.info: Characterizing latency, throughput, and port usage of instructions on intel microarchitectures","cited_arxiv_id":null,"evidence_quote":"The instruction-level micro-op counts used to infer that microcode is shared across efficiency cores and that the tested instructions are microcoded."},{"cited_title":"Instructions affected by rogue system register read","cited_arxiv_id":null,"evidence_quote":"Intel's list of instructions affected by Rogue System Register Read, used to scope which remaining attacks likely share the µSpectre-MEB root cause."}],"review_version":1}