Re: [PATCH v2 09/18] PCI/CMA: Validate Subject Alternative Name in certificates

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

Lukas Wunner wrote:
> PCIe r6.1 sec 6.31.3 stipulates requirements for Leaf Certificates
> presented by devices, in particular the presence of a Subject Alternative
> Name which encodes the Vendor ID, Device ID, Device Serial Number, etc.
> 
> This prevents a mismatch between the device identity in Config Space and
> the certificate.  A device cannot misappropriate a certificate from a
> different device without also spoofing Config Space.  As a corollary,
> it cannot dupe an arbitrary driver into binding to it.  Only drivers
> which bind to the device identity in the Subject Alternative Name work
> (PCIe r6.1 sec 6.31 "Implementation Note: Overview of Threat Model").
> 
> The Subject Alternative Name is signed, hence constitutes a signed copy
> of a Config Space portion.  It's the same concept as web certificates
> which contain a set of domain names in the Subject Alternative Name for
> identity verification.
> 
> Parse the Subject Alternative Name using a small ASN.1 module and
> validate its contents.  The theory of operation is explained in a
> comment at the top of the newly inserted code.
> 
> This functionality is introduced in a separate commit on top of basic
> CMA-SPDM support to split the code into digestible, reviewable chunks.
> 
> The CMA OID added here is taken from the official OID Repository
> (it's not documented in the PCIe Base Spec):
> https://oid-rep.orange-labs.fr/get/2.23.147
> 
> Side notes:
> 
> * PCIe r6.2 removes the spec language on the Subject Alternative Name.
>   It still "requires the leaf certificate to include the information
>   typically used by system software for device driver binding", but no
>   longer specifies how that information is encoded into the certificate.
> 
>   According to the editor of the PCIe Base Spec and the author of the
>   CMA 1.1 ECN (which caused this change), FPGA cards which mutate their
>   device identity at runtime (due to a firmware update) were thought as
>   unable to satisfy the previous spec language.  The Protocol Working
>   Group could not agree on a better solution and therefore dropped the
>   spec language entirely.  They acknowledge that the requirement is now
>   under-spec'd.  Because products already exist which adhere to the
>   Subject Alternative Name requirement per PCIe r6.1 sec 6.31.3, they
>   recommended to "push through" and use it as the de facto standard.
> 
>   The FPGA concerns are easily overcome by reauthenticating the device
>   after a firmware update, either via sysfs or pci_cma_reauthenticate()
>   (added by a subsequent commit).
> 
> * PCIe r6.1 sec 6.31.3 strongly recommends to verify that "the
>   information provided in the Subject Alternative Name entry is signed
>   by the vendor indicated by the Vendor ID."  In other words, the root
>   certificate on pci_cma_keyring which signs the device's certificate
>   chain must have been created for a particular Vendor ID.
> 
>   Unfortunately the spec neglects to define how the Vendor ID shall be
>   encoded into the root certificate.  So the recommendation cannot be
>   implemented at this point and it is thus possible that a vendor signs
>   device certificates of a different vendor.
> 
> * Instead of a Subject Alternative Name, Leaf Certificates may include
>   "a Reference Integrity Manifest, e.g., see Trusted Computing Group" or
>   "a pointer to a location where such a Reference Integrity Manifest can
>   be obtained" (PCIe r6.1 sec 6.31.3).
> 
>   A Reference Integrity Manifest contains "golden" measurements which
>   can be compared to actual measurements retrieved from a device.
>   It serves a different purpose than the Subject Alternative Name,
>   hence it is unclear why the spec says only either of them is necessary.
>   It is also unclear how a Reference Integrity Manifest shall be encoded
>   into a certificate.

I think this analysis is sufficient to justify the Linux requirement for
Subject-Alternative-Name. I agree that it seems odd that an FPGA that
changes its id also does not have a way to provision an updated
certificate at the same time. Like I would expect if the new bitstream
is signed then it can also deploy an updated certificate in the same
bitstream.

Unless and until commericial devices arrive that violate the expectation
with no way to update the certificate would Linux need a workaround, and
even then it would appear to be an explicit quirk.

I can see debug scenarios where it would be useful to relax this
requirement, but that can be achieved with local hacks, no need pressing
need to ship that debug facility upstream.

Acked-by: Dan Williams <dan.j.williams@intel.com>

...don't feel comfortable offering a reviewed-by on ASN parsing.