Broken Conditional

Definition

A broken conditional is a class of realistic RTL (Register-Transfer Level) hardware bug in which a conditional statement — typically an if, case, or other conditional assignment — is constructed incorrectly. In the ENCARSIA study's bug taxonomy, broken conditionals are distinguished from signal mix-ups: they specifically concern the conditions guarding assignments rather than the values assigned. The bugs arise from designers:

• forgetting an exceptional case (a missing case arm or a missing nested if),
• specifying the wrong conditional expression (a wrong select signal or wrong logical combination),
• making algorithmic mistakes in conditional logic (e.g., failing to enforce privilege-mode checks or overflow checks).

The term is defined explicitly in the Encarsia paper (Section 4.2 / 5.2):

"Broken conditionals refer to issues arising from improper handling of exceptional cases or, e.g., operations allowed only in a specific privilege mode."

Survey Evidence

The Encarsia authors manually classified every observable CPU bug fix found across four open-source RISC-V cores — Ibex, CVA6, Rocket, and BOOM — plus the HACK@DAC'19 and HACK@DAC'21 buggy designs, into one of two syntactic categories. Of the 177 relevant bugs:

Per-design breakdown of broken conditional fixes:

Concrete Examples

Example 1 — Forgotten debug-mode check (Ibex PR #277)

The designer forgot to include a check that the CPU is in debug mode before allowing access to debug CSRs, which would let a non-privileged user gain unintended access. The fix inserted a new conditional:

verilog // bug: missing nested conditional inside CSR_DCSR case // fix: illegal_csr = ~debug_mode_i;

The corresponding intermediate representation (Figure 4 of the paper) shows the original multiplexer tree in which the debug_mode_i branch was missing, and the resulting tree after the fix.

Example 2 — Forgotten conditional in case statement (CVA6 PR #138, Listing 3 bug C1)

verilog case (state) IDLE: begin // bug C1: forgotten conditional next_state = ENCRYPT; end ENCRYPT: ... endcase

The fix adds a missing nested if (valid_i) so the assignment is gated properly.

Example 3 — Missing case arm (BOOM PR #173, Listing 3 bug C2)

verilog case (state) IDLE: ... ENCRYPT: ... // bug C2: missing case arm ENCRYPT_FINAL: begin if (!valid_i) next_state = IDLE; end endcase

Example 4 — Missing privilege check (Ibex debug-CSR bug)

The bug allowed unintended access because the design lacked a debug-mode check before granting access to debug CSRs.

How ENCARSIA Models and Injects Broken Conditionals

In Yosys's intermediate representation, conditional assignments are expressed as multiplexer (mux) trees: each level progressively narrows down the candidate expressions assigned to the root signal, with select signals (derived from the assignment's conditions) choosing the appropriate branch.

In this representation, a broken conditional manifests as either:

1. A missing branch — the mux tree lacks a leaf for one case the designer forgot to handle, or
2. An incorrectly derived select signal — the condition guarding an existing branch is wrong.

ENCARSIA uses table transformations over an abstract table representation of mux trees (Figure 5) to inject realistic broken-conditional bugs:

• Removing a row models a designer forgetting to consider a special case (e.g., missing reset, default, or overflow check).
• Turning a select signal into X (don't-care) models cases where designers place insufficient constraints on a case.
• Turning a don't-care select signal into a specific value models bugs where constraints are placed on cases mistakenly.

The paper claims these table transformations "cover the entirety of the bugs in conditional logic that we revealed in the survey." After manipulation, the table is translated back into a Yosys pmux cell (a many-input multiplexer using one-hot encoding) so that the bug-injected circuit can be simulated, instrumented, or analyzed by downstream fuzzers.

Classification Boundary with Signal Mix-Ups

The paper is careful to avoid double-counting bugs that touch both the body and the guard of a conditional:

• Bugs that modify conditions (missing cases, wrong conditions) are classified as broken conditionals.
• Bugs that concern solely the conditionally assigned values but do not modify any condition are classified as signal mix-ups.
• Bugs that modify multiple things may be classified as both.

Security Implications

The Encarsia authors compared each architecturally-observable bug's effect to those of hardware bugs previously assigned CVE numbers. They concluded that all architecturally observable broken conditionals (and signal mix-ups) could impact security in some way, because an attacker can deliberately craft conditions in which the bug produces an attacker-chosen architectural effect. Forgotten privilege checks are explicitly cited as a typical broken-conditional pattern that "create access control vulnerabilities."

Fuzzer Evaluation

When ENCARSIA's injected broken-conditional (and signal mix-up) bugs are used to evaluate three CPU fuzzers over a 24-hour window on Ibex, Rocket, and BOOM:

• DifuzzRTL: finds 41.67% of injected bugs.
• ProcessorFuzz: finds 41.67% of injected bugs.
• Cascade: finds 40% of injected bugs.

These shortfalls motivate ENCARSIA's framework for automatically injecting realistic broken conditionals into RTL designs in order to evaluate fuzzer quality.