Skip to content
STIMSMITH

Condition code matching

Concept

Condition code matching is a technique used by the armshaker fuzzer's back-end to ensure that the CPSR condition flags are set to match the condition code encoded in an AArch32 instruction. This prevents undefined instructions whose condition code does not currently match the flags from being silently skipped as NOPs, which is an implementation-defined behavior on some Armv8-A processors.

First seen 6/21/2026
Last seen 6/21/2026
Evidence 2 chunks
Wiki v1

WIKI

Condition code matching

In the AArch32 execution state, every instruction begins with a four-bit condition code field. The processor evaluates this field against the current condition flags in the CPSR (Current Program Status Register) and only executes the instruction when the condition holds. When the condition does not hold, the instruction is treated as a NOP.

When fuzzing for hidden or undocumented instructions on real hardware, this default behavior can produce a large number of false positives. Some Armv8-A implementations execute undefined instructions whose condition code does not match the current flags as silent NOPs, rather than raising an undefined-instruction exception. This is documented as implementation-defined behavior in section G1.16.1 of the Arm Architecture Reference Manual (DDI0487).

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
fuzzer back-end ← uses 100% 1e
The fuzzer back-end supports condition code matching via the -c option.

CITATIONS

3 sources
3 citations — click to collapse
[1] The fuzzer back-end provides a -c/--cond option that sets the CPSR condition flags to match the condition code encoded in the instruction. frestr/armshaker
[2] On AArch32, -c ensures that undefined instructions with a normally non-matching condition code won't be skipped, as is the case in some ISA implementations. frestr/armshaker
[3] Some Armv8-A processors execute undefined instructions with an unmatched condition code as NOPs rather than generating an exception, which is implementation-defined behavior per Armv8 ARM section G1.16.1 (DDI0487E). frestr/armshaker