Expand description
A uBFT stand-in for measuring super::UbftEngine on one card.
§The problem
The service’s latency only means something when it is measured on the card, at the card’s clock, through the same RTL a uBFT replica would use. But a replica needs peers, a network and a host stack; one card has none of that. The probe plays the replica’s part of the conversation:
probe ──sign request i──▶ UbftEngine ──frame i──▶ probe ──▶ HBM (frame i)
──verify request (header + frame i, message patched in)──▶
◀──verdict i── check: valid unless i was tampered, tag == iRequests go one at a time with gap idle cycles between them, so every
request is isolated and the engine’s own latency counters (see
super) time it. The frame goes to HBM so the host checks every
signature against the software reference and Ed25519.
§Messages
Request i signs the 16 bytes i (LE64) ‖ !i (LE64) with tag i. When
tamper_every is t > 0, every request with i mod t == t − 1 is
verified with message byte 0 flipped, and must be rejected.
In DSig profile 2 (DSIG_MESSAGE_BYTES=64) request i signs a 48-byte
context zero-extended to 64 bytes: i ‖ !i, then those 16 bytes XOR
0xa5, then XOR 0x3c (probe_message_kernel). The sign request is
in layout v2 (tag 0..8, context 8..56) and the verify record is 27
beats: the frame’s last beat carries the message’s first 22 bytes, and
an appended beat the other 42 (as crate::verify::record).
§Feeding the verify request at full rate
The frame is kept in a 32-row block RAM while it arrives. During the verify request the RAM is read one row ahead: the read address is always the row that will be presented next cycle, so a taken beat is replaced by the next one without a bubble.
Structs§
Functions§
- probe_
message_ kernel - The message of request
i:i ‖ !i, little endian (16 bytes); in profile 2 followed by those bytes XOR0xa5and XOR0x3c, then 16 zero bytes (a 48-byte context zero-extended to 64). - ubft_
probe_ kernel - The probe’s logic.