One Flew over the Stack Engine’s Nest: Practical Microarchitectural Attacks on the Stack Engine

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The authors present a detailed microarchitectural analysis of the stack engine, a frontend optimization in modern x86 CPUs from Intel and AMD. They reverse engineer its behavior, focusing on the conditions that trigger a synchronization uop, namely unsupported operations and stack depth overflows. Based on these findings, they construct three leakage primitives and demonstrate their use in same-thread and cross-thread covert channels, as well as side-channel attacks against the cJSON and protobuf libraries. Finally, they identify and analyze undocumented MSRs ("chicken bits") on recent AMD CPUs that can disable the stack engine, measuring the performance impact of this mitigation. While the level of detail in the reverse engineering is commendable, the work suffers from questionable measurement reliability, a potentially contrived threat model, and claims that may not be fully substantiated by the provided evidence.

Strengths

1. Comprehensive Microarchitectural Analysis: The paper provides an impressively detailed investigation of the stack engine's behavior across a wide range of modern Intel and AMD microarchitectures, from Sandy Bridge to Zen 5. The systematic approach to characterizing properties like ARSP depth (Section 5.4) and support for add/sub (Section 5.5) is thorough.

2. Mitigation Analysis: The discovery and experimental validation of the undocumented MSRs on AMD Zen 4 and Zen 5 to control the stack engine (Section 9.1) is a significant finding. Measuring the real-world performance impact using SPEC CPU2017 provides a valuable data point on the trade-off between performance and security for this specific optimization.

Weaknesses

1. Unreliable Measurements Undermine Core Observations: The foundation of this paper—the reverse engineering in Section 5—appears to be built on a shaky measurement methodology. The authors frequently acknowledge measurement issues, such as "performance counter inaccuracies" and "high jitter" on Intel CPUs (caption of Figure 4, page 7), and "excessive noise" preventing a conclusive analysis of speculative execution (Section 5.7, page 8). Most concerningly, when key observations contradict their model (e.g., the lack of a sync uop on Golden Cove and Zen 1), they dismiss it as a "performance counter bug" (Section 5.2, page 6) without providing concrete evidence to support this claim. This is a critical weakness. An alternative and equally plausible explanation is that the hardware behaves differently, which would invalidate the generality of their findings and the primitives built upon them. The burden of proof is on the authors to demonstrate that these are measurement errors, not fundamental behavioral differences.

2. Questionable Novelty and Robustness of Attack Techniques:

   • The "new port contention technique" for cross-thread leakage (Section 7.2, page 10) is poorly motivated and described. The authors claim prior methods are insufficient for single-cycle uops but describe their solution as creating a dependency chain to delay execution. This is a standard approach to amplify contention signals, not a novel technique. The lack of a clear, formal description or a rigorous comparison against prior work makes the claim of novelty unsubstantiated.
   • The attack primitives themselves show a lack of generality. The Sync+Reload primitive is rendered ineffective on Zen 5, the latest AMD architecture, because sync uops are dispatched unconditionally (Section 5.2). This forces the authors to develop a more complex Prime+Sync+Probe primitive. This suggests a fragmented and architecture-specific set of leakage methods rather than a universal principle.

3. Contrived Threat Model and Fragile Attacks: The practicality of the demonstrated side-channel attacks is debatable.

   • The cJSON attack (Section 8.1) requires an attacker within the same address space to repeatedly invoke a parsing function on the same secret data but at different start offsets. This seems like a highly specific and unlikely scenario in a real-world setting like the FaaS environment described. A strong justification for the realism of this attack vector is missing.
   • The protobuf attack (Section 8.2) is admitted to only work when default compiler optimizations (which use vector instructions that reset the stack engine) are not used. It relies on a specific *__get_packed_size function. This makes the attack fragile and opportunistic, rather than a general threat to applications using protobuf. The paper fails to argue for the prevalence of such vulnerable code patterns in real-world software.

4. Overstated Claims: The abstract claims this work is the "first reverse engineering of the stack engine." This overstates the contribution. The existence and basic function of the stack engine have been known and described in public documents, including Agner Fog's optimization manuals [18], for years. While this paper provides a much deeper security-focused analysis, it is not the first reverse engineering. This should be rephrased for accuracy.

Questions to Address In Rebuttal

1. Regarding the claim of a "performance counter bug" on Golden Cove and Zen 1 (Section 5.2), what evidence can you provide to prove that a sync uop is indeed dispatched but simply not counted, as opposed to not being dispatched at all? Without this proof, how can you be confident in the universality of your Sync+Reload primitive?

2. Please formalize your "new dispatch alignment technique" (Section 7.2). How does it fundamentally differ from established techniques that use dependency chains to amplify contention for measurement? Please provide a more rigorous comparison to prior work like that of Aldaya et al. [3].

3. Could you elaborate on a more concrete and plausible end-to-end attack scenario for the cJSON side channel (Section 8.1)? Specifically, how would an attacker in a realistic in-process sandboxing environment gain the ability to repeatedly trigger the victim's parsing function on the same data with byte-level control over the starting offset?

4. Given that one of your main primitives (Sync+Reload) does not work on the latest AMD CPUs and your demonstrated attacks rely on non-default compiler flags (protobuf) or a highly specific invocation pattern (cJSON), do you believe your work demonstrates a widespread, practical threat, or rather a narrow, opportunistic one? Please justify your assessment.

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper presents a comprehensive, end-to-end investigation of the CPU stack engine—a long-standing but under-examined microarchitectural optimization—as a novel source of information leakage. The authors conduct a meticulous reverse engineering of the stack engine's behavior across a wide range of modern AMD and Intel processors, identifying the precise conditions that trigger synchronization events. Building on this foundational understanding, they construct a set of powerful leakage primitives. These primitives are then leveraged to build practical covert and side channels, culminating in a high-fidelity attack that exfiltrates structural information from a widely-used JSON parsing library, thereby leaking sensitive data. Crucially, the work does not stop at exploitation; the authors discover and verify undocumented "chicken bits" in recent AMD CPUs that can disable the stack engine, and they provide a sober analysis of the ~4% performance cost this mitigation incurs. This is a foundational piece of work that systematically transforms a seemingly benign performance optimization into a fully understood security liability.

Strengths

This paper has several significant strengths that place it firmly in the upper echelon of microarchitectural security research.

1. Novelty and Significance of the Target: While the community has spent years dissecting caches, branch predictors, and speculative execution, the stack engine has remained largely unexplored from a security perspective. This work is, to my knowledge, the first to subject it to a rigorous security analysis. By doing so, it opens up a new avenue of inquiry into how fundamental frontend optimizations can create security vulnerabilities, broadening the attack surface beyond the more commonly studied CPU components.

2. Methodological Rigor and Breadth: The authors’ approach is exceptionally thorough. The reverse engineering effort detailed in Section 5 (pages 5-8) is impressive, spanning multiple generations and architectures from both Intel and AMD. This provides a valuable comparative view and demonstrates that the vulnerability is not an isolated design flaw but an emergent property of a widely adopted optimization. The progression from reverse engineering to primitive-building to a full-fledged attack is logical and compelling.

3. A Complete "Vulnerability Lifecycle" Analysis: This is perhaps the paper’s greatest strength. It does not simply present an attack; it presents the entire story. It begins with curiosity about a microarchitectural feature, moves to deep understanding, demonstrates a practical exploit, and, most importantly, provides a concrete, hardware-verified mitigation. The discovery and functional analysis of the undocumented MSR bits in Section 9.1 (page 12) is a standout contribution, turning the paper from an offensive security work into a balanced and constructive piece of systems research. The performance evaluation of the mitigation provides the final, critical data point needed for CPU architects to make informed trade-off decisions.

4. Bridging Low-Level Primitives to High-Level Impact: The attack on the cJSON library (Section 8.1, page 11) is an excellent case study. It skillfully connects an esoteric microarchitectural effect (a sync uop being dispatched due to ARSP overflow) to a tangible security outcome (distinguishing between patient records based on the structure of parsed data). This demonstration is crucial for showing that the identified leakage channel is not merely theoretical but poses a genuine risk to real-world software.

Weaknesses

The weaknesses of this paper are minor and relate more to missed opportunities for contextualization than to flaws in the work itself.

1. Limited Contextualization within the Landscape of Frontend Attacks: The paper correctly identifies itself as a frontend attack in Section 10 (page 13). However, it could do more to position the stack engine channel relative to other known frontend channels (e.g., from the uop cache, Loop Stream Detector, or branch predictors). A brief discussion on the comparative properties—for instance, is the stack engine channel stealthier due to its transient nature? Is it lower or higher bandwidth? Is it more or less noisy than, say, a uop cache-based channel?—would help readers better situate this new vector within the broader taxonomy of microarchitectural threats.

2. Could Further Generalize the Underlying Principle: The paper correctly notes in Section 5.9 (page 8) that architectures like ARM and RISC-V do not require a stack engine due to their different ISA idioms. This is an important distinction. However, the underlying principle is that a performance optimization designed to handle a common software idiom (in this case, x86's push/pop stack management) creates state that can be leaked. The paper could strengthen its intellectual contribution by briefly speculating on whether analogous "idiom-specific" frontend optimizations in other ISAs might create similar, currently undiscovered, leakage vectors. This would elevate the core idea from an x86-specific finding to a more general principle of microarchitectural security.

Questions to Address In Rebuttal

1. The discovery of the MSR "chicken bits" is a fantastic contribution. Can the authors elaborate, even briefly, on the methodology used to find them? Was this the result of a brute-force MSR scan, or were there clues in documentation, patents, or kernel patches that pointed them in the right direction? Understanding this process could be valuable for other researchers.

2. How does the stack engine channel compare to other non-speculative, frontend channels in terms of its key properties? Specifically, considering a sophisticated defender, would this channel be considered more or less difficult to detect than a channel based on, for example, uop cache contention?

3. The paper makes a compelling case for the vulnerability of the stack engine in x86. Thinking more broadly, do the authors believe that the general principle—that stateful frontend optimizations for common software idioms are a ripe target for side channels—is applicable to other architectures? Could they provide a hypothetical example of what such an optimization and vulnerability might look like on an architecture like ARM or RISC-V?

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

This paper presents a systematic reverse engineering and security analysis of the "stack engine," a microarchitectural optimization in modern x86 CPUs that tracks the stack pointer (RSP) in the frontend to improve instruction-level parallelism. The authors characterize the behavior of this engine across a wide range of recent Intel and AMD microarchitectures, identifying its internal state (ARSP), its tracking depth, and the conditions that trigger a synchronization with the architectural RSP in the backend.

Based on these novel insights, the authors construct three new attack primitives (Direct Underflow, Sync+Reload, Prime+Sync+Probe) that exploit the stack engine's state to leak information. They demonstrate these primitives by building covert channels and a side-channel attack against the cJSON parsing library. Finally, they discover and analyze undocumented MSR "chicken bits" in recent AMD CPUs that can disable the stack engine, providing a mitigation and a way to quantify its performance impact.

The core novelty of this work lies in being the first to deeply investigate, characterize, and weaponize the stack engine as a source for information leakage. While the attack patterns are analogous to prior work in other domains (e.g., caches), the target, the channel, and the specific mechanisms are entirely new.

Strengths

1. Novelty of the Target Microarchitectural Unit: The primary strength of this paper is its focus on a previously unexamined microarchitectural component for security analysis. While the existence of stack pointer tracking is known in principle (citing Bekerman et al. [8] from 2000), this paper provides the first-ever detailed, empirical reverse engineering of its modern implementations (Section 5, pages 5-8). The characterization of properties like tracking depth (Figure 4, page 7), conditions for synchronization (Section 5.2, page 5), and support for add/sub (Section 5.5, page 7) across multiple generations of AMD and Intel CPUs is a significant and novel contribution to the community's understanding of the x86 frontend.

2. Novel Primitives Derived from First Principles: The attack primitives are not generic; they are meticulously derived from the specific behaviors uncovered during the reverse engineering phase. For example, Prime+Sync+Probe directly exploits the finite capacity of the internal ARSP register and the observable synchronization event on overflow. This tight coupling between reverse engineering and exploit development is a hallmark of high-quality microarchitectural security research. This represents the first time such stateful tracking in the stack engine has been exploited.

3. Novel Observation Technique for a Difficult Signal: The authors correctly identify that the signal from the stack engine—a single-cycle, independent ALU operation—is difficult to observe, especially cross-thread, and that prior port contention techniques [3, 23] are insufficient. Their development of a "tuned" port contention method with a dependency to align execution windows (Section 7.2, pages 10-11) is a subtle but important novel contribution in its own right, enabling the observation of this new class of faint signals.

4. Novel Discovery of Undocumented Mitigations: The discovery and characterization of undocumented "chicken bits" in AMD Zen 4 and Zen 5 CPUs to control the stack engine (Section 9.1, page 12) is a concrete and novel finding. This is not simply an application of existing knowledge but a genuine discovery that provides an immediate mitigation path and allows for a precise performance evaluation of the targeted feature.

Weaknesses

1. Conceptual Analogy to Existing Attack Patterns: While the target and mechanism are novel, the conceptual framework of the Prime+Sync+Probe primitive is a direct analogue to the classic Prime+Probe cache attack. The pattern is: (1) put the microarchitectural structure into a known state (prime), (2) let the victim execute, (3) check the state to see if the victim's activity changed it (probe). The paper should more explicitly position its contribution not as the invention of a new attack pattern, but as the novel discovery that the stack engine constitutes a previously unknown structure susceptible to this pattern.

2. The Demonstration is an Application, Not a Core Novelty: The successful attack on the cJSON library (Section 8.1, page 11) is an excellent demonstration of the primitives' effectiveness. However, from a novelty standpoint, this is an application of the core ideas rather than a new idea in itself. The core contribution remains the identification and exploitation of the stack engine, not the specific finding in a downstream software library.

Questions to Address In Rebuttal

1. The Prime+Sync+Probe primitive is functionally analogous to cache-based Prime+Probe. Can the authors elaborate on the non-trivial aspects of adapting this conceptual pattern to the stack engine's ARSP register? For instance, how does the non-cache-like, single-value nature of the ARSP state fundamentally differ from the set-based state of a cache during an attack?

2. In Section 5.7 ("Stack engine under speculation"), you confirm that sync operations are observable under transient execution but conclude that an attack "would only slightly expand the capabilities of a cross-thread attacker." This conclusion seems understated. Could a transient execution attack based on the stack engine enable leakage scenarios not possible with existing speculative attack primitives? Please clarify if there is a genuinely novel transient attack vector here that has been downplayed.

3. Your reverse engineering covers a wide range of x86 CPUs. You briefly state that ARM and RISC-V lack a stack engine due to their ISA design (Section 5.9, page 8). Are you aware of any analogous frontend optimizations in other non-x86 architectures that track register state (not just the stack pointer) in a similar stateful, finite-capacity manner that could be susceptible to the new class of primitives you have developed?