Fuzzilicon Framework for Vulnerability Discovery

• Fuzzilicon is a post-silicon fuzzing framework that leverages microcode-level instrumentation for systematic vulnerability detection in x86 CPUs.
• It employs a hypervisor-managed, deterministic test harness with hardware watchdogs and feedback metrics to accelerate vulnerability discovery by 8×.
• The framework minimizes intrusion by using red-unlock techniques and optimized instrumentation, enabling identification of speculative bugs like μSpectre and others.

Fuzzilicon is a post-silicon fuzzing framework for real-world x86 CPUs that enables deep introspection into processor microcode and microarchitectural layers. It is designed to automate the discovery of vulnerabilities previously accessible only via extensive manual reverse engineering, introducing microcode-level instrumentation and feedback-guided fuzzing in a scalable, coverage-oriented manner. Fuzzilicon operates without reliance on Register Transfer Level (RTL) and demonstrates the first practical system for systematic vulnerability detection directly on post-silicon x86 CPUs through minimally intrusive, hypervisor-managed microcode instrumentation and model-free differential analysis (Lenzen et al., 29 Dec 2025).

1. Motivation, Challenges, and Goals

Post-silicon CPU vulnerability discovery faces three central obstacles. First, microarchitectural invisibility: commercial x86 CPUs constitute proprietary black boxes, exposing only coarse-grained signals (e.g., hardware performance counters or architectural faults) and largely obscuring the proprietary microcode behaviors where critical flaws reside. Second, traditional techniques lack an effective bug-detection oracle; the absence of formal microarchitectural specifications renders it difficult to judge whether an observed internal state or behavior constitutes a correctness violation, particularly for effects involving speculative or undocumented microcode. Third, non-determinism and fault containment challenges arise: stateful instructions, asynchronous interrupts, or improper microcode patching can introduce persistent non-determinism, unpredictably hang the processor, and disrupt fuzzing campaigns.

Fuzzilicon addresses these challenges by extracting fine-grained feedback from microcode execution. Microcode- and microarchitectural-level feedback is essential as many impactful vulnerabilities only manifest within the microcode engine itself; architectural coverage metrics (such as basic block or opcode coverage at the x86 ISA level) saturate rapidly and fail to differentiate the abundance of distinct micro-op (µop) execution paths, including those associated with SMM entry, VMX exit, or other architectural events. Precise logging of µop addresses and their execution frequency provides the path sensitivity necessary for rigorous test input prioritization.

2. Architecture and Design Principles

Fuzzilicon comprises three principal components. The Fuzzer Controller runs off-target, managing the corpus, orchestrating input mutation (using either a genetic engine or AFL Havoc mutators), performing serialization-oracle transformations, and scheduling campaigns. The Fuzzer Agent operates on the target CPU, performing microcode introspection—enabled by "red-unlocking" the processor—injecting microcode instrumentation, collecting coverage, capturing architectural state, and tracing early divergences. A hardware Watchdog governed by the Controller forcibly resets the Device Under Test (DUT) in the event of hangs or crashes to ensure uninterrupted operation.

Fuzzilicon exploits Intel’s microcode update interface after enabling red-unlock mode, which reveals two undocumented instructions (udbgrd/udbgwr) allowing direct read/write access to microcode RAM and the hook table. Intel’s patch engine employs 16 hook registers to redirect microcode execution from designated addresses (SRCᵢ) into patch RAM destinations (DSTᵢ). Fuzzilicon repurposes these hooks to insert lightweight instrumentation at selected addresses within the microcode ROM.

A custom Type-1 UEFI hypervisor is used to ensure deterministic, isolated test runs. For every test, the hypervisor initializes a sanitized VMCS, clears volatile RAM, resets segment and general-purpose registers, enforces execution timeouts, and intercepts inherently non-deterministic instructions (e.g., RDRAND, RDPMC, and external interrupts). Upon completion, the hypervisor extracts the final architectural state for subsequent comparison. This harness ensures reproducibility and limits test non-determinism.

3. Microcode Instrumentation and Feedback Collection

Fuzzilicon’s minimally intrusive instrumentation leverages the microcode staging buffer (address range 0xba00–0xbb00) to temporarily store and restore small register sets, preserving the observable architectural state during instrumentation routines. The principal pseudocode algorithm for µop instrumentation consists of:

1. hook_handler_even: Saves registers, loads indices, jumps to the common handler.
2. hook_handler_odd: Similar; distinguishes even/odd paired addresses.
3. handler: Saves further registers, computes the coverage index, increments the corresponding RAM counter (tracking (µop_address, execution_count)), restores state, and resumes execution at the original µop.
4. exit_i_even/exit_i_odd: Finalizes context restoration and executes the original µop sequence.

Even/odd µop differentiation exploits Intel’s auto-pairing of even-numbered hooks with odd neighbors. Fuzzilicon injects an immediate jump at each DST address, ensuring that execution of the even-indexed instruction triggers instrumentation while the odd-indexed address executes normally, allowing for fine localized feedback and unmodified µop logic elsewhere.

4. Reverse Engineering and Optimized Fuzzing Workflow

Reverse engineering red-unlock functionality is a prerequisite for Fuzzilicon deployment. Prior community proof-of-concepts are combined to achieve patch RAM read/write access, enumerate hook register layouts, and bypass signature validation on microcode updates. The hook table enables instrumentation at up to 32 µop addresses per configuration (16 hook registers, each paired for both even and odd addresses).

Covering the entire microcode ROM (≈0x7C00 addresses) with 32-instrumented slots per run requires 992 executions in the naïve baseline. Fuzzilicon optimizes further by limiting instrumentation to µop entry points below 0x1000 (i.e., 512 locations, requiring only 32 runs) and propagating coverage along basic block successors—only reinstrumenting edges whose predecessor blocks exhibited new coverage. This propagation mechanism, employing the successor set Φ(y) for each basic block y, yields up to a 31× reduction in required executions for comprehensive microcode coverage.

5. Feedback-Guided Fuzzing and Differential Analysis

Fuzzilicon introduces the first microcode-centric feedback metric: for each test, the set of observed (µop_address, execution_count) pairs forms the coverage vector, permitting discrimination among test cases by both traversed micro-op paths and their multiplicities (sensitive to iteration counts in loops).

Input generation is initialized from either random byte sequences or valid x86 instruction streams sourced from standard libraries (libc++, libz, libzip). Mutation strategies include a custom genetic mutator (introducing 1–8 byte-level mutations, crossover; fitness = µcode coverage + code executed) and AFL Havoc mutators (preferred in experiments for speed).

For systematic vulnerability exposure, Fuzzilicon uses a serialization oracle: for each program P, a serialized variant Q is constructed ($$Q ≡ \text{fence};~\text{insn}_0;~\text{fence};~\text{insn}_1;~\ldots$$), suppressing instruction speculation. Binary-rewriting ensures correct relative addressing. The Superset Disassembly method disambiguates misaligned jumps by splitting ambiguous fragments and inserting HLT barriers. Any divergence between the architectural states reached by P and Q indicates a candidate microarchitectural or speculative bug.

6. Experimental Results and Discovered Vulnerabilities

Experiments on an Intel N3350 (Goldmont, CPUID 0x506ca, on Gigabyte GB-BPCE-3350C) subjected the system to 48-hour fuzzing epochs per configuration (≥3 repetitions) employing both random and valid corpora, with and without µcode feedback.

Fuzzilicon achieved 2,867 unique µop addresses covered, corresponding to 16.27% of 17,624 hookable µop locations—the first established empirical baseline. Coverage was realized with an 8× acceleration compared to conventional approaches, and instrumentation overhead was reduced by 31× (mean 571 µs per test, down from 566 ms baseline).

Table: Key Quantitative Results

Metric	Value	Baseline Comparison
Unique µop coverage	2,867 / 17,624 (16.27%)	N/A
Coverage speedup with feedback	8×	Equal coverage time
Instrumentation overhead per test	571 µs	566 ms (31× reduction)

Notable findings include the automatic rediscovery of the μSpectre vulnerability, along with the identification of two previously unknown microcode-level speculative-execution bugs:

• F1: μSpectre – Microcode speculative path-induced information leakage identified differentially.
• F2: Persistent speculative CRBUS writes – SPECULATIVE MOVETOCREG_DSZ64 bypasses patch hooks after misprediction.
• F3: Persistent speculative segment-selector updates – WRSEGFLD instruction in speculative windows fails to roll back, potentially allowing ring-0 escalation or denial-of-service via GDT base state.
• F4: Microcode dispatch as speculation barrier – First µop fetch behavior enables timing side-channels by halting out-of-order execution.
• F5: Speculative µops leak via perf counters – Increments to MS_DECODE.MS_ENTRY register persist even if the respective µops do not retire.

7. Portability, Limitations, and Prospects

Fuzzilicon is applicable to any red-unlocked Intel x86 CPU exposing patch RAM and hook-table access, requiring only minimal per-CPU configuration (hook addresses, staging buffer offsets). Extension to AMD CPUs is plausible in theory (e.g., via EntryBleed), but would necessitate new reverse engineering of the AMD microcode subsystem.

Limitations include the necessity for red-unlock features, which are generally unavailable on retail CPUs without hardware modifications. Instrumentation is limited by the 16 hook register constraint, creating the need for repeated, finely scheduled executions; future hardware enhancements, such as expanded patch RAM or additional hook slots, would ameliorate this. The serialization oracle may yield false positives for self-modifying or complex, interdependent instruction streams; advances in dynamic binary rewriting could address these artifacts. Broadening support beyond x86/Intel requires discovery of analogous patch-RAM interfaces and further microcode research.

In summary, Fuzzilicon establishes a novel methodology for post-silicon x86 CPU vulnerability discovery, directly instrumenting microcode with minimal intrusion, providing empirical coverage baselines and microcode-centric feedback, leveraging hypervisor-managed deterministic harnesses, and systematizing model-free differential testing for microarchitectural security research (Lenzen et al., 29 Dec 2025).