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

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Sat, 7 May 2022 12:18:48 +0200
Lukas Wunner <lukas@wunner.de> wrote:

> On Fri, May 06, 2022 at 03:40:25PM -0700, Dan Williams wrote:
> > On Tue, May 3, 2022 at 8:35 AM Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> > So, like you, I was envisioning all the CMA and SPDM code landing in
> > the kernel until I read this:
> > 
> > "Extending in-kernel TLS support"
> > https://lwn.net/Articles/892216/
> > 
> > ...and questioned why this new CMA/SPDM session establishment, which
> > is similar to TLS, be done inside the kernel while TLS session
> > establishment is done in userspace? I had a chance to chat with Chuck
> > at LSF/MM and confirmed there is little appetite to change this
> > up-call requirement for session establishment and expect CMA to be the
> > same. The rough idea of how this works with CMA/SPDM is providing an
> > ABI to retrieve session setup data with the end result of userspace
> > instantiating a keyid via keyctl the to be used for future SPDM
> > messages.  
> 
> I'm still somewhat undecided on the kernel vs. user space question.

Likewise.  I feel a few more prototypes are needed to come to clear
conclusion.

> 
> The simplest approach would be to expose DOE to user space and just
> let it send the requests necessary for setting up an SPDM session
> as well as IDE.
> 
> Jonathan posted patches a while ago to expose a DOE chrdev:
> https://lore.kernel.org/all/20210524133938.2815206-5-Jonathan.Cameron@huawei.com/

Discussions at Plumbers last year (and on list) concluded that generic
interface was probably a non starter, but something SPDM specific should
be fine. (even if it's just that generic interface with a check that it
is the right DOE protocol ;)
> 
> On the other hand, I'm poring over Jonathan's latest kernel SPDM/CMA
> patches and they're not very large, hence seem upstreamable.

That ended up rather cleaner than I expected. Though note that series doesn't get
quite as far as secure channel setup which is the point where a
userspace stack might hand over to kernel.  It should be a fairly trivial
addition though.

> 
> It would be nice to have the kernel auto-detect that a PCI device
> supports IDE and create a directory in sysfs as a result.  The user
> would just drop certificates there which are added to a keyring
> and the kernel would automatically try to set up an SPDM session
> with one of the certificates and bring up IDE encryption.  Binding of
> drivers to devices could be delayed until IDE is set up, as could be
> enumeration of devices below a hot-plugged, IDE-capable PCIe switch.

Not sure interface would look exactly like that, but the point in general
is good.

> 
> (I can think of plenty of use cases, some good, some evil.
> Such as preventing malicious / forged devices from being used,
> but also vendors and employers controlling what people plug into
> their machines.  Brave new world.)

We could do driver specific 'blocking' until the 'authorized' bit Dan suggested
is set by userspace (after attestation) and end up with somewhat
similar security.  The only real difference being that a malicious device
might have more driver code to attack than it would if we blocked
the driver starting at all.  That would depend on how the driver was
implemented.

> 
> Of course, it would probably be possible to implement all of this
> in user space but it might not be as seamless.
> 
> I just fear that we may become a laughing stock for security researchers
> with a kernel-only implementation.  Kind of like "ASN.1 parsing at ring 0":
> https://x41-dsec.de/lab/blog/kernel_userspace/
> 
> I have some feedback on Jonathan's SPDM/CMA patches and will send it
> out in a bit...

Cool. Though I suspect those will be parked for now as 'sufficient' for
discussion.  Next step is to mock up what the alternative looks like...

Good to capture the feedback while it's fresh on basis we might end up back there!

Jonathan


> 
> Thanks,
> 
> Lukas
>