# Overview

This document describes the ROM controller (rom_ctrl). This module attaches as a peripheral to the system bus, and thus follows the Comportability Specification.

The ROM controller interfaces between the system bus and the mask ROM. This ROM has scrambled contents (scrambled with a fixed key, derived from a global constant). The controller is responsible for descrambling these contents on memory fetches.

Unlike the SRAM controller, which performs the equivalent task for SRAM, the ROM controller also contains a ROM checker block. This ROM checker is used to compute a cryptographic hash of the ROM contents just after boot, detecting any malicious changes that have been made to the mask ROM when the system was at rest.

## Features

• Logic for memory and address descrambling
• Post-boot ROM integrity check
• Alert trigger and status CSRs for ROM integrity errors or FSM glitches.

# Theory of Operations

## Block Diagram

The image below shows a high-level block diagram of the module. Blue boxes are instantiations of generic primitives that are used elsewhere on the chip. Green boxes are simple operations; the meat of the design is in the grey boxes.

The upper half of the diagram shows paths for ROM reads when the system is in normal operation. The lower half of the diagram shows the ROM checker. This is triggered by the power manager early in the chip boot sequence to check validity of the ROM image. It runs exactly once, and releases the green multiplexer when it is done.

## ROM access when chip is in operation

Once the chip has booted, ROM accesses are requested over the system TL-UL bus. These come in through the TL-UL SRAM adapter (top-left of block diagram). In normal operation, the green multiplexer will give access to these TL reads. The address is scrambled at the first substitution-permutation network (marked S&P in the diagram).

In parallel with the ROM access, a reduced prim_prince primitive (5 rounds with latency 1; equivalent to the cipher used for SRAM) computes a 39-bit truncated keystream for the block. On the following cycle, the scrambled data from ROM goes through a substitution-permutation network and is then XOR’d with the keystream. This scheme is the same as that used by the SRAM controller, but is much simplified because the ROM doesn’t have to deal with writes, byte accesses or key changes.

The output from the XOR is the unscrambled 32-bit data, plus seven ECC bits. This data is passed straight through the TL-UL SRAM adapter; the ECC bits are used as a signal integrity check by the system bus.

The following diagram shows the timing of the different signals. The time from the req output from the tlul_adapter_sram to the response that appears on its rvalid input is one cycle. The “scrambling scheme” for addresses in the diagram is to reverse their digits. The word stored at address 21 in the ROM is denoted w21. The keystream value for address 12 is denoted k12. The unscrambled ROM data for (logical) address 12 is denoted d12.

The prim_prince primitive and the two substitution-permutation networks are all parameterised by “keys”. For rom_ctrl, these keys are global randomised netlist constants: they are assumed to be difficult to recover, but aren’t considered secret data.

## The startup ROM check

The ROM checker runs immediately after reset. Until it is done, it controls ROM address requests (through the green multiplexer). The select signal for this multiplexer has a redundant encoding to protect it against fault injection attacks. If the select signal has an invalid value, this will trigger a fatal alert. Before starting to read data, it starts a cSHAKE operation on the KMAC module using one of its application interfaces. We expect to use the cSHAKE256 algorithm, with prefix “ROM_CTRL”. The Application Interface section of the KMAC documentation details the parameters used.

The checker reads the ROM contents in address order, resulting in a scattered access pattern on the ROM itself because of the address scrambling. Each read produces 39 bits of data, which are padded with zeros to 64 bits to match the interface expected by the KMAC block. The checker FSM loops through almost all the words in ROM (from bottom to top), passing each to the KMAC block with the ready/valid interface and setting the kmac_data_o.last bit for the last word that is sent. Once the last word has been sent, the FSM releases the multiplexer; this now switches over permanently to allow access through the TL-UL SRAM adapter.

The top eight words in ROM (by logical address) are interpreted as a 256-bit expected hash. Unlike the rest of ROM, their data is not stored scrambled, so the expected hash can be read directly. This is taken by the checker FSM (ignoring ECC bits) and will be compared with the digest that is read back from the KMAC block.

Once it comes back, the digest is forwarded directly to the Key Manager. It is also compared with the hash that was read from the top eight words of ROM. On a match, pwrmgr_data_o.good is signalled as Mubi4True. In either case, pwrmgr_data_o.done goes high when the calculation is complete.

The diagram below shows the operation of the simple FSM.

## What does the ROM check do?

One of the possible physical attacks on a system like OpenTitan is to subvert the mask ROM. The regular structure of a mask ROM is useful because it makes metal fixes easy, but (for the same reasons) it makes the ROM quite an easy target for an attacker. See [SKO-05]1, section 2.1.1, for a description of mask ROMs and attacks on them.

Since the code in ROM is the first thing to execute, an attacker that modifies it undetected can completely subvert the chain of trust. As such, OpenTitan needs some form of ROM integrity checking and the ROM checker is the module in charge of providing it.

After bringing the ROM controller module out of reset, the power manager must wait until pwrgr_data_o.done is asserted before starting the host processor. The ROM controller also passes the pwrmgr_data_o.good signal. The power manager can use this to decide whether to boot (taking into account life cycle state). This provides an extra safety check, but the real security comes from key manager integration described below.

The simple KMAC interface assumes that KMAC is pre-configured to run the cSHAKE algorithm with a prefix specific to the ROM checker. The ROM checker will not assert kmac_data_o.valid after finishing the one and only digest computation. The KMAC module may choose to add a check for this, to detect reset glitches affecting the rom_ctrl block.

The integration with the key manager is based on forwarding the digest data in kmac_data_i as keymgr_data_o.data. This 256-bit digest will be incorporated into the CreatorRootKey. The key manager should only allow one transaction (of 256 bits / 32 bits = 8 beats) after reset to pass this information across. On future messages, it should raise an alert, defeating an attacker that tries to trigger extra transactions before or after the real one.

CreatorRootKey forms the first key in the chain described in Identities and Root Keys. An attacker who modifies the ROM will perturb CreatorRootKey (to avoid doing so would require a preimage attack on the ROM checksum calculation or the KM_DERIVE function). The result is that, while the chip will function, it will have the “wrong” root key and the chain of trust used for attestation will be broken.

## Fault-injection hardening

The core integrity check, flowing from the ROM data to CreatorRootKey, should be infeasible to subvert. However, rom_ctrl also controls bus access to ROM data and interacts with other blocks. To avoid attacks propagating into the rest of the system, we take the following extra hardening steps:

• All internal FSMs are sparsely encoded, with a minimum Hamming distance of 3.
• The “good” signal passed to the power manager is multi-bit encoded. (*)
• The switching signals for the mux are multi-bit encoded (using mubi4_t) (*)
• We check to ensure the mux doesn’t switch back to the checker after giving access to the bus.
• The main FSM has internal consistency checking to ensure that other blocks don’t signal completion when the FSM is in a state that doesn’t expect them to be running.

Items with (*) next to them are not yet implemented in the RTL.

## Hardware Interfaces

Referring to the Comportable guideline for peripheral device functionality, the module rom_ctrl has the following hardware interfaces defined.

Primary Clock: clk_i

Other Clocks: none

Bus Device Interfaces (TL-UL): regs_tl, rom_tl

Bus Host Interfaces (TL-UL): none

Peripheral Pins for Chip IO: none

Interrupts: none

fatal

A fatal error. Fatal alerts are non-recoverable and will be asserted until a hard reset.

Security Countermeasures:

Countermeasure IDDescription
ROM_CTRL.CHECKER.CTR.CONSISTENCY

Once rom_ctrl has handed control of the mux to the bus, the internal FSM counter should point at the top of ROM (where we ensure the word has invalid ECC bits). The unexpected_counter_change signal in rom_ctrl_fsm goes high and generates a fatal alert if that counter is perturbed in any way.

ROM_CTRL.CHECKER.CTRL_FLOW.CONSISTENCY

The main checker FSM steps on internal 'done' signals, coming from its address counter, the KMAC response and its comparison counter. If any of these are asserted at times we don't expect, the FSM jumps to an invalid state. This triggers an alert and will not set the external 'done' signal for pwrmgr to continue boot.

ROM_CTRL.CHECKER.FSM.LOCAL_ESC

The main checker FSM moves to an invalid state on local escalation.

ROM_CTRL.COMPARE.CTRL_FLOW.CONSISTENCY

The hash comparison module triggers a fatal error if the checker FSM triggers a second comparison after a reset. This is handled by the start_alert signal in the rom_ctrl_compare module and could be triggered if the checker FSM was somehow glitched to jump backwards.

ROM_CTRL.COMPARE.CTR.CONSISTENCY

The hash comparison module has an internal count (indexing 32-bit words in the 256-bit digests). If this glitches to a nonzero value before the comparison starts or to a value other than the last index after the comparison ends then an fatal alert is generated. This is handled by the wait_addr_alert and done_addr_alert signals in rom_ctrl_compare.

ROM_CTRL.FSM.SPARSE

FSMs are sparsely encoded. There are two FSMs. The first is in rom_ctrl_fsm. The second, simpler FSM is in rom_ctrl_compare.

ROM_CTRL.MEM.SCRAMBLE

The ROM is scrambled.

ROM_CTRL.MEM.DIGEST

A cSHAKE digest is computed of the ROM contents.

ROM_CTRL.INTERSIG.MUBI

Checker FSM 'done' signal is multi-bit encoded when passed to pwrmgr. This signal is derived from the (multi-bit) sparse FSM state in the rom_ctrl_fsm module.

ROM_CTRL.BUS.INTEGRITY

TL bus control and data signals are integrity protected (using the system-wide end-to-end integrity scheme).

ROM_CTRL.BUS.LOCAL_ESC

To avoid responding to a request with erroneous data, even though an alert went out, the bus_rom_rvalid signal used to signal a response to the ROM-side TL bus can only be high if no internal consistency error has been spotted.

ROM_CTRL.MUX.MUBI

The mux that arbitrates between the checker and the bus is multi-bit encoded. An invalid value generates a fatal alert with the sel_invalid signal in the rom_ctrl_mux module.

ROM_CTRL.MUX.CONSISTENCY

The mux that arbitrates between the checker and the bus gives access to the checker at the start of time and then switches to the bus, never going back. If a glitch does cause it to switch back, a fatal alert is generated with the sel_reverted or sel_q_reverted signals in the rom_ctrl_mux module.

ROM_CTRL.CTRL.REDUN

Addresses from TL accesses are passed redundantly to the scrambled ROM module, to ensure the address lines are not independently faultable downstream of the bus integrity ECC check. See the bus_rom_prince_index and bus_rom_rom_index signals in the rom_ctrl module.

ROM_CTRL.CTRL.MEM.INTEGRITY

End-to-end data/memory integrity scheme.

### Parameters

Parameter Default (Max) Top Earlgrey Description
RndCnstRomKey (see RTL) (see RTL) Compile-time random default constant for scrambling key (used in prim_prince block).
RndCnstRomNonce (see RTL) (see RTL) Compile-time random default constant for scrambling nonce (used in prim_prince block and the two S&P blocks).

### Signals

The table below lists other ROM controller inter-module signals.

Signal Type Destination Description
pwrmgr_data_o rom_ctrl_pkg::pwrmgr_data_t pwrmgr

A structure with two fields. The first, done, becomes true when the ROM check is complete and remains true until reset.

The second, good, is only valid if done is true. This is true if the digest computation matched the expected value stored in the top words of ROM and false otherwise. This field stays constant when done is true.

keymgr_data_o rom_ctrl_pkg::keymgr_data_t keymgr A 256-bit digest, together with a valid signal. Once the ROM check is complete, valid will become true and will then remain true until reset. The digest in data is only valid when valid is true and is be constant until reset.
kmac_data_o kmac_pkg::app_req_t kmac Outgoing data to KMAC. Data is sent in 64-bit words in the data field. When a word of data is available, the valid field is true. When this is the last word of data, the last field is also true. Since we never send partial words, the strb field is always zero.
kmac_data_i kmac_pkg::app_rsp_t kmac Incoming data from KMAC interface. This contains a ready signal for passing ROM data and a done signal that shows a digest has been computed. When done is true, the digest is exposed in two shares (digest_share0 and digest_share1). The error field is ignored.

# Programmer’s Guide

Software will mostly interact with the ROM controller by fetching code or loading data from ROM. For this, the block looks like a block of memory, accessible through a TL-UL window. However, there are a few registers that are accessible. Other than the standard ALERT_TEST register, all are read-only.

The FATAL_ALERT_CAUSE register might change value during operations (if an alert is signalled), but the other registers will all have fixed values by the time any software runs.

To get the computed ROM digest, software can read DIGEST_0 through DIGEST_7. The ROM also contains an expected ROM digest. Unlike the rest of the contents of ROM, this isn’t scrambled. As such, software can’t read it through the standard ROM interface (which would try to unscramble it again, resulting in rubbish data that woud cause a failed ECC check). In case software needs access to this value, it can be read at EXP_DIGEST_0 through EXP_DIGEST_7.

## Register Table

### Registers visible under device interface regs

Reset default = 0x0, mask 0x1
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 fatal
BitsTypeResetNameDescription
0wo0x0fatal

Write 1 to trigger one alert event of this kind.

The cause of a fatal alert.

Reset default = 0x0, mask 0x3

The bits of this register correspond to errors that can cause a fatal alert. Software can read these bits to see what went wrong. Once set, these bits cannot be cleared.

 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 integrity_error checker_error
BitsTypeResetNameDescription
0ro0x0checker_error

Set on a fatal error detected by the ROM checker.

1ro0x0integrity_error

Set on an integrity error from the register interface.

rom_ctrl.DIGEST_0 @ 0x8

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_0... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_0
BitsTypeResetNameDescription
31:0ro0x0DIGEST_0

32 bits of the digest

rom_ctrl.DIGEST_1 @ 0xc

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_1... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_1
BitsTypeResetNameDescription
31:0ro0x0DIGEST_1

For ROM_CTRL1

rom_ctrl.DIGEST_2 @ 0x10

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_2... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_2
BitsTypeResetNameDescription
31:0ro0x0DIGEST_2

For ROM_CTRL2

rom_ctrl.DIGEST_3 @ 0x14

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_3... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_3
BitsTypeResetNameDescription
31:0ro0x0DIGEST_3

For ROM_CTRL3

rom_ctrl.DIGEST_4 @ 0x18

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_4... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_4
BitsTypeResetNameDescription
31:0ro0x0DIGEST_4

For ROM_CTRL4

rom_ctrl.DIGEST_5 @ 0x1c

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_5... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_5
BitsTypeResetNameDescription
31:0ro0x0DIGEST_5

For ROM_CTRL5

rom_ctrl.DIGEST_6 @ 0x20

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_6... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_6
BitsTypeResetNameDescription
31:0ro0x0DIGEST_6

For ROM_CTRL6

rom_ctrl.DIGEST_7 @ 0x24

The digest computed from the contents of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_7... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_7
BitsTypeResetNameDescription
31:0ro0x0DIGEST_7

For ROM_CTRL7

rom_ctrl.EXP_DIGEST_0 @ 0x28

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_0... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_0
BitsTypeResetNameDescription
31:0ro0x0DIGEST_0

32 bits of the digest

rom_ctrl.EXP_DIGEST_1 @ 0x2c

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_1... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_1
BitsTypeResetNameDescription
31:0ro0x0DIGEST_1

For ROM_CTRL1

rom_ctrl.EXP_DIGEST_2 @ 0x30

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_2... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_2
BitsTypeResetNameDescription
31:0ro0x0DIGEST_2

For ROM_CTRL2

rom_ctrl.EXP_DIGEST_3 @ 0x34

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_3... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_3
BitsTypeResetNameDescription
31:0ro0x0DIGEST_3

For ROM_CTRL3

rom_ctrl.EXP_DIGEST_4 @ 0x38

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_4... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_4
BitsTypeResetNameDescription
31:0ro0x0DIGEST_4

For ROM_CTRL4

rom_ctrl.EXP_DIGEST_5 @ 0x3c

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_5... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_5
BitsTypeResetNameDescription
31:0ro0x0DIGEST_5

For ROM_CTRL5

rom_ctrl.EXP_DIGEST_6 @ 0x40

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_6... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_6
BitsTypeResetNameDescription
31:0ro0x0DIGEST_6

For ROM_CTRL6

rom_ctrl.EXP_DIGEST_7 @ 0x44

The expected digest, stored in the top words of ROM

Reset default = 0x0, mask 0xffffffff
 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 DIGEST_7... 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ...DIGEST_7
BitsTypeResetNameDescription
31:0ro0x0DIGEST_7

For ROM_CTRL7

### Registers visible under device interface rom

rom_ctrl.ROM @ + 0x0
8192 item ro window
Byte writes are not supported
 31 0 +0x0 +0x4 ... +0x7ff8 +0x7ffc

ROM data

1. SKO-05: Skorobogatov, Semi-Invasive Attacks - A New Approach to Hardware Security Analysis, University of Cambridge Computer Laboratory Technical Report 630, 2005 ↩︎