Closed vogelpi closed 2 years ago
I have been discussing this with @mwbranstad and he confirmed that we should look into this.
Have there been any updates on this?
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.
What is the order of operations here once we are in boot_rom to switch to regular entropy?
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.
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.
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.
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?
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.
SGTM as well. Do we need to track the task for enabling continuous mode somewhere, or can software already do this today?
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.
@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.
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