Re: [RFC PATCH v3 3/4] PCI/CMA: Initial support for Component Measurement and Authentication ECN

[Lukas Wunner <lukas@wunner.de>]

On Fri, Sep 23, 2022 at 04:36:34PM -0500, Bjorn Helgaas wrote:
> On Tue, Sep 06, 2022 at 12:15:55PM +0100, Jonathan Cameron wrote:
> > --- /dev/null
> > +++ b/drivers/pci/cma.c
> > @@ -0,0 +1,117 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Component Measurement and Authentication was added as an ECN to the
> > + * PCIe r5.0 spec.
> 
> It looks like PCIe r6.0, sec 6.31?  (Oh, I see that's what you mention
> above in the Kconfig text :))  I have absolutely no idea what CMA is
> about or how it works.  Other than pci_doe_submit_task(), nothing here
> is recognizable to me as PCI-related and I can't tell what else, if
> anything, is connected to something in the PCIe spec.

CMA is an adaption of the SPDM spec to PCIe.

Basically this is about authenticating PCI devices:
The device presents a certificate chain to the host;
The host needs to trust the root of that certificate chain;
The host sends a nonce to the device;
The device signs the nonce with its private key, sends it back;
The host verifies the signature matches the certificate (= public key).

The protocol to perform this authentication is called SPDM:
https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.2.1.pdf

Various other specs besides PCIe have adopted SPDM (e.g. CXL).

One transport over which the SPDM message exchanges are sent is PCI DOE,
which appears in v6.0.

So-called measurements can be retrieved after authentication was
completed successfully:  E.g. a signed hash of the firmware.
Thereby, the host can verify the device is in a trusted state.

"Attestation" appears to be a fancy terminus technicus which encompasses
authentication and validation of measurements.

Authentication forms the basis for IDE (PCI TLP encryption,
PCIe r6.0 sec 6.33).  Encryption is useless without authentication
because it's otherwise susceptible to man-in-the-middle attacks.

Authentication also forms the basis for TDISP (Trusted I/O virtualization,
recently accepted as an ECN).

There was an SPDM BoF at Plumbers last week:
https://lpc.events/event/16/contributions/1304/attachments/1029/1974/LPC2022-SPDM-BoF-v4.pdf
https://lpc.events/event/16/abstracts/1301/

The outcome is that we'll be working towards a minimal CMA implementation
which is capable of authenticating PCI devices and presenting the result in
sysfs.  There might be a global policy knob in sysfs to control handling
of devices for which authentication failed (e.g. forbid binding to
drivers).  Features such as a per-device policy can later be added on top
if need be.  We'll need to rework DOE handling such that the PCI core
scans all DOE mailboxes on device enumeration to look for one capable
of SPDM and perform authentication.  We'll seek to upstream this though
the PCI tree.  That's my summary in brief, Jonathan or Dan may have
amendments or corrections to make. :)

Thanks,

Lukas