Open nasahlpa opened 1 month ago
Thanks @nasahlpa for debugging and reporting this. We have discussed this offline and our conclusion was that this is not critical for Earlgrey as in Earlgrey the only app interface for which a sideload key can be used is keymgr and software has full control over keymgr. So it's not expected that keymgr will invalidate the sideload key while the app interface is still busy.
However, this is something we should fix in the RTL for future versions / use cases where software may have less control.
Description
While working on #22956, I've detected the following in the
kmac_app
module. When thekeymgr_key_i.valid
gets invalidated, we enter theStKeyMgrErrKeyNotValid->StError->StErrorAwaitApp
FSM state. Exiting theStErrorAwaitApp
state only is possible with: https://github.com/lowRISC/opentitan/blob/df4d7d58a86b24db28ba483ceead796a5b23fe9d/hw/ip/kmac/rtl/kmac_app.sv#L584-L596However, it could be that the key gets invalidated AFTER
(app_i[app_id].valid && app_i[app_id].last)
was seen:Hence, the
StErrorAwaitApp
cannot be escaped. This is not too problematic for Earl Grey as in Earl Grey the SW has full control over the keymanager which is providing the sideloading key.A solution would be to extend the
kmac_app
module to track whether(app_i[app_id].valid && app_i[app_id].last)
already has been seen. In this case, just it is sufficient to just let the SW clear the error usingerr_processed_i
.