lowRISC / opentitan

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

Re-generating `RndCnst` for each build #16719

Open msfschaffner opened 1 year ago

msfschaffner commented 1 year ago

Similarly to the OTP images, we recently enabled re-generation of random netlist constants for the life cycle state and top-level RndCnst parameters.

For the latter, we ran into CI issues, since in-tree modifications made in the build phase do not persist into the run phase on all platforms, since the two phases can be scheduled as separate jobs. As explained in #16699, software tests relying on scrambled ROM images fail because the ROM scrambling step executed in the run phase through bazel is using the wrong RndCnst for the scrambling key.

In the short term, rerunning top-gen in the run phase with the correct build_seed would be a workaround to enable this flow. Long term, we should add a mechanism to pass the build_seed into the ROM generation step in bazel, similarly to how OTP images are generated.

msfschaffner commented 1 year ago

@sriyerg @timothytrippel @tjaychen @weicaiyang @cindychip

moidx commented 1 year ago

@vogelpi should this be part of the RndCnst efforts? Moving to M2.5. Please move to Backlog if it makes sense. Thanks.

cdgori commented 1 year ago

It's fairly important to have a way to test this re-generation over a number of iterations, in case there is some issue, so I wouldn't suggest backlog here.

timothytrippel commented 1 year ago

After discussion with @msfschaffner

cdgori commented 1 year ago

I don't know what everyone would consider an appropriate number of nightlies to exercise this seeding/regeneration process to be, but something like a ~month's worth feels correct to me.

timothytrippel commented 1 year ago

Moving this to M2.5.2 as we discussed.

msfschaffner commented 1 year ago

Moving into the next milestone since we did not have time for doing this. We do however run regressions on the closed source side with regenerated constants - so this is covered to some extend (although not in the public facing nightlies).

vogelpi commented 6 months ago

@moidx has impact on manufacturing testing to align scrambling config.

vogelpi commented 6 months ago

@moidx and I discussed that enabling this in CI is most likely going to trash the buildsystem caching. Thus, it would be better to setup a weekly test run for this or so.

rswarbrick commented 6 months ago

Could we do it more simply, by checking in a "base" build constant and then adding the week number to it on the fly? That would avoid having to do a "weekly bump".

andreaskurth commented 6 months ago

By @moidx: Problem is understood. Only applicable to DV flow. Integrating it will be painful. Given the timeline we'll probably not be able to address this before closed source. Recommendation is to put into backlog and address any closed source issues if and when they come up. @timothytrippel and I can help with this.

By @vogelpi: Agreed.