Re: [RFC v3 00/27] lib: Rust implementation of SPDM

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

Jonathan Cameron wrote:
[..] 
> From a simple case of 'what is here' in this set, the only bit I'm seeing
> change in order to implement what I think you and Jason are describing is we
> don't bother checking the cert chain in kernel for the first time: We
> provide that to userspace to decide if it's good. If I understand
> correctly, this will be at the end of the full sequence once we've pushed
> through a nonce and gotten signatures + measurements.  Same as checking a
> TSM provided transcript. That was sort of happening anyway if we consider
> the .cma keyring as just providing a short cut filter if we didn't trust
> the device provided root cert.
> User space got the transcripts before it had to make any decision on
> binding and could do anything it liked with them.

Exactly, the kernel checking the cert is not sufficient to establish
trust in the device interface (Link + MMIO). If userspace is making a
driver-bind or TDISP accept decision, it needs
certs+measurements+interface-report and does not benefit from the kernel
also validating the certificate.

> For that caching the public key bit, I'm not clear on whether you intend
> to do that from kernel side (which I think I'd prefer) or have user space
> squirt that key back in again?  If we are doing it in kernel we can
> at least always verify the transcript is self consistent and refuse to
> give anything to user space if it's not consistent (other than debug material).
> By self consistent I mean we verify the signature against the device provided
> cert (might as well verify whole chain as that's trivial given we have to partly
> parse them anyway to find the cert).  I don't think it maters hugely if
> we do this in kernel beyond advantage of removing a few foot guns and
> simplifying the userpace interface to "I'm fine with the provided transcript
> for use when I'm not here next time" write. Disadvantage is we use the
> cert parsing code (which is there anyway) and parse it all twice - once
> in kernel and probably again in userspace or at some remote verifier.

Right, the proposal is cache the public-key from pci_tsm_ops::connect()
and at least require that the resulting transcript from that session
establishment is properly self-signed. No point in continuing with a TSM
implementation that is not self-consistent.

> Measurement verification (in kernel) is potentially a trickier bit of ABI
> design as the space of what might be in there and what matters for a given
> device is complex to say the least.  Only a small part of that is spec
> defined.
> 
> I can see there may be some use cases where we relax things beyond this
> (potentially including .cma keyring and root cert only)

So I expect there will be an extended tail of problems to solve from
same device and same measurements checks, to full recovery into the TCB.
A .cma keyring may be a part of that eventually, but the "as simple as
possible, but no simpler" starting point is userspace device policy
wrapped around self-signed evidence.

If the device interface is adversarial, mere trust in the SPDM session
is insufficient to protect against the type of attacks that re-checking
the certificate only after reset/resume is meant to mitigate.