From afac772ffcc84e4a3fdf9ab55339b74e96a0bd01 Mon Sep 17 00:00:00 2001 From: Pascal Nasahl Date: Thu, 9 Apr 2026 12:16:57 +0200 Subject: [PATCH 1/4] [doc] Remove RF write enable and read address glitch detection doc As those features were removed in lowRISC/ibex@8fda2d6 reflect this in the documentation as well. Signed-off-by: Pascal Nasahl --- doc/03_reference/security.rst | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/doc/03_reference/security.rst b/doc/03_reference/security.rst index 3ea007653..5bbbf6c2e 100644 --- a/doc/03_reference/security.rst +++ b/doc/03_reference/security.rst @@ -85,22 +85,6 @@ When Ibex is configured with the SecureIbex parameter, ECC checking is added to This can be useful to detect fault injection attacks since the register file covers a reasonably large area. No attempt is made to correct detected errors, but an internal major alert is signaled for the system to take action. -Register file write enable glitch detection -------------------------------------------- - -When Ibex is configured with the SecureIbex parameter, the write enable signal into the register file is checked to be one-hot. -This can be useful to detect fault injection attacks. -No attempt is made to correct detected errors, but an internal major alert is signaled for the system to take action. - -Register file read addresses glitch detection -------------------------------------------- - -When Ibex is configured with the SecureIbex parameter, the read addresses provided to the register file are converted to one-hot encoded signals, and a one-hot encoded MUX is used to select the register to read from. -By using one-hot encoding checkers, glitches in the one-hot encoded signals are detected. -Bit-flips inside the plain read addresses before the one-hot conversion happens are detected by the dual core lockstep. -This can be useful to detect fault injection attacks. -No attempt is made to correct detected errors, but an internal major alert is signaled for the system to take action. - ICache ECC ---------- From eddb428a4da3cac266dd9b95c091b2f1377eabd2 Mon Sep 17 00:00:00 2001 From: Pascal Nasahl Date: Thu, 9 Apr 2026 12:23:14 +0200 Subject: [PATCH 2/4] [doc] Move lockstep description in the documentation As this is the most prominent feature, move it up in the documenation. Signed-off-by: Pascal Nasahl --- doc/03_reference/security.rst | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/03_reference/security.rst b/doc/03_reference/security.rst index 5bbbf6c2e..07b749130 100644 --- a/doc/03_reference/security.rst +++ b/doc/03_reference/security.rst @@ -69,6 +69,16 @@ This will make the insertion interval of dummy instructions much harder for an a Note that the dummy instruction feature inserts multiply and divide instructions. The core must be configured with a multiplier (`RV32M != ibex_pkg::RV32MNone`) or errors will occur using this feature. +Dual core lockstep +------------------ + +This configuration option instantiates a second copy of the core logic, referred to as the shadow core. +The shadow core executes using a delayed version of all inputs supplied to the main core. +All outputs of the shadow core are compared against a delayed version of the outputs of the main core. +Any mismatch between the two sets of outputs will trigger an internal major alert. + +Note that the register file and icache RAMs are not duplicated since these units are covered by ECC protection. + Bus integrity checking ---------------------- @@ -107,13 +117,3 @@ Certain critical CSRs (`mstatus`, `mtvec`, `cpuctrl`, `pmpcfg` and `pmpaddr`) ha This creates a second copy of the register which stores a complemented version of the main CSR data. A constant check is made that the two copies are consistent, and an internal major alert is signalled if not. Note that this feature is not currently used when the SecureIbex parameter is set due to overlap with dual core lockstep. - -Dual core lockstep ------------------- - -This configuration option instantiates a second copy of the core logic, referred to as the shadow core. -The shadow core executes using a delayed version of all inputs supplied to the main core. -All outputs of the shadow core are compared against a delayed version of the outputs of the main core. -Any mismatch between the two sets of outputs will trigger an internal major alert. - -Note that the register file and icache RAMs are not duplicated since these units are covered by ECC protection. From eae617b1de8650e5ad5a3aa3f6bd386580bf2777 Mon Sep 17 00:00:00 2001 From: Pascal Nasahl Date: Thu, 9 Apr 2026 12:32:02 +0200 Subject: [PATCH 3/4] [doc] Document the split data and ECC of the register file This was added in lowRISC/ibex@e23c26c Signed-off-by: Pascal Nasahl --- doc/03_reference/security.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/03_reference/security.rst b/doc/03_reference/security.rst index 07b749130..6a454a4c2 100644 --- a/doc/03_reference/security.rst +++ b/doc/03_reference/security.rst @@ -91,7 +91,11 @@ Write data can be checked against the supplied checkbits at its destination to c Register file ECC ----------------- -When Ibex is configured with the SecureIbex parameter, ECC checking is added to all reads of the register file. +When Ibex is configured with the SecureIbex parameter, the data stored in the register file is not duplicated in the dual core lockstep to save area. +Instead, two instances of the register file are used. +The first instance is driven by the main core and holds the data itself. +The second instance is driven by the shadow core and holds the corresponding ECC. +ECC checking is conducted inside the shadow core. This can be useful to detect fault injection attacks since the register file covers a reasonably large area. No attempt is made to correct detected errors, but an internal major alert is signaled for the system to take action. From 48d3412d5825a401f088e60e11f735e6f7293f71 Mon Sep 17 00:00:00 2001 From: Pascal Nasahl Date: Thu, 9 Apr 2026 12:45:03 +0200 Subject: [PATCH 4/4] [doc] Document the ICache tweak infection feature This documents lowRISC/ibex@556dff1 Signed-off-by: Pascal Nasahl --- doc/03_reference/security.rst | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/doc/03_reference/security.rst b/doc/03_reference/security.rst index 6a454a4c2..eb5d2d03f 100644 --- a/doc/03_reference/security.rst +++ b/doc/03_reference/security.rst @@ -77,7 +77,7 @@ The shadow core executes using a delayed version of all inputs supplied to the m All outputs of the shadow core are compared against a delayed version of the outputs of the main core. Any mismatch between the two sets of outputs will trigger an internal major alert. -Note that the register file and icache RAMs are not duplicated since these units are covered by ECC protection. +Note that the register file and icache RAMs are not duplicated since these units are covered by other countermeasures. Bus integrity checking ---------------------- @@ -102,10 +102,21 @@ No attempt is made to correct detected errors, but an internal major alert is si ICache ECC ---------- -The ICache can be configured with ECC protection. +When Ibex is configured with the SecureIbex parameter, the data and tag banks are not duplicated in the dual core lockstep to save area. +Instead, ECC protection is added to the ICache. When an ECC error is detected a minor alert is signaled. See :ref:`icache-ecc` for more information. +ICache Tweak Infection +---------- + +In addition to the ICache ECC, SecureIbex also uses a tweak infection based countermeasure. +After computing the ECC and before writing to the data or tag banks, the ICache XORs a tweak to the data. +When reading back from those banks, the tweak is un-XORed before checking the ECC. +The tweak for the data bank consists of the data address without the `IC_LINE_W` LSBs. +For the tag tweak, the tag index is used. +This technique establishes a link in the bank memories between data and address. + Hardened PC -----------