sled-agent: add RoT attestation endpoints by luqmana · Pull Request #9739 · oxidecomputer/omicron

luqmana · 2026-01-28T23:44:21Z

This covers the sled agent portion of https://github.com/orgs/oxidecomputer/projects/159?pane=issue&itemId=139850060 by exposing a new set of APIs a propolis instance will call.

I hooked up the existing verifier-cli tool with a new sled-agent-client-based interface to exercise the new APIs (playing the role of propolis):

BRM42220026 # ./verifier-cli --interface sled-agent --sled-addr '[fde2:c3cc:fbe3:101::1]:12345' log | tee log.json
{"index":1,"measurements":[{"Sha3_256":[127,251,54,168,183,58,224,201,42,83,6,65,4,185,67,222,122,251,50,182,251,85,202,12,37,122,102,35,50,21,169,102]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"Sha3_256":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}]}

BRM42220026 # ./verifier-cli --interface sled-agent --sled-addr '[fde2:c3cc:fbe3:101::1]:12345' cert-chain > chain.pem
BRM42220026 # openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout
subject=C = US, O = Oxide Computer Company, CN = alias
issuer=C = US, O = Oxide Computer Company, CN = device-id

subject=C = US, O = Oxide Computer Company, CN = device-id
issuer=C = US, O = Oxide Computer Company, CN = PDV1:913-0000019:006:BRM42220026

subject=C = US, O = Oxide Computer Company, CN = PDV1:913-0000019:006:BRM42220026
issuer=C = US, O = Oxide Computer Company, CN = Platform Identity Staging Intermediate 20780377

subject=C = US, O = Oxide Computer Company, CN = Platform Identity Staging Intermediate 20780377
issuer=C = US, O = Oxide Computer Company, CN = Platform Identity Staging Root A

BRM42220026 # ./verifier-cli verify-cert-chain --ca-cert /usr/share/oxide/idcerts/staging.pem chain.pem && echo chain verified
chain verified

BRM42220026 # awk '/BEGIN CERTIFICATE/ {p=1} p; /END CERTIFICATE/ {exit}' chain.pem > alias-cert.pem

BRM42220026 # perl -e "print '0'x64" | xxd -r -p > nonce.bin
BRM42220026 # ./verifier-cli --interface sled-agent --sled-addr '[fde2:c3cc:fbe3:101::1]:12345' attest nonce.bin | tee attestation.sig
{"Ed25519":[249,0,91,88,42,203,67,7,219,178,216,2,171,173,99,190,207,245,241,234,153,92,23,83,6,198,205,190,243,167,93,42,222,236,217,106,64,233,143,226,105,24,252,145,119,15,109,108,67,130,172,249,106,116,65,248,183,48,110,77,63,39,112,5]}

BRM42220026 # ./verifier-cli verify-attestation --alias-cert alias-cert.pem --log log.json --nonce nonce.bin attestation.sig && echo attestation verified
attestation verified

labbott · 2026-01-29T19:41:37Z

sled-agent/types/versions/src/add_rot_attestation/attestation.rs

+            chain.into_iter().map(|cert| cert.to_pem(LineEnding::LF)).collect();
+        Ok(CertificateChain(certs?))
+    }
+}


It seems a little odd to have this and other conversion methods here. Can we push this lower into the rot modules to just return the type directly?

Can we push this lower into the rot modules to just return the type directly?

I'm not sure I follow here. As in, change the types RotAttestationHandle::get_measurement_log/get_certificate_chain/attest take/return?

For the conversions, I had them here just to keep them close to the definitions which seem to be normal from a quick rg 'impl (Try)?From' sled-agent/types/versions/src

Yeah I was thinking of changing the types returned from RotAttestationHandle to return the inventory types directly. There's a lot of TryFrom and From but that's for conversion between internal inventory types. There isn't another great example of other inventory types doing a lot of external conversions in sled-agent/types/versions/src/impls/ but if nobody else has a problem I think it's fine for it to stay as is.

Got it, makes sense -- moved things around in fad57df.

sled-agent/types/versions/src/add_rot_attestation/attestation.rs

sled-agent/src/rot.rs

sled-agent/src/http_entrypoints.rs

luqmana · 2026-02-03T23:57:43Z

Dropped the attestation code I had in the local omicron ipcc crate and switched to using dice-verifier. Besides deduplicating, that comes with the nice upside of being able to use the AttestMock impl for non-gimlet setups (piggy-backing off sprockets' AttestConfig in sled-agent's config.toml).

hawkw · 2026-02-05T18:40:52Z

sled-agent/src/rot.rs

+    #[error("Failed to create IPCC attestor: {0}")]
+    AttestIpcc(#[from] dice_verifier::ipcc::IpccError),
+
+    #[error("Failed to create mock attestor: {0}")]
+    AttestMock(#[from] mock::AttestMockError),
+
+    #[error("Attestation request failed: {0}")]
+    Attest(#[from] AttestError),
+
+    #[error("RoT attestation queue full")]
+    Busy,
+
+    #[error("RoT attestation task gone - request cancelled")]


super nitpicky, but: i think typically the preferred style for these errors is to put the first character in lower-case, since they might be wrapped in another error and formatted like: failed to foo: couldn't get bar: invalid baz, and it looks weird if it's like failed to foo: Couldn't get bar: invalid baz

Sure – updated all but the last 2 (to preserve the intended "RoT" capitalization).

hawkw · 2026-02-05T18:42:18Z

sled-agent/src/rot.rs

+    /// This should be run via `spawn_blocking` as we perform ipcc operations
+    /// via an ioctl and don't want to block any other tasks.


I kinda wonder if it would be better to have run do the spawn_blocking call internally, if calling it outside of a spawn_blocking is always wrong?

Made new and run private and instead now provide a launch method that does both and ensures the semantics we want.

hawkw · 2026-02-05T18:43:10Z

sled-agent/types/versions/src/add_rot_attestation/attestation.rs

+impl fmt::Display for Rot {
+    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
+        match self {
+            Rot::Oxide => write!(f, "oxide"),
+        }
+    }
+}


nit, take it or leave it: this could be derived using strum

hawkw · 2026-02-05T18:45:28Z

sled-agent/types/versions/src/add_rot_attestation/attestation.rs

+
+impl fmt::Debug for Sha3_256Digest {
+    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
+        f.debug_tuple("Sha3_256Digest").field(&hex::encode(self.0)).finish()


nit: I feel like it's generally considered bad form to allocate in a fmt::Debug impl, and hex::encode will, regretfully, allocate a String which we will then write to f and immediately drop. is there another crate that can wrap a byte array in a thing that implements fmt::Debug to format it in hex without allocating a string?

not a huge deal as we're probably not going to fmt::Debug these in a performance critical path, but...it would be nice...

Went and added such a wrapper (BytesToHexDebug) to omicron_common and dropped the use of hex::encode here.

hawkw · 2026-02-05T18:45:56Z

sled-agent/types/versions/src/add_rot_attestation/attestation.rs

+
+impl fmt::Debug for Ed25519Signature {
+    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
+        f.debug_tuple("Ed25519Signature").field(&hex::encode(self.0)).finish()


similar hex::encode sadness here, not a huge deal.

No more sadness! Switched to the new BytesToHexDebug here as well.

hawkw · 2026-02-05T19:06:00Z

sled-agent/Cargo.toml

 # Only used by the simulated sled agent.
 crucible-agent-client.workspace = true
 derive_more.workspace = true
+dice-verifier = { workspace = true, features = ["ipcc", "mock"] }


is it possible to only enable the mock stuff in the sled-agent sim? is that worth doing?

No, this is actually for running real sled-agent but on a non-"gimlet":

omicron/smf/sled-agent/non-gimlet/config.toml

Line 124 in 558f89e

attest = { which = "local", priv_key = "/opt/oxide/sled-agent/pkg/test-alias-1.key.pem", cert_chain = "/opt/oxide/sled-agent/pkg/test-alias-1.certlist.pem", log = "/opt/oxide/sled-agent/pkg/sprockets-log.bin", test_corpus = [ "/opt/oxide/sled-agent/pkg/testing-measurements/corim-rot.cbor", "/opt/oxide/sled-agent/pkg/testing-measurements/corim-sp.cbor"] }

hawkw · 2026-02-05T19:16:36Z

sled-agent/src/rot.rs

+pub struct RotAttestationTask {
+    log: Logger,
+    rx: mpsc::Receiver<RotAttestationMessage>,
+    attest: Box<dyn Attest + Send>,
+}


maybe worth a comment someplace explaining that this is an actor task thingy as it has unique ownership over the attest instance?

Added a blurb there with some more details.

… to sled_agent::rot

…revent misuse

luqmana force-pushed the luqmana/rot-attest branch from 54163d9 to e4f73c5 Compare January 28, 2026 23:56

luqmana mentioned this pull request Jan 29, 2026

verifier: add sled-agent implementation for Attest oxidecomputer/dice-util#347

Open

luqmana force-pushed the luqmana/rot-attest branch from e4f73c5 to de2a8d9 Compare January 29, 2026 19:11

labbott reviewed Jan 29, 2026

View reviewed changes

jgallagher reviewed Jan 29, 2026

View reviewed changes

sled-agent/src/rot.rs Outdated Show resolved Hide resolved

sled-agent/src/rot.rs Outdated Show resolved Hide resolved

sled-agent/src/http_entrypoints.rs Show resolved Hide resolved

luqmana force-pushed the luqmana/rot-attest branch 6 times, most recently from fad57df to 44ce979 Compare February 3, 2026 23:54

luqmana force-pushed the luqmana/rot-attest branch from 3dc1e06 to 8f2c2eb Compare February 5, 2026 02:10

hawkw reviewed Feb 5, 2026

View reviewed changes

luqmana added 10 commits February 5, 2026 21:31

sled-agent: add RoT attestation endpoints

492b753

sled-agent: bail with 529 if rot queue full

c01d5a1

sled-agent: Add comments to RoT attestation types.

69920df

sled-agent: make RoT attestation Nonce type an enum

1700978

sled-agent: make the choice of RoT explicit in attestation endpoints

95673c8

sled-agent: don't fail startup if no ipcc handle on non-oxide

501101f

sled-agent-types-versions: move RoT attestation type conversions down…

5f7f241

… to sled_agent::rot

Use dice-verifier for both ipcc and mock attestation.

f08ed11

Cargo.toml/lock: switch to main branch for dice-verifier

4d8dda9

sled-agent/rot: add some comments and RotAttestationTask::launch to p…

6519128

…revent misuse

luqmana force-pushed the luqmana/rot-attest branch from 8f2c2eb to 2a7011c Compare February 5, 2026 22:34

luqmana added 2 commits February 6, 2026 01:02

Replace allocating hex::encode with BytesToHexDebug wrapper.

47cdecd

sled-agent: add doc comments to RoT endpoints

5561a2c

luqmana force-pushed the luqmana/rot-attest branch from 2a7011c to 5561a2c Compare February 6, 2026 01:04

		/// This should be run via `spawn_blocking` as we perform ipcc operations
		/// via an ioctl and don't want to block any other tasks.

Conversation

luqmana commented Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

luqmana commented Feb 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

luqmana commented Jan 28, 2026 •

edited

Loading