ot_keymgr: Implement key generation, wiping & better error handling

[AlexJones0]

This PR is the fourth of a series of 4 PRs to implement OpenTitan's keymgr IP, used in Earlgrey, split to ease review. It finishes implementing the main logic for the keymgr, allowing the generation of both SW output and HW output (sideloaded) keys, as well as identity generation outputs. It implements sideloaded key clearing and fixed handling of the KMAC sideloaded key between operations, and models wiping of the keys with entropy (partially, there is still no entropy reseeding). It also adds some more debug & fault status checks. The docs are then updated with the new keymgr status, noting anything that is still unimplemented.

As seen in the last commit, thanks to the additions from previous PRs (otp_ctrl, flash_ctrl, aes, kmac, otbn) this is now enough functionality to get all sim_qemu_rom_with_fake_keys OpenTitan tests related to keymgr or sideloading passing.

See the commit messages for more details about each change.

ROM_EXT support

With these keymgr changes, the aforementioned OTP and flash updates, other flash updates and the UART VAL break workaround, this should be enough to boot into ROM_EXT Earlgrey environments.

I currently have a work-in-progress, slightly hacky version of this in OpenTitan on my fork here (see the diff). I've tried running all the keymgr and sideloading test in sival_rom_ext and all of these are also passing, except for two tests that are marked as broken in the fpga_cw310_sival_rom_ext environment (from a quick glance, likely because they don't make sense to run after ROM_EXT). If you have set up OpenTitan to be able to use a local QEMU override and use this branch, you can run a SiVal ROM_EXT test like:

./bazelisk.sh test //sw/device/tests:aes_smoketest_sim_qemu_sival_rom_ext \
   --test_output=streamed \
   --override_repository="+qemu+qemu_opentitan=/path/to/your/qemu/checkout"

One key unresolved issue that I've hacked around in the Bazel is with flashgen.py, where I've had to provide the --unsafe-elf flag because the ROM_EXT signed binary and ELF do not match. I believe this is because the ROM_EXT binary is signed together with the ROM_EXT's immutable section, which has a separate ELF file from the ROM_EXT's ELF. Hence the binary's start and size do not match the ELF. Based on this understanding, I think that the best way to resolve this would be to update flashgen.py with an option to provide multiple ELFs for a given binary. @rivos-eblot does this sound reasonable, or is there anything else I should be aware of here?

[AlexJones0]

Progresses lowRISC/opentitan#27894, partially progresses lowRISC/opentitan#27931.

[AlexJones0]

(oops, accidentally didn't mark this as a draft until #185 is merged)

[jwnrt]

Reviewed for style and didn't see any obvious problems. Given that all the keymgr tests are now passing I trust that the logic is correct as well.

Thanks

[rivos-eblot]

I wonder whether it could make sense to define something like QEMU bitops.h:

#define BITS_PER_BYTE           CHAR_BIT
#define BITS_PER_LONG           (sizeof (unsigned long) * BITS_PER_BYTE)

for 32-bit values since we use them a lot in hw/opentitan?

[AlexJones0]

Yes - that seems like something that could end up being useful (and avoid mistakes). There are quite a few useful helpers in bitops.h. In this specific case > 32 key sinks would require a rewrite due to register changes, so I'm really just being extra safe and sanity checking that we don't have exactly 32 keymgr key sinks in our design somehow! (I hope not)