Hi James, On Wed, Feb 07, 2024 at 04:46:36PM -0500, James Bottomley wrote: > Just to correct this: IMA uses its own log format, but I think this was > a mistake long ago and the new log should use TCG2 format so all the > tools know how to parse it. At last year's Plumbers BoF on PCI device authentication & encryption, you requested that the kernel exposes proof of SPDM signature validation so that user space can verify after the fact that the kernel did everything correctly. Your above comment seems to indicate that you prefer TCG2 CEL as the format to expose the information, however the format seems ill-suited for the purpose: Per TCG PFP v1.06r52 sec 3.3.7, an SPDM CHALLENGE event merely logs the nonce used. That's not sufficient to verify the signature: The signature is computed over a hash of the concatenation of all the messages exchanged with the device: * GET_VERSION request + VERSION response * GET_CAPABILITIES request + CAPABILITIES response * NEGOTIATE_ALGORITHMS request + ALGORITHMS response * GET_DIGESTS request + DIGESTS response * GET_CERTIFICATE request + CERTIFICATE response (can be multiple) * CHALLENGE request + CHALLENGE_AUTH response The content of those SPDM messages is not necessarily static: E.g. the SPDM requester (the kernel) presents all supported algorithms and the SPDM responder (the device) selects one of them. If only the nonce is saved in the log, the verifier in user space would need to know exactly which algorithms were supported by the SPDM requester at the time the request was sent (could since have changed through a kernel update). It also needs to know exactly which algorithm the SPDM responder picked. Armed with the knowledge which algorithm bits were set, the verifier would have to reconstruct the messages that were exchanged between SPDM requester and responder so that it can calculate the hash over their concatenation and verify the signature. The algorithm selection is but one example of bits that can vary between different requesters/responders and between different points in time. The SPDM protocol allows a great deal of flexibility/agility here. The nonces sent by requester and responder are not the only bits that are variable, is what I'm trying to say. Storing the nonces in the log is sufficient to prove their freshness, but it is not sufficient to prove correct validation of the signature. I'd have to store the full concatenation of all exchanged SPDM messages in the log to facilitate that. Personally I have no problem doing so, but it won't be possible with the CEL format as currently specified by TCG. So on the one hand I'd like to fulfil your Plumbers request to expose proof of correct signature validation and on the other hand you're requesting CEL format which is insufficient to fulfil the request. I don't really know how to reconcile that. I do see value in exposing the full concatenation of all exchanged SPDM messages: It would allow piping that into wireshark or tshark to decode the messages into human-readable form, which might be useful for debugging SPDM communication with the device. In fact, an SPDM dissector for wireshark already exists, though it's not up-to-date (last change 3 years ago) and probably needs a cleanup before it can be upstreamed: https://github.com/jyao1/wireshark-spdm/ I'm considering adding a custom sysfs interface which exposes the last, say, 64 SPDM events of each device, comprising: * type of event (CHALLENGE or GET_MEASUREMENTS) * timestamp * all exchanged messages * hash of all exchanged messages * hash algorithm used * signature received from device * certificate chain used for signature validation The memory consumption for all that data would be significant and the format wouldn't be TCG2 CEL, but it would fulfil your request to provide proof of signature verification. Thoughts? Thanks, Lukas
