lowRISC / opentitan

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

[edn] Need startup sequence for continous entropy delivery #5464

Closed vogelpi closed 2 years ago

vogelpi commented 3 years ago

When enabling the entropy complex (entropy_src, csrng, edn) with a minimal configuration sequence edn will deliver a fixed amount of boot-time entropy (384 bits). After that, edn stops delivering entropy and the consuming devices starve. This behavior is intended. To get more entropy, edn needs to be correctly configured to send periodic generate and reseed commands to csrng and ultimately entropy_src.

Now that we have multiple devices connected to the edns, it would be good to work out such a configuration sequence and potentially also add it to boot ROM. See also https://github.com/lowRISC/opentitan/pull/5427#pullrequestreview-603979681

vogelpi commented 3 years ago

I have been discussing this with @mwbranstad and he confirmed that we should look into this.

martin-lueker commented 3 years ago

Have there been any updates on this?

vogelpi commented 3 years ago

I am not sure Martin. There has been quite a lot of work on the ES, CSRNG, EDN DIFs but I don't know if the DIF consists such a sequence. I can imagine that such a sequence would be constructed by a higher-level driver. Maybe @moidx who was working on the DIFs has a clearer idea.

tjaychen commented 3 years ago

i think @mwbranstad addressed this through this commit

moidx commented 3 years ago

What is the order of operations here once we are in boot_rom to switch to regular entropy?

  1. Toggle entropy_src to switch to regular entropy
  2. Toggle CSRNG enable; and,
  3. Configure EDN
vogelpi commented 3 years ago

My understanding is that the commit referenced by Tim just increases the amount of entropy delivered without proper configuration. Once the specified amount has been served to consumers, EDN will just stop responding and any consumer will wait and eventually stall forever. As a temporary workaround, we disabled and re-enabled EDN which makes it serving once more the specified amount of entropy before stopping again. This is clearly not the right way to do this.

Instead software needs to tell EDN to automatically request more entropy from CSRNG (generate command register) and after a specified interval, trigger a CSRNG reseed from the entropy source (reseed command register). More information on this can be found in the EDN specifcation under Auto Request Mode.

mwbranstad commented 3 years ago

Here is what I am seeing as a possible sequence: 1) do the basic boot sequence for fast entropy: enable ES, enable CS, set EDN to boot req mode 2) once the chip boot sequence has reached some near steady state, re-init the two EDN blocks. Set EDN0 to auto req mode with a very long time between reseeds. Set EDN1 to very short times, possibly a toggle between a GEN and a RESEED command. 3) There are software ports in each EDN and CSRNG as well for doing GEN commands, etc.

tjaychen commented 3 years ago

yeah what @mwbranstad is describing is more or less what I expect to happen. The boot time entropy is increased to accommodate boot purposes. Once we get into individual tests (or software proper), then the fips-mode sequence needs to formally setup for "good" entropy.

I think this will trickle in slowly as the difs for entropy_src / csrng / edn are gradually ready.

tjaychen commented 2 years ago

i think this is an issue that can be closed down now. We increased the amount of available of boot time entropy, but it is generally understand we need to enable the "fips" mode for more.

Does anyone disagree?

moidx commented 2 years ago

SGTM. I think there is also a configuration register in EDN to increase the number of gen bytes in boot mode, so this is ok to close for my perspective.

Before any critical operations we should enable the entropy complex in continuous mode.

vogelpi commented 2 years ago

SGTM as well. Do we need to track the task for enabling continuous mode somewhere, or can software already do this today?

andreaskurth commented 2 years ago

Both the mask ROM https://github.com/lowRISC/opentitan/blob/a4684e1331fa7f64d091e37a1a4bda140cd3d4d1/sw/device/silicon_creator/mask_rom/mask_rom_start.S#L205-L231

and the test ROM https://github.com/lowRISC/opentitan/blob/a4684e1331fa7f64d091e37a1a4bda140cd3d4d1/sw/device/lib/testing/test_rom/test_rom_start.S#L179-L205

now contain code to initialize the entropy source and the CSRNG and to let EDN0 provide entropy in boot mode (according to the reset value of the register, EDN provides 4095 * 128 bit of entropy in boot mode).

After this initial entropy as well as for the high-quality EDN1, auto mode has to be used instead. Configuration of the auto mode is not generic, so each use case is expected to contain appropriate initialization code. An example of this initialization code will be developed to solve #7424.

Thus, I think no separate work is required on this issue and am closing it. Feel free to re-open if you disagree.

tjaychen commented 2 years ago

@engdoreis has a separate test where we go through this exercise to disable the entropy complex and put it into continuous mode with "FIPS" level entropy. So we could probably use that as an example.