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

[Dan Williams <dan.j.williams@intel.com>]

Lukas Wunner wrote:
> 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.

I would also add that attestation is useful without encryption. The
Thunderclap [1] class of vulnerabilities is concerned with malicious
devices impersonating legitimate ones. Where validating that the device
you think you are talking to also passes a challenge response with a
certificate chain you trust helps to mitigate that attack vector. IDE is
interesting because it is "persistent attestation". Whereas SPDM is a
point in time validation, IDE helps protect against swapping out the
device after the initial SPDM attestation. That event would be signaled
by error handling, making device swap out and interposer attacks more
difficult. I.e. you would need to silence the device swap out and any
upstream device that flags the error.

If Linux adds SPDM support for the value of attestation then I submit
IDE should be considered next.

[1]: https://thunderclap.io/