The integer CSRs that need fault-injection protection use ibex_csr with a shadow copy. The CHERIoT capability CSRs added in #2475 (mtvec_cap, mepc_cap, mtdc_cap, mscratchc_cap, depc_cap, dscratch0/1_cap in ibex_cs_registers.sv) are plain flops without one, so MTCC does not get the protection that MTVEC has.
In a SecureIbex configuration these registers are duplicated in the shadow core, so a fault should surface in the lockstep comparison before it can leave the core. The gap matters for configurations without lockstep, and for consistency with the integer CSRs.
Scope:
- MTCC at minimum, since MTVEC is shadowed
- decide whether the root capabilities (MTDC, MScratchC) warrant it too
- best done together with reworking these registers to use
ibex_csr
Agreed with @nasahlpa in review: #2475 (comment)
The integer CSRs that need fault-injection protection use
ibex_csrwith a shadow copy. The CHERIoT capability CSRs added in #2475 (mtvec_cap,mepc_cap,mtdc_cap,mscratchc_cap,depc_cap,dscratch0/1_capinibex_cs_registers.sv) are plain flops without one, so MTCC does not get the protection that MTVEC has.In a
SecureIbexconfiguration these registers are duplicated in the shadow core, so a fault should surface in the lockstep comparison before it can leave the core. The gap matters for configurations without lockstep, and for consistency with the integer CSRs.Scope:
ibex_csrAgreed with @nasahlpa in review: #2475 (comment)