On Fri, Nov 06, 2026 at 09:23:44PM +0530, Aneesh Kumar K.V wrote:
quoted
quoted
Does this split require us to guarantee that no GET_VERSION can be
issued in between?
Yes, in my opinion TSM must enforce it because as you said, GET_VERSION
resets everything.
+1
How can TSM enforce this? Another subsystem could issue GET_VERSION
through the DOE mailbox. IIUC, TSM would only detect a transcript
mismatch when KEY_EXCHANGE_RSP validation fails. Is that correct?
Firstly I think nothing but the attestation subsystem driver should
operate the DOE mailbox, certainly not the SPDM flow inside it.
Secondly, yes, the KEY_EXCHANGE should blow up if the session is
interfered with in some way, that is one of it's critical security
tasks.
Third, the kernel needs to keep track of the SPDM session 'generation'
directly and expose it to userspace so there is an unbreakable
continuity from START CONNECT to the final ACCEPT.
I suppose we would need to pass all of those parameters for the host ->
RMM/firmware interaction. I had assumed that the algorithms were the only
negotiated parameters needed for SPDM session establishment. Would validating
Kc and Ks require passing additional details from the RustSPDM exchange to the
firmware?
This is just backwards. The TSM should be in control of the session
from start to end, and the kernel should be inspecting the plain text
messages it sends. We need the TSM to send all the messages we need,
like GET_DIGESTS, GET_CERTIFICATES and so on.
Doing two sesssions is just an inherently less secure idea. We should
not do this unless we get really really stuck. I prefer we change the
TSM interfaces, ie in RMM, to work optimally so we don't need to try
to do this.
Nobody has every done any of this before, all the specs are copying
each other with incomplete implementations. Nobody should be insisting
they can't change.
My main question is whether we should avoid splitting the context and
relying on the host not to disrupt the sequence. I wonder whether that
would be a poor API design and whether we can avoid it. Is that a goal
we should pursue?
The host can interfere with the TSM's DOE operations, that is part of
the threat model and countered by the KEY_EXCHANGE sequence. I don't
see any reason to worry about this as a problem, and we should take
advantage of it to make the flow work naturally under a single
session.
Jason