cf-ambiguous instruction

Concept

A cf-ambiguous instruction is a control-flow instruction in the Cascade CPU fuzzer whose operand value cannot be computed until late in program generation, forcing the instruction set simulator (ISS) to run at least once per such instruction unless mitigated.

First seen 7/2/2026

Last seen 7/2/2026

Evidence 3 chunks

Wiki v1

WIKI

cf-ambiguous instruction

In the Cascade CPU fuzzing framework, a cf-ambiguous instruction is a control-flow instruction whose required operand value is not known when the instruction is first selected during program generation. The canonical examples are indirect jumps such as jalr, which must be supplied with a specific target value val that Cascade intends to impose on the CPU under test. Because val is not yet determined, Cascade cannot simply pre-compute a static target operand; instead, it must take special steps to materialize val later, which has implications for instruction set simulator (ISS) pre-simulation and overall fuzzing throughput.

Why such instructions are problematic

READ FULL ARTICLE →

NEIGHBORHOOD

No graph connections found for this entity yet. It may appear in future ingestion runs.

explore full graph →

RELATIONSHIPS

1 connections

Cascade ← uses 100% 3e

Cascade identifies and handles cf-ambiguous instructions specially during program construction

LINKED ENTITIES

1 links

Cascade USES Extracted graph relationship

CITATIONS

8 sources

8 citations — click to expand

[1] A cf-ambiguous instruction is exemplified by indirect jumps such as `jalr`, which require a specific operand value `val` that Cascade intends to impose. Cascade (USENIX Security 2024 preprint)

[2] Without mitigation, the ISS cannot proceed to the next basic block (or complete a correct memory operation) without running at least once per cf-ambiguous instruction, creating a critical performance bottleneck. Cascade (USENIX Security 2024 preprint)

[3] Following dependency preservation, Cascade makes `val` depend on a randomly picked dependent register `rd` whose value is unknown when the cf-ambiguous instruction is picked, and introduces an offset register `r_off` and an offset applier instruction (e.g., `xor`) whose output is the applied register `r_app` holding `val`. Cascade (USENIX Security 2024 preprint)

[4] Branches are handled via ISS feedback rather than the offset-applier scheme, because applied registers are a precious resource; Cascade selects a still or hopping branch opcode accordingly. Cascade (USENIX Security 2024 preprint)

[5] Cascade maintains a per-architectural-integer-register state machine ensuring (1) `r_app` is available when the cf-ambiguous instruction is picked, (2) `r_off` is ready before the offset applier instruction, and (3) `rd` is available when the offset applier instruction executes. Cascade (USENIX Security 2024 preprint)

[6] Cascade's asymmetric ISA pre-simulation feeds the ISS an intermediate program that (a) has identical dependent-register values, (b) has identical control flow, and (c) contains no applied register that depends on the randomized data flow, enabling a single ISS execution per program. Cascade (USENIX Security 2024 preprint)

[7] The intermediate program differs from the ultimate program in three ways: (1) immediates `imm1` and `imm2` set `r_off` directly to `val`, (2) the offset-applying instruction is substituted with an `mv` from `r_off` to `r_app`, and (3) non-taken branches are transformed into NOPs. Cascade (USENIX Security 2024 preprint)

[8] Free and applied registers hold identical values between the intermediate and ultimate programs at every program point, but registers in the `gen`, `ready`, and `unrel` states do not, so they must never be used as input to any instruction other than the next step of the offset construction cycle. Cascade (USENIX Security 2024 preprint)