[aes] Add intermodule connections and estimated gates for hardening

[vogelpi]

This adds non-functional changes for the bronze netlist. More precisely, it adds:

• intermodule connections to keymgr and csrng,
• estimated gate count for security hardening,
• gate count estimate for local, high-bandwidth PRNG.
• connection to alert handler (split out from [aes] Add shadow CTRL register, interface with alert handler #2152 ).

What is still missing:

• gate count estimate for additional modes (if we decide to go for it)

[vogelpi]

Hey @mwbranstad, @martin-lueker, I went ahead and defined a prototype for the peripheral CSRNG interface according to the figures in your spec. This is for peripherals to request entropy from the CSRNG. Obviously, the interface defined here is just preliminary. I will update this according to what you decide to use/support. Just let me know.

[mwbranstad]

thanks @vogelpi. I looked at it quickly. We need to talk about a number of items, but this starts that discussion. Once more work has been done on csrng, we probably need to set up a meeting to discuss a number of these issues that I have in mind.

[vogelpi]

Sounds good, thanks for the feedback @mwbranstad .

[vogelpi]

I updated the gate generators based on yesterdays discussion. Also the local, high-bandwidth PRNG is now accounted for.

[vogelpi]

Update: I also added the alert handler interface here (split out from #2152).

[eunchan]

So, whether csrng or aes is merged first, I think eventually csrng_pkg in this PR should be removed . right? :)

[vogelpi]

Yep, the csrng_pkg.sv in this PR should eventually be removed. The same also holds for the keymgr_pkg.sv.

[mwbranstad]

@vogelpi why do you think the csrng_pkg will be removed? I would expect that it will not be removed.

[vogelpi]

@vogelpi why do you think the csrng_pkg will be removed? I would expect that it will not be removed.

My understanding is that there will be a PR for the csrng first that contains the crsng_pkg.sv (because the struct definitions currently contained in there, are csrng-specific but aes uses them, probably like other modules that connect to csrng). This is similar to the altert handler interface definitions.

[imphil]

Since we have multiple blocks depending on the CSRNG interface as defined in (a variant of) csrng_pkg.sv (bignum is another example, see #2393), I'd appreciate if we can get the interface definition into OT master as soon as the interface signals have stabilized enough (which seems to be the case already?). The actual implementation and all of that can then come at a later point.

[mwbranstad]

Since there was some urgency to get the csrng package into the v1-bronze level, that is all that has been promoted so far. At this point, indeed a separate PR into the master will be done as soon at the related markdown documentation has matured and will be submitted under the same PR.

[martin-lueker]

Hi @mwbranstad, @imphil: I can certainly see the reason for urgency. However, I think our recent experience has shown that trying to push documentation and RTL in at the same time is a recipe for live revisions and general heartburn ;) . I'm not sure that approach is the best means of effective collaboration.

If possible I'd like to try to keep the next CSRNG PR compact, and really keep the comments focused. I think starting with the doc has to come first. In fact, I could start by migrating my own (background/non-technical) documentation contributions to a MD PR ASAP (which likely means starting tomorrow afternoon). @mwbranstad this would leave you with just the actual IP documentation.

@imphil: I don't know if you can recommend any other way to better move through the PR flow for priority items, but we're truly more than willing to take suggestions.

[imphil]

Thanks @mwbranstad and @martin-lueker for your comments.

I understand that the CSRNG documentation and implementation are rather tricky and large beasts, so things will take time -- no worries about that.

What I'm trying to figure out if we can split out some of that work in a preliminary form that will help us move forward with other IP blocks.

I'm missing one critical piece of information to be able to suggest something more concrete: how stable is the CSRNG interface at this point? Do you expect some small changes like adding auxiliary signals or renamings, or a major overhaul of the interface?

If the interface proposed by Pirmin in https://github.com/vogelpi/opentitan-1/blob/aes-v1-bronze/hw/ip/aes/rtl/csrng_pkg.sv is roughly the one you're aiming to use, I'd be fine with a pull request which puts this file into the hw/ip/csrng/rtl folder, even if there is no documentation or other implementation next to it. This way we can start using the interface definitions in AES, Bignum, and other blocks which need random numbers without duplicating code. You can of course still revise the interface freely as the spec matures, committing things doesn't mean they are frozen.

Please let me know if there's anything I can help with.

[mwbranstad]

@imphil trying to communicate the current plan for the csrng interface. The version going into the v1-bronze is what I would consider near done. The version that the pointer to the aes/rtl is really not what the csrng app interface will be. I have been meaning to get with @vogelpi to discuss this, but that has not happened yet. While this latest version gets moved into v1-bronze, I was planning on a PR for this same package plus other supporting documentation into OT master for a normal review. This is expected to happen fairly soon. This should supply all of the information needed to plan for how to use the interface, and as anticipated, discuss what additional support might be needed.

[imphil]

@mwbranstad sounds good, thanks!

[eunchan]

Could you please take a look at the csrng interface on v1-bronze and revise the interface accordingly? I assume AES talks to CSRNG directly not to Entropy source. the new interface is csrng_pkg::csrng_req/rsp_t.

[vogelpi]

Thanks @eunchan for pinging me. If I understand this correctly, the csrng_req/rsp_t structs in the new csrng_pkg.sv actually describe the more advanced application interface to be used by e.g. the key manager or the rng distribution network. Peripherals such as aes and otbn will not interface to the csrng directly but via the rng distribution network instead and thus use a simplified interface.

It would be great if @mwbranstad or @martin-lueker could clarify this please.

[mwbranstad]

What @vogelpi describes is accurate. @eunchan are meeting soon to sort this out.

[vogelpi]

What @vogelpi describes is accurate. @eunchan are meeting soon to sort this out.

Thanks @mwbranstad for the quick feedback!

[tjaychen]

is the rng distribution network the csrng_entropy_upd struct..?

…

On Tue, Jun 23, 2020 at 9:07 AM Pirmin Vogel ***@***.***> wrote: What @vogelpi <https://github.com/vogelpi> describes is accurate. @eunchan <https://github.com/eunchan> are meeting soon to sort this out. Thanks @mwbranstad <https://github.com/mwbranstad> for the quick feedback! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH2RSUB4KJHC7AEZM5FE63RYDHMXANCNFSM4M2Q7G2A> .

[vogelpi]

Update:

• Rebased on current v1-bronze.
• Updated keymgr interface (now using keymgr_pkg.sv that is already in the tree as part of keymgr)
• Removed csrng peripheral interface/rng distribution network interface to unblock this PR and @eunchan. This interface is still not defined. FYI @mwbranstad and @martin-lueker , this is now tracked in Specify Entropy Distribution Network (EDN) #2693.