[kmac] Abort when sideload key is invalid during operation #22794

The `CFG_SHADOWED` CSR gets write-locked while the SHA3 module is operating. This makes sense for configuration values but it is problematic for the `err_processed` bit, through which SW acknowledges that it has handled an error occurring while KMAC/SHA3 is operating, because that acknowledgment would then not propagate to KMAC and it would get stuck. Signed-off-by: Andreas Kurth <[email protected]>

This commit fixes four problems in KMAC's error handling: 1) App interface done after SW has processed error Before this commit, when the FSM in `kmac_app` was in its `StError` state and SW acknowledged the error by writing the `err_processed` bit in the `CFG_SHADOWED` CSR, the FSM would go back to the `StIdle` state. If the active HW app interface had not provided all data before this SW-induced transition to the `StIdle` state, KMAC was no longer ready to absorb the remaining data, thereby stalling the HW app interface. This commit extends the FSM in `kmac_app` so that when an error happens it doesn't matter whether SW acknowledges the error before or after the HW app interface has provided all data. In both cases, the FSM now waits for SW to acknowledge *and* the HW app interface to provide all data before it returns to `StIdle`. To implement this, two new states (`StErrorAwaitSw` and `StErrorAwaitApp`) get added. In block-level DV, `kmac_key_error_vseq` waited for the *first* data item instead of the *last* before stopping to send items on the active HW app interface and continuing with the vseq (acknowledging the error from SW and going to the next iteration). This no longer works because KMAC now remains in `StError` until the HW app interface has send the last data item, so that vseq now correctly sends all data items including the last on the HW app interface. This may raise a new issue: If the HW app interface misbehaves, KMAC will remain in the error state until it gets reset. To remediate this, we could add a mechanism for SW to clear KMAC's state regardless of the state of the HW app interface. 2) SHA3 core not told to process Before this commit, when the FSM in `kmac_app` went through the `StError` state, it would not tell the SHA3 core to process the data so that its internal state would get flushed. This commit extends the FSM in `kmac_app` so that `CmdProcess` is signaled on `cmd_o` to the SHA3 core when the error is handled, and lets the FSM wait for the completion of SHA3 (`absorbed_i` input) before returning to idle. To implement this, a new state (`StErrorWaitAbsorbed`) is added. 3) Signaling completion to SW when an error has occurred in SW mode Before this commit, when an error would occur in SW mode (`mux_sel == SelSw`), the `absorbed_o` output, which in turn triggers the `kmac_done` IRQ would not be raised. This case could not happen because no errors were raised in SW mode (such errors will get raised with the next commit), but it's still wrong. This commit extends the FSM in `kmac_app` with a side-band state bit (`err_during_sw_q`) and uses that to set `absorbed_o` when an error that occurred during SW mode got handled. 4) Clearing of `kmac_errchk` Before this commit, the state of the `kmac_errchk` would not get cleared after the error has been handled. Thus the next invocation of KMAC could start with a residual state in `kmac_errchk` and incorrectly fail. This commits adds a MuBi-encoded signal from `kmac_app` to `kmac_errchk` through which the former can clear the latter after an error. Signed-off-by: Andreas Kurth <[email protected]>

When `kmac_app` aborts an operation as soon as the sideload key becomes invalid (which it will do in a couple of commits) the current stability assertions on `key_len_i` and `key_data_i` in `kmac_core` would be violated. This is not a problem: `kmac_core` *should* use an invalid, useless key in that case. To prevent these assertions from failing, this commit introduces a signal with which `kmac_app` indicates to `kmac_core` whether `key_len_i` and `key_data_i` are valid and rewrites the assertions to take that valid signal into account. Signed-off-by: Andreas Kurth <[email protected]>

Signed-off-by: Andreas Kurth <[email protected]>

…function Signed-off-by: Andreas Kurth <[email protected]>

Signed-off-by: Andreas Kurth <[email protected]>

The KMAC HW IP block features an option to load keys from Key Manager via a HW key sideload interface. Prior to this commit, KMAC would: - when used via the SW application interface: *not check at all* if the sideload key is valid (issue lowRISC#10704, lowRISC#16855); - when used via a HW application interface: check if the sideload key is valid *only for a single cycle* when the application interface gets configured (state `StAppCfg` in `kmac_app`). This could lead to cases where KMAC would use an invalid sideload key. This commit fixes the problem by checking whether the sideload key is valid in *every* FSM state in which the sideload key is used. If the sideload key is invalid even for a single cycle (the FSM cannot know whether the key is being used in this exact cycle or not), `kmac_app`'s FSM goes into the `StKeyMgrErrKeyNotValid` state. In that state, the FSM signals the `keymgr_pkg::ErrKeyNotValid` error code in KMAC's `err_code` CSR. The FSM then transitions to the `StError` state, where it drains data from the HW application interface by keeping `app_o.ready` high. The digest output remains all-zero (it can only take a non-zero value in the `StAppWait` state). The FSM exits the `StError` state after SW has signalled that it has processed the error by writing the `processed` bit in the `CFG_SHADOWED` CSR *and* the active HW app interface has sent the last data item. This commit resolves lowRISC#10704 and implements the RTL part of lowRISC#16855. Covering this in DV remains open, although the existing tests (which don't cover this) keep their previous pass rates. Signed-off-by: Andreas Kurth <[email protected]>

Signed-off-by: Andreas Kurth <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[kmac] Abort when sideload key is invalid during operation #22794

[kmac] Abort when sideload key is invalid during operation #22794

Commits on May 2, 2024