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

[Lukas Wunner <lukas@wunner.de>]

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.

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/

On the other hand, I'm poring over Jonathan's latest kernel SPDM/CMA
patches and they're not very large, hence seem upstreamable.

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.

(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.)

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...

Thanks,

Lukas