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 sp_measure: record measurement in attest task #1482

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

Conversation

flihp
Copy link
Contributor

@flihp flihp commented Aug 8, 2023

This is still a work in progress but the basic functionality has been tested successfully on an rot-carrier. This still needs to be integrated w/ the oxide-rot-1 image and tested on a gimlet before merging.

This makes a bit more sense as a default configuration as the
rot-carrier is designed to work with the gimletlet.
@flihp flihp marked this pull request as draft August 8, 2023 16:54
Copy link
Collaborator

@labbott labbott left a comment

Choose a reason for hiding this comment

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

Does it make sense to keep this in a separate task if this is all it's going to do? I know separation yadda yadda but there's overhead to have another task, especially if we're going to be pulling in sha256 each time

app/rot-carrier/app.toml Outdated Show resolved Hide resolved
@flihp
Copy link
Contributor Author

flihp commented Aug 8, 2023

Does it make sense to keep this in a separate task if this is all it's going to do? I know separation yadda yadda but there's overhead to have another task, especially if we're going to be pulling in sha256 each time

That's still the primary driver. Probably worth writing a quick RFD to document whatever decision we make since this is a threat modeling exercise.

@flihp flihp force-pushed the attest-record-spmeasure branch 2 times, most recently from 4bad7f0 to ceba272 Compare August 8, 2023 23:48
This was great for development. Less so now.
`sp_measure` panic's on most / all errors. This causes `jefe` to restart
it. In testing this has casued the `swd` task to get stuck in the
RUNNING state. Better to hold this task than lock up the system.
This task is intended to run once when the system boots and the task it
performs should not be repeated. Jefe will no longer restart this task
and so we could remove the final call to `sys_recv_closed` as well,
however tasks that return from their `main` function are reported as
having executed an illegal instruction. So we leave this call in place
to prevent a scary message from showing up in the task list: `FAULT:
illegal instruction (was: ready)`
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.

None yet

2 participants