Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[icache] Disable S&P diffusion layer in memory scrambling #2130

Merged
merged 2 commits into from
Jan 19, 2024

Conversation

msfschaffner
Copy link
Contributor

@msfschaffner msfschaffner commented Jan 18, 2024

This re-vendors updated primitives into the Ibex repository and disables the S&P diffusion layer in data scrambling as per lowRISC/opentitan#20788

@msfschaffner
Copy link
Contributor Author

msfschaffner commented Jan 18, 2024

@vogelpi @nasahlpa maybe this can be combined with the vendoring step that you had planned to do?
That way we can fix multiple things at once.

Please go ahead and merge this if it LGTY.

Copy link
Member

@nasahlpa nasahlpa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking care of this, @msfschaffner. LGTM, just added two comments.

@@ -40,13 +40,16 @@ std::vector<uint8_t> scramble_addr(const std::vector<uint8_t> &addr_in,
* @param repeat_keystream Repeat the keystream of one single PRINCE instance if
* set to true. Otherwise multiple PRINCE instances are
* used.
* @param use_sp_layer Use the S&P layer for data diffusion. In HW this is
* disabled by default since it interacts adversely with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can link issue #20788 or the corresponding RFC to highlight why this is the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is actually mentioned already in the description of the parameter in the scrambling primitive (prim_ram_1p_scr). I can add it here, but it'll require another round of vendoring.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're waiting for another change to vendor this in, we can add a link to scramble_model.h as well.

Copy link
Contributor Author

@msfschaffner msfschaffner Jan 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coming in lowRISC/opentitan#20882. I can repeat the vendoring step once @vogelpi has merged his Trivium PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should wait factoring in Trivium in this PR? I think @vogelpi will make some more changes in the code (e.g., #20852).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now factored out the prim change into a separate PR here lowRISC/opentitan#20885. The AES change itself might take more time until it's fully reviewed and approved.

Copy link
Contributor

@rswarbrick rswarbrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks sensible to me, but don't we need to pass 2 for NumDiffRounds as part of the first commit?

If it's possible, it would be really nice if the first commit was "use newer vendored code, but no change in behaviour" and the second commit was "now switch to the new behaviour".

(It's possible I've missed something! Say if so!)

@msfschaffner
Copy link
Contributor Author

msfschaffner commented Jan 18, 2024

This looks sensible to me, but don't we need to pass 2 for NumDiffRounds as part of the first commit?

If it's possible, it would be really nice if the first commit was "use newer vendored code, but no change in behaviour" and the second commit was "now switch to the new behaviour".

(It's possible I've missed something! Say if so!)

We actually do that already ;). ibex_top already overrides the NumDiffRounds parameter with 2 and the second commit in this PR removes that override so that it defaults to 0.

@msfschaffner
Copy link
Contributor Author

Unrelated question, is the readthedocs CI error an intermittent one?

Copy link
Contributor

@vogelpi vogelpi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for the PR @msfschaffner !

The CI error on the documentation step is unrelated to this PR. I'll file an issue.

Update code from upstream repository
https://github.com/lowRISC/opentitan to revision
4cf2479b8e6c9b68b9fe1adba202443d3dbe3ff3

* [prim_trivium] Allow dynamically disabling the lockup protection
  (Pirmin Vogel)
* [scrambling] Add reference to RFC issue (Michael Schaffner)
* [edn] Move prim_edn_req out of prim (Rupert Swarbrick)
* [reggen] Remove the devmode input (Michael Schaffner)
* [prim, rom_ctrl] Remove S&P layer from data scrambling (Michael
  Schaffner)
* [prim] Fix typo in Trivium/Bivium stream cipher primitives (Pirmin
  Vogel)
* [prim] Add scratch Verilator testbench for Trivium/Bivium primitives
  (Pirmin Vogel)
* [prim] Add Trivium/Bivium stream cipher primitives (Pirmin Vogel)
* [chip,dv] update makefile for real_key rom test (Jaedon Kim)
* [dvsim] cast self.seed to 'int' (Jaedon Kim)
* [dvsim] Change systemverilog seed to 32 bits (Hakim Filali)
* [dv] Specialize dv_spinwait_* documentation comments (Rupert
  Swarbrick)

Signed-off-by: Michael Schaffner <msf@opentitan.org>
Signed-off-by: Michael Schaffner <msf@opentitan.org>
@msfschaffner msfschaffner added this pull request to the merge queue Jan 19, 2024
Merged via the queue into lowRISC:master with commit 56413ec Jan 19, 2024
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants