Re: [RFC PATCH 0/1] DOE usage with pcie/portdrv

From: Lukas Wunner <lukas@wunner.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Gavin Hindman <gavin.hindman@intel.com>,
	Linuxarm <linuxarm@huawei.com>,
	"Weiny, Ira" <ira.weiny@intel.com>,
	Linux PCI <linux-pci@vger.kernel.org>,
	linux-cxl@vger.kernel.org, CHUCK_LEVER <chuck.lever@oracle.com>
Subject: Re: [RFC PATCH 0/1] DOE usage with pcie/portdrv
Date: Fri, 27 May 2022 11:39:28 +0200	[thread overview]
Message-ID: <20220527093928.GA11083@wunner.de> (raw)
In-Reply-To: <CAPcyv4izKEGKw0L=QkTxp8MMfuWxzF9Rz4Bb_F0rRRiy_+2m8w@mail.gmail.com>

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@wunner.de> 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