On Thu, Jan 26, 2023 at 10:24:32AM +0100, Samuel Ortiz wrote: > On Wed, Jan 25, 2023 at 11:03 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > CMA/SPDM (PCIe r6.0 sec 6.31) is in active development on this branch: > > > > https://github.com/l1k/linux/commits/doe > > > > The device authentication service afforded here is generic. > > It is up to users and vendors to decide how to employ it, > > be it for "confidential computing" or something else. > > > > Trusted root certificates to validate device certificates can be > > installed into a kernel keyring using the familiar keyctl(1) utility, > > but platform-specific roots of trust (such as a HSM) could be > > supported as well. > > This may have been discussed at LPC, but are there any plans to also > support confidential computing flows where the host kernel is not part > of the TCB and would not be trusted for validating the device cert chain > nor for running the SPDM challenge? As long as a device is passed through to a guest, the guest owns that device. It is the guest's prerogative and duty to perform CMA/SPDM authentication on its own behalf. If the guest uses memory encryption via TDX or SEV, key material established through a Diffie-Hellman exchange between guest and device is invisible to the host. Consequently using that key material for IDE encryption protects device accesses from the guest against snooping by the host. SPDM authentication consists of a sequence of exchanges, the first being GET_VERSION. When a responder (=device) receives a GET_VERSION request, it resets the connection and all internal state related to that connection. (SPDM 1.2.1 margin no 185: "a Requester can issue a GET_VERSION to a Responder to reset a connection at any time"; see also SPDM 1.1.0 margin no 161 for details.) Thus, even though the host may have authenticated the device, once it's passed through to a guest and the guest performs authentication again, SPDM state on the device is reset. I'll amend the patches so that the host refrains from performing reauthentication as long as a device is passed through. The host has no business mutating SPDM state on the device once ownership has passed to the guest. The first few SPDM exchanges are transmitted in the clear, so the host can eavesdrop on the negotiated algorithms, exchanged certificates and nonces. However the host cannot successfully modify the exchanged data due to the man in the middle protection afforded by SPDM: The challenge/response hash is computed over the concatenation of the exchanged messages, so modification of the messages by a man in the middle leads to authentication failure. Obviously the host can DoS guest access to the device by modifying exchanged messages, but there are much simpler ways for it to do that, say, by clearing Bus Master Enable or Memory Space Enable bits in the Command Register. DoS attacks from the host against the guest cannot be part of the threat model at this point. Thanks, Lukas
