Skip to content

Tags: oxidecomputer/hubris

Tags

oxide-rot-1-v1.0.34

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Measure the SP on SP_RESET signal interrupt (#1946)

On SP_RESET asserted, the RoT will measure the entire active SP Hubris
bank (Hubris plus 0xff padding from 0x800_0000 to 0x80f_ffff).
The measurement reliably takes about 0.482 seconds since neither the SP
nor the RoT are doing anything else during this time. This low
measurement time and the existing timeouts and retries used by the
control plane mitigate concerns that were present when the duration was
measured in multiple seconds.

This time could be further reduced. It is currently taking 0.245 seconds
to inject the measurement program into the SP. Each u32 is being sent
and read back separately and retried if there is any error (no errors
have been seen as of yet).

If all is well with the SP, the measurement will match the `Sha3_256`
value represented in the SP Hubris archive in the file named
"img/final.fwid".
 
# Testing SP measurement

Checkout hubris branch `attest-sp`

```sh
APP=$PWD/app/oxide-rot-1/app-dev.toml
ARCHIVE=$(cargo -q xtask print --archive --image-name a $APP)
cargo xtask flash $APP
```

## Measure on SP Reset:

Hit the reset button on the SP or use the SpCtrl.db_reset_sp function:
```sh
humility --archive=$ARCHIVE hiffy -c SpCtrl.db_reset_sp -a delay_ms=10
sleep 13
```

## See traces
The ringbuf trace in `swd` and `attest` tasks have the interesting
information including the time expended:

```sh
humility --archive=$ARCHIVE ringbuf
```

## Dump the attestation log:

```sh
humility --archive=$ARCHIVE hiffy -c Attest.log -a offset=0 -n 256 -o out
hexdump -C out
```
The hexdump is not hard to read directly. The first four bytes are a LE
u32 giving
the number of valid entries. Each entry is a 1-byte discriminator that
is 0_u8 for `Sha3_256` followed by the 32-byte measurement (FWID). There
is space for 16 measurements.

## Notes

  - The RoT only attempts a measurement if it detects an SP reset.
- Existing measurements are cleared if an STLINK power-on is detected or
if an STLINK is on during a measurement attempt. It is observed that
powered-off STLINKs have no effect.
- No SP reset can be captured until the `swd` task has initialized. If
needed, the control plane can request the SP to reset itself which will
result in the RoT measuring the SP.
- The `attest` task has a `reset_log_and_record` function usable only by
the `swd` task (and hiffy for debug builds).
- Closes #2020 by reserving the first slot of the attestation log for
the `swd` task.

sidecar-v1.0.35

website: update the kernel bug page, which has been lagging

This includes the bugs I've found recently, all of which have merged
fixes.

psc-v1.0.33

website: update the kernel bug page, which has been lagging

This includes the bugs I've found recently, all of which have merged
fixes.

oxide-rot-1-v1.0.33

website: update the kernel bug page, which has been lagging

This includes the bugs I've found recently, all of which have merged
fixes.

gimlet-v1.0.34

website: update the kernel bug page, which has been lagging

This includes the bugs I've found recently, all of which have merged
fixes.

sidecar-v1.0.34

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Disable periodic IPCC zero bytes on Grapefruit (#1988)

In the current IPCC design, the SP sends zero bytes periodically when
the channel is idle to guard against the possibility of losing a frame
terminator. On gimlet this causes the UART FIFO to quickly fill up and
so when the channel wakes up there are around 16 bytes to drain and
things move along. On grapefruit/cosmo, however, there is a 4K FIFO in
the FPGA upstream of the SP here so the natural saturation doesn't (yet)
occur as we'd like. The extra zero bytes also make tracing the bus
harder. Disable them for now.

oxide-rot-1-v1.0.32

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Disable periodic IPCC zero bytes on Grapefruit (#1988)

In the current IPCC design, the SP sends zero bytes periodically when
the channel is idle to guard against the possibility of losing a frame
terminator. On gimlet this causes the UART FIFO to quickly fill up and
so when the channel wakes up there are around 16 bytes to drain and
things move along. On grapefruit/cosmo, however, there is a 4K FIFO in
the FPGA upstream of the SP here so the natural saturation doesn't (yet)
occur as we'd like. The extra zero bytes also make tracing the bus
harder. Disable them for now.

sidecar-v1.0.33

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add PCA9545 driver, use on Gimlet + Sidecar (#1974)

It turns out that none of our hardware actually uses the 8-channel part
(except Grapefruit, indirectly through Ruby).

psc-v1.0.32

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add PCA9545 driver, use on Gimlet + Sidecar (#1974)

It turns out that none of our hardware actually uses the 8-channel part
(except Grapefruit, indirectly through Ruby).

oxide-rot-1-v1.0.31

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Add PCA9545 driver, use on Gimlet + Sidecar (#1974)

It turns out that none of our hardware actually uses the 8-channel part
(except Grapefruit, indirectly through Ruby).