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

WIP - Measure the SP on SP_RESET signal interrupt #1946

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from
Draft

Conversation

lzrd
Copy link
Contributor

@lzrd lzrd commented Dec 13, 2024

This is a work in progress. Measurement currently takes 12.8s and we'd like to improve that or accommodate that delay before merging.

That's in addition to any feedback that people may have.

Testing SP measurement

Checkout hubris branch attest-sp

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:

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:

humility --archive=$ARCHIVE ringbuf

Dump the attestation log:

humility --archive=$ARCHIVE hiffy -c Attest.log -a offset=0 -n 256 -o out
hexdump -C out

Run the measurement without resetting the SP:

humility --archive=$ARCHIVE hiffy -T20 -c SpCtrl.db_measure_sp

Notes

  • The SP starts quicker than the RoT so the power-on reset of the SP is not being captured
  • The attest task needs a reset_log_and_record function usable only by the swd task.
  • If the SP has a powered dongle attached, a purposely invalid measurement will be logged to the attest task. Is that the right thing to do? TBD.
  • the db_measure_sp and db_reset_sp are there for development and will be removed before merge. It should be sufficient to reset the SP if attestation needs to be refreshed.
  • This has only been tested on grapefruit so far.

lzrd added 6 commits December 12, 2024 15:08
Add interrupt-related API calls to the LPC55 `gpio_driver`.

A task on an LPC55 can now configue and use GPIO interrupts.

app.toml example shows Pin Interrupt configuration:

[tasks.foo]
...
interrupts = { "pint.irq0" = "button-irq" }
...
task-slots = ["gpio_driver", ...]

[tasks.foo.config]
pins = [
  { name="BUTTON', pin={ port=1, pin=9}, alt=0, pint=0, direction="input", opendrain="normal" }
]
…API.

The functions:

fn {clear,detected,disable,enable}_{rising,falling,status}(PintSlot)
and
fn read_pint_status(...)

become

fn pint_op(PintSlot, PintOp, PintCondition)

This leaves a couple permutations not covered (enable/disable
interrupt at the NVIC level).
Those can are left as no-ops for the time being.

Future: The unimplemented combinations could return an error/fault
if called.
…EADME.md

Feedback response: Fix idl/lpc55-pins.idol to use Option<PintSlot>.
Feedback response: Collapse the many PINT calls in lpc55-pins.idol to one `pint_op`
Generate separate GPIO pin setup functions for named pins.
This allows easier switching between pin configurations at runtime.
Hiffy commands db_measure_sp and db_reset_sp are there temporarily for
testing.
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.

1 participant