8000 opentitan: Add ROM_EXT-compatible ePMP setup. by jrvanwhy · Pull Request #4034 · tock/tock · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

opentitan: Add ROM_EXT-compatible ePMP setup. #4034

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

Merged
merged 2 commits into from
Jun 18, 2024

Conversation

jrvanwhy
Copy link
Contributor

The existing ePMP code was developed and tested in environments that use a test ROM. On the real silicon, we instead use a ROM_EXT, which passes a different ePMP config to Tock than the test ROM. In particular, it:

  1. Sometimes configures and locks entries 0 and 1 (depends on which ROM_EXT is in use).
  2. Sets up several entries in a manner that works for Tock, but without the lock bit set.
  3. Disables the Rule Lock Bypass bit (this breaks the dance the current constructor does with the MMIO region).

This ePMP config is documented at https://opentitan.org/book/sw/device/silicon_creator/rom_ext/doc/si_val.html#epmp.

This PR renames the existing EarlGreyEPMP constructor to new_test_rom, and introduces a new constructor for use with a ROM_EXT, called simply new. This constructor makes use of the ROM_EXT's existing layout to make ePMP configuration much simpler; it pretty much just locks down the ROM_EXT's config in place.

This has been tested and verified to work on OpenTitan silicon.

The existing ePMP code was developed and tested in environments that use a test ROM. On the real silicon, we instead use a ROM_EXT, which passes a different ePMP config to Tock than the test ROM. In particular, it:

1. Sometimes configures and locks entries 0 and 1 (depends on which ROM_EXT is in use).
2. Sets up several entries in a manner that works for Tock, but without the lock bit set.
3. Disables the Rule Lock Bypass bit (this breaks the dance the current constructor does with the MMIO region).

This ePMP config is documented at https://opentitan.org/book/sw/device/silicon_creator/rom_ext/doc/si_val.html#epmp.

This PR renames the existing EarlGreyEPMP constructor to `new_test_rom`, and introduces a new constructor for use with a ROM_EXT, called simply `new`. This constructor makes use of the ROM_EXT's existing layout to make ePMP configuration much simpler; it pretty much just locks down the ROM_EXT's config in place.

This has been tested and verified to work on OpenTitan silicon.
@jrvanwhy jrvanwhy requested a review from lschuermann June 17, 2024 22:03
@github-actions github-actions bot added the WG-OpenTitan In the purview of the OpenTitan working group. label Jun 17, 2024
lschuermann
lschuermann previously approved these changes Jun 17, 2024
Copy link
Member
@lschuermann lschuermann 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 great to me, generally. Just one minor nit with the mseccfg documentation.

Also, I think that we should update the constructor of new_test_rom to explicitly lock down regions 2 & 3, now that they're unused (in order to be compatible to the regular new), like so:

          // Set the appropriate `pmpcfg0` register value:
          //
          // 0x80 = 0b10000000, for start address of the kernel .text TOR entry
          //        setting L(7) = 1, A(4-3) = OFF, X(2) = 0, W(1) = 0, R(0) = 0
          //
          // 0x8d = 0b10001101, for kernel .text TOR region
          //        setting L(7) = 1, A(4-3) = TOR,   X(2) = 1, W(1) = 0, R(0) = 1
+         //
+         // 0x80 = 0b10000000, for disabled padding regions 2 & 3 (to be
+         //        compatible with the non test-rom constructor)
+         //        setting L(7) = 1, A(4-3) = OFF, X(2) = 0, W(1) = 0, R(0) = 0
-         csr::CSR.pmpcfg0.set(0x00008d80);
+         csr::CSR.pmpcfg0.set(0x80808d80);

Comment on lines 497 to 508
8000
// ---------- PMP machine CSRs configured, lock down the system

// Finally, unset the rule-lock bypass (RLB) bit. If we don't have a
// debug memory region provided, further set machine-mode lockdown (we
// can't enable MML and also have a R/W/X region). We also set MMWP for
// good measure, but that shouldn't make a difference -- it can't be
// cleared anyways as it is a sticky bit.
//
// Unsetting RLB with at least one locked region will mean that we can't
// set it again, thus actually enforcing the region lock bits.
//
// Set RLB(2) = 0, MMWP(1) = 1, MML(0) = 1
Copy link
Member

Choose a reason for hiding this comment

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

From what I understand, the new ROM_EXT will already have this exact(?) mseccfg CSR value set for us. If that is the case, I'm by no means opposed to keeping this write in to make this explicit, but we might want to update the comment documenting this expectation.

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 ROM_EXT I'm working with actually sets 0x2 (MMWP, but not MML or RLB). I've updated the documentation to just say we're enabling MML.

@lschuermann
Copy link
Member

We'll probably also want to update the in-tree board to use the new_test_rom constructor (in essence not changing it's ePMP instantiation, except for having one less userspace region available), at least until we update to a bitstream where the new, locked-down EXT_ROM ships by default.

…be compatible with the rom_ext constructor, and reviewer-suggested doc fixes.
@jrvanwhy
Copy link
Contributor Author

Also, I think that we should update the constructor of new_test_rom to explicitly lock down regions 2 & 3, now that they're unused (in order to be compatible to the regular new), like so:

Done.

We'll probably also want to update the in-tree board to use the new_test_rom constructor (in essence not changing it's ePMP instantiation, except for having one less userspace region available), at least until we update to a bitstream where the new, locked-down EXT_ROM ships by default.

It currently uses new_debug, so I decided to leave it as-is.

@bradjc bradjc added this pull request to the merge queue Jun 18, 2024
Merged via the queue into tock:master with commit 5a65d68 Jun 18, 2024
12 checks passed
@alevy
Copy link
Member
alevy commented Jun 18, 2024

Question: does this (and if so how) impact the qemu virtualized opentitan?

@jrvanwhy
Copy link
Contributor Author
jrvanwhy commented Jun 18, 2024

Question: does this (and if so how) impact the qemu virtualized opentitan?

I renamed EarlGreyEPMP::new to EarlGreyEPMP::new_test_rom; it should still work on QEMU as-is. I really doubt that the new EarlGreyEPMP::new function I added in this PR will work on QEMU.

The only change to EarlGreyEPMP::new_test_rom is to lock out one of the regions that was previously used for userspace (which is to give it the same functionality in practice as EarlGreyEPMP::new).

@lschuermann
Copy link
Member

@alevy One other insight is that (upstream) QEMU does not faithfully emulate any of OpenTitan's ROMs right now. So on QEMU, the default constructors that we have will fail their pre-configuration checks, unless we pass an option that explicitly disables these (at risk of ending up with a configuration that's not secure or soft-bricks the chip, depending on the exact hardware configuration that we start with).

@jrvanwhy jrvanwhy deleted the tock-new-rom_ext branch January 31, 2025 00:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WG-OpenTitan In the purview of the OpenTitan working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0