lowRISC / opentitan

OpenTitan: Open source silicon root of trust
https://www.opentitan.org
Apache License 2.0
2.58k stars 777 forks source link

[kmac,rtl] Invalidated key after app_i.last was seen #24739

Open nasahlpa opened 1 month ago

nasahlpa commented 1 month ago

Description

While working on #22956, I've detected the following in the kmac_app module. When the keymgr_key_i.valid gets invalidated, we enter the StKeyMgrErrKeyNotValid->StError->StErrorAwaitApp FSM state. Exiting the StErrorAwaitApp state only is possible with: https://github.com/lowRISC/opentitan/blob/df4d7d58a86b24db28ba483ceead796a5b23fe9d/hw/ip/kmac/rtl/kmac_app.sv#L584-L596

However, it could be that the key gets invalidated AFTER (app_i[app_id].valid && app_i[app_id].last) was seen: Image

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 using err_processed_i.

vogelpi commented 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.