Fuzzilicon: A Post-Silicon Microcode-Guided x86 CPU Fuzzer

Fuzzilicon: A Post-Silicon Microcode-Guided x86 CPU Fuzzer

Speakers: Johannes Lenzen

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=J_tOKcp_wDg

Overview

CPU vulnerabilities like Downfall, Meltdown, Spectre, ZombieLoad, and RIDL have caused enormous damage, with Intel spending hundreds of millions on recalls. This talk presents Fuzzilicon, the NDSS 2026 Best Paper Award winner and the first automated post-silicon x86 CPU fuzzer with microcode-level visibility. By leveraging Intel's red unlock mode (a debug interface) to instrument microcode execution, Fuzzilicon achieves what was previously impossible in black-box hardware fuzzing: coverage-guided exploration of microarchitectural states. The system introduces a microcode coverage bitmap, a serialization oracle for detecting speculative execution vulnerabilities via differential testing, and a bare-metal hypervisor for deterministic test isolation.

Fuzzilicon discovered 5 new findings on Intel x86 CPUs, including a microcode-level Spectre variant detected automatically (previously only found manually), speculative writes to CSR bars leaving zombie states, speculative microcode writes to segment selector caches, speculative execution suppression bugs, and speculative micro-ops leaving traces in performance counters. The microcode-guided approach achieves 31x speedup over baseline instrumentation.

Background

▶ Watch: CPU vulnerabilities landscape and the post-silicon challenge (0:00)

CPU vulnerability detection faces a fundamental visibility gap. Pre-silicon approaches analyze RTL code (available for open-source designs like RISC-V) but miss real-world behaviors, modern CPU optimization features, and production-scale complexity. Post-silicon approaches test real hardware but face the black-box problem: commercial x86 CPUs provide no insight into microarchitectural state, making coverage-guided fuzzing infeasible.

The landscape reveals a stark asymmetry: of approximately 20 CPU fuzzing methods surveyed, 16 target open-source CPUs (primarily RISC-V) using pre-silicon evaluation with RTL access. Only 4 (including Fuzzilicon) target post-silicon real hardware. The academic RISC-V designs are simplified and lack the advanced optimization features (out-of-order execution, speculative execution, complex pipelines) that create the vulnerability surface in production Intel/AMD processors.

Microcode is the key insight. Complex x86 instructions are decomposed into sequences of micro-operations (micro-ops) stored in microcode ROM. For example, the RDRAND instruction (hardware random number generation) decomposes into multiple micro-ops including conditional branches. Intel provides mechanisms to update microcode via hook tables that redirect execution from ROM to RAM, enabling post-manufacture bug fixes. Fuzzilicon repurposes this microcode update mechanism for security instrumentation.

Key Findings

▶ Watch: Fuzzilicon overview: microcode coverage, serialization oracle, hypervisor (4:00)

• 5 new findings on Intel x86 CPUs:

1. Microcode-level Spectre variant: Automatically discovered; previous work required manual analysis
2. Speculative writes to CSR bars: Failed speculative execution rolls back architectural state but leaves data in CSR bars as zombie state, exploitable in later phases
3. Speculative writes to segment selector caches: Microcode speculatively writes to selector caches that persist after rollback
4. Speculative execution suppression: Certain instructions under speculative execution stop further speculation in subsequent instructions
5. Performance counter traces: Speculative micro-ops leave observable traces in hardware performance counters that attackers could leverage as side channels

• 31x speedup over baseline microcode instrumentation through static analysis optimization
• Best Paper Award at NDSS 2026
• First post-silicon x86 fuzzer with microarchitectural visibility: Bridging the gap between pre-silicon RTL analysis and post-silicon black-box testing
• Coverage feedback helps: Contradicting a USENIX Security 2025 paper that claimed hardware fuzzing doesn't benefit from feedback, Fuzzilicon shows that microcode coverage feedback leads to better state exploration
• Random corpus outperforms valid corpus: Random initial instruction sequences achieve higher microcode coverage than valid programs, because valid programs constrain the fuzzer to existing execution paths

Technical Deep Dive

▶ Watch: Coverage bitmap design and instrumentation optimization (31x speedup) (8:00)

Fuzzilicon operates on Intel CPUs in red unlock mode -- a debug mode normally available only to Intel engineers that provides deep microarchitectural visibility. Following prior work, the researchers unlock this mode on target CPUs.

Microcode Coverage Bitmap: Treating microcode as software, Fuzzilicon creates a bit vector where each bit represents one micro-op. Using the hook table mechanism, instrumentation code is inserted before target micro-ops. When a micro-op executes, its corresponding bit is set. This provides coverage feedback analogous to AFL's edge coverage for software fuzzing, but at the microarchitectural level.

Instrumentation Optimization: With 32,000 micro-ops but only 32 available hook slots, naive instrumentation is infeasible. Fuzzilicon performs static analysis to classify micro-ops into two types:

• Sequential micro-ops: Always execute the next micro-op in sequence. Only one instrumentation point needed for the entire sequence.
• Branching micro-ops: Execute different paths based on conditions. Require instrumentation at each branch target.

This reduces instrumentation overhead from one-per-micro-op to a much smaller set, achieving the 31x speedup.

Serialization Oracle: To detect speculative execution vulnerabilities, Fuzzilicon runs each test case twice in parallel VMs:

• Normal execution: Instructions execute with full speculative execution
• Serialized execution: Memory fences (LFENCE/MFENCE) are inserted between every instruction, preventing speculation

If the hardware state differs between the two executions, a speculative execution anomaly has been detected. This is a powerful differential testing oracle that doesn't require manual specification of expected behavior.

Bare-Metal Hypervisor Isolation: A custom hypervisor ensures each test case starts from a clean, deterministic hardware state. The hypervisor reinitializes all hardware state between test cases, eliminating persistent side effects and making execution deterministic -- critical for reproducible bug finding.

Fuzzing Loop: The complete pipeline: seed corpus mutation generates test cases, which run in both normal and serialized VMs. State differences trigger the tracer for vulnerability analysis. If no difference is found, the microcode coverage bitmap guides mutation toward unexplored microarchitectural states.

Demo / Proof of Concept

▶ Watch: Serialization oracle: differential testing normal vs fence-serialized execution (12:00)

Fuzzilicon's evaluation addresses three research questions:

Coverage effectiveness: With microcode coverage feedback, the fuzzer achieves higher micro-op coverage than without feedback, directly contradicting claims from a recent USENIX Security paper that hardware fuzzing doesn't benefit from feedback. The coverage advantage translates to more thorough microarchitectural state exploration.

Corpus quality: Random byte sequences as initial corpus achieve higher coverage than valid instruction sequences extracted from normal software. This is because valid programs constrain the fuzzer to existing execution paths, while random sequences explore unconventional instruction combinations that may trigger edge-case microarchitectural behaviors.

Bug finding: The 5 findings span multiple categories of speculative execution vulnerabilities, with the automated Spectre variant detection being the most significant -- demonstrating that microcode-level fuzzing can replace manual analysis for discovering microarchitectural side-channel vulnerabilities.

Defensive Implications

▶ Watch: Q&A: comparison with Google's CPU fuzzer and undocumented instructions (16:00)

• Automated speculative execution vulnerability discovery: Fuzzilicon provides the first automated approach to finding Spectre-class vulnerabilities in production Intel hardware, potentially enabling systematic discovery of new transient execution attack variants
• Microcode update validation: The same framework could be used to validate that microcode patches actually fix the vulnerabilities they target, providing a regression testing capability for CPU security patches
• Zombie state detection: The finding that speculative writes leave persistent state in CSR bars and segment selector caches reveals new potential side-channel sources that defenders should monitor
• Performance counter side channels: The discovery that speculative micro-ops leave traces in performance counters adds to the growing catalog of side-channel sources that security-sensitive applications may need to protect against
• Pre-silicon coverage gap: The finding that random corpus outperforms valid corpus suggests that pre-silicon verification with realistic workloads may systematically miss the unconventional instruction combinations that trigger vulnerabilities

Key Takeaways

• Fuzzilicon is the first post-silicon x86 CPU fuzzer with microcode-level coverage visibility, winning the NDSS 2026 Best Paper Award
• 5 new findings on Intel CPUs including automatically discovered microcode Spectre variant and speculative zombie states in CSR bars
• The serialization oracle (normal vs. fence-serialized execution) provides a powerful differential testing approach for speculative execution bugs
• Microcode coverage feedback improves state exploration, contradicting claims that hardware fuzzing doesn't benefit from coverage guidance
• 31x speedup achieved through static analysis-based instrumentation optimization
• Red unlock mode requirement limits applicability to specific Intel CPU families but the methodology could extend to other architectures with similar debug interfaces

About the Speaker(s)

The presentation was delivered by Lisha Wu, an assistant professor at the University of Bristol and former postdoc at the System Security Lab at TU Darmstadt. The original lead author is Johannes Lenzen. Wu demonstrated exceptional command of both the microarchitectural concepts and the fuzzing methodology. The work was recognized with the NDSS 2026 Best Paper Award, reflecting its significance to the hardware security research community.