On Mon, May 16, 2022 at 10:01:26AM -0700, Dan Williams wrote: > On Sat, May 14, 2022 at 6:55 AM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > Circling back to the SPDM/IDE topic, while NVMe is now capable of > > reliably recovering from errors, it does expect the kernel to handle > > recovery within a few seconds. I'm not sure we can continue to > > guarantee that if the kernel depends on user space to perform > > re-authentication with SPDM after reset. That's another headache > > that we could avoid with in-kernel SPDM authentication. > > What is missing from this conversation is what constitutes a device > leaving the trusted compute boundary and is the existing attestation > invalidated by a reset. I.e. perhaps the kernel can just do a > keep-alive heartbeat after the reset with the already negotiated key > to confirm the session is still valid. After a bit of digging in the spec I think I can answer your question. Any type of reset (both Conventional Reset and FLR) "must result in all IDE Streams associated with that Function transitioning to the Insecure state, and all keys must be invalidated and rendered unreadable." (PCIe r6.0, sec 6.33.8). So IDE is always gone after reset and needs to be re-established. An SPDM session is necessary for that. Does a reset affect SPDM? It depends on the type of reset: A FLR "must not change the state of the secure session" (PCIe r6.0, sec 6.31.4). But for a Conventional Reset, the situation seems to be different: The CMA/SPDM section of the spec doesn't say what happens to an SPDM session upon a Conventional Reset, but sec 6.6.1 clearly states that "all Port registers and state machines must be set to their initialization values as specified in this document, except for sticky registers". So I think we must assume that the SPDM session is gone after a Conventional Reset. DPC results in a Conventional Reset at the port where it occurs and also propagates a Hot Reset down the hierarchy (see ea401499e943). The bottom line is that after DPC, both the SPDM session as well as IDE need to be re-established, requiring the certificate validation which is controversial here when performed at the kernel level. (As an aside, sec 6.6.2 lists the registers not affected by a FLR but neglects to mention the SPDM/CMA session state. I think that's an erratum, I've requested access to the protocol workgroup to report that.) Thanks, Lukas
