[mask rom] Address Pseudocode Issues
Signed-off-by: Sam Elliott <selliott@lowrisc.org>
diff --git a/sw/device/mask_rom/boot.md b/sw/device/mask_rom/boot.md
index 99e6c38..2e8b2fe 100644
--- a/sw/device/mask_rom/boot.md
+++ b/sw/device/mask_rom/boot.md
@@ -40,13 +40,13 @@
// Chip-specific startup functionality
// **Open Q:** Proprietary Software Strategy.
// - Clocks
- // - AST / Entropy. **Open Q:** Is this needed for SRAM Scrambling?
+ // - AST / Entropy.
// - Flash
// - Fuses
chip_specific_startup();
// Manufacturing boot-strapping intervention.
- // **Open Q:** How does the mask rom deal with chip recovery?
+ // **Open Q:** How does the Mask ROM deal with chip recovery?
// **Open Q:** Pin Strapping Configuration.
manufacturing_boot_strap();
@@ -106,7 +106,7 @@
// the current ROM_EXT.
root_key_identity = derive_and_lock_creator_root_key_inputs(measurements);
- // **Open Q:** Does mask rom just lock down key manager inputs, and let the
+ // **Open Q:** Does Mask ROM just lock down key manager inputs, and let the
// ROM_EXT load the key?
load_root_key(root_key_identity);
@@ -117,10 +117,7 @@
// PMP Region for ROM_EXT (2.c.v)
// **Open Q:** Integration with Secure Boot Hardware
- // **Open Q:** Do we need to lock down Mask ROM at final jump? How sensitive
- // is the mask rom itself? We may end up with a jump routine
- // just past a page boundary, as SRAM is non-executable.
- // Alternatively, we may only lock some regions of the mask rom.
+ // **Open Q:** Do we need to prevent access to Mask ROM after final jump?
pmp_unlock_rom_ext();
// Transfer Execution to ROM_EXT (2.c.vi)
@@ -203,11 +200,9 @@
// Will actually be written in assembly
crt_init() {
// - Load `.data` initial image into SRAM.
- // - Zero `.bss` section
- // **Open Q:** Is this required? We'll have zeroed all of SRAM already.
- // - Zero stack
- // **Open Q:** Is this required? We'll have zeroed all of SRAM already.
- // - Load `sp`, `gp`
+ // - Zero `.bss` section.
+ // - Zero stack.
+ // - Load `sp`, `gp`.
// **Open Q:** These are used by exception and interrupt handlers if written
// in C. Should they be initialized as early as possible? We can turn off
// the use of `gp` fairly easily, `sp` is an ABI issue.
@@ -219,21 +214,16 @@
This is where, depending on lifecycle state, new flash images may be loaded onto
the device (usually during manufacturing).
-**Open Q:** How do we need to harden this?
- (Yes if we don't validate the image before executing).
-
-**Open Q:** Do we want hardware support for hardening this?
+**Open Q:** Do we want hardware hardening for this?
There are suggestions around having the hardware return `nop` when reading
this memory if we're not in the correct lifecycle state.
```c
manufacturing_boot_strap() {
- // 1. Reads lifecycle state to establish whether bootstrapping is allowed and
- // what kind
- // 2. Loads flash image if allowed.
- // 3. Directly execute flash image
- // **Open Q:** Should we reset before we execute the flash image (to reuse
- // the rom_ext_manifest checking functionality).
+ // 1. Read lifecycle state to establish whether bootstrapping is allowed.
+ // 2. Determine what kind of bootstrapping is being requested.
+ // 3. Load ROM_EXT image into flash if allowed.
+ // 4. Reboot device (causing loaded ROM_EXT to be verified then executed).
}
```
@@ -245,15 +235,14 @@
// - initilized flash_ctrl DIF (for accessing flash info page)
// Returns:
// - boot policy struct
- // Open Qs: What boot policies do we allow?
+ // **Open Q:** What boot policies do we allow?
// - Active ROM_EXT selector (there are only two ROM_EXT slots) (2.b, 2.c.i)
// - What to do if digest doesn't match (2.c.ii)
// - What to do if signature doesn't verify (2.c.iii)
// - What to do if system measurements are not right (2.c.iv)
- // - What to do if final jump does not succeed (2.c.vi)
// 1. Uses dif_flash_ctrl to issue read of boot info page.
- // 2. pull this into a struct to return.
+ // 2. Pull this into a struct to return.
}
```
@@ -265,7 +254,7 @@
// - ROM_EXT manifest
// - Handles for Peripheral DIFs
- // When and How do we lock down peripheral configuration?
+ // **Open Q:** When and How do we lock down peripheral configuration?
// - We configure based on ROM_EXT manifest (signed)
// - Only locks down these peripherals if info is provided.
@@ -273,7 +262,7 @@
// - Alert Manager
// - Pinmux / Padctrl
// - Entropy Configuration
- // - anything else?
+ // - Anything Else?
// This is explicitly a separate step from locking the key manager inputs. In
// particular, this depends on the ROM_EXT's choices, whereas the key manager
