RE: RFC: Plumbers microconf topic: PCI DOE and related.

[Vikram Sethi <vsethi@nvidia.com>]

Hi Jonathan, 

> -----Original Message-----
> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>


> Open Questions / Problems:
> 1. Control which software entity uses DOE.
>    It does not appear to be safe (as in not going to disrupt each other rather
>    than security) for multiple software entities (Userspace, Kernel, TEE,
>    Firmware) to access an individual DOE instance on a device without
>    mediation.  Some DOE protocols have clear reasons for Linux kernel
>    access (e.g. CDAT) others are more debatable.
>    Even running the discovery protocol could disrupt other users. Hardening
>    against such disruption is probably best effort only (no guarantees).
>    Question is: How to prevent this?
>     a) Userspace vs Kernel. Are there valid reasons for userspace to access
>        a DOE? If so do how do we enable that? Does a per protocol approach
>        make sense? Potential vendor defined protocols? Do we need to lock
>        out 'developer' tools such as setpci - or do we let developers shoot
>        themselves in the foot?
>     b) OS vs lower levels / TEE. Do we need to propose a means of telling the
> OS
>        to keep its hands off a DOE?  How to do it?
> 
> 2. CMA support.
>    Usecases for in kernel CMA support and whether strong enough to support
>    native access. (e.g. authentication of VF from a VM, or systems not running
>    any suitable lower level software / TEE)

Any time the device is reset, you'd want to measure again. I'd think every kernel
PF FLR/SBR/CXL reset needs to be followed by a measurement of the device
In kernel. Of course needs bigger discussion on the plumbing/infrastructure
to report the measurement and attest that the measurements post reset are valid.
Instead of native access, could it be mediated via ACPI or UEFI runtime service?
Not clear that ACPI/UEFI would be the appropriate mediator in all cases. 

>    Key / Certificate management. This is somewhat like IMA, but we probably
>    need to manage the certificate chain separately for each CMA/SPDM
> instance.
>    Understanding provisioning models would be useful to guide this work.
> 
> 3. IDE support
>    Is native kernel support worthwhile? Perhaps good to discuss
>    potential usecases + get some idea on priority for this feature.
> 
> 4. Potential blockers on merging emulation support in QEMU. (I'm less sure
>    on this one, but perhaps worth briefly touching on or a separate
>    session on emulation if people are interested? Ben, do you think this
>    would be worthwhile?)
> 
> There are other minor questions we might slip into the discussion, time
> allowing such as need for async support handling in the kernel DOE code.
> 
> For all these features, we have multiple layers on top of underlying PCI so
> discussion of 'how' to support this might be useful.
> 1) Service model - detected at PCI subsystem level, services to drivers.
> 2) Driver initiated mode - library code, but per driver instantiation etc.
> 
> That's what have come up with this morning, so please poke holes in it and
> point out what I've forgotten about.
> 
> Note for an actual CFP proposal, I'll probably split this into at least two.
> Topic 1: DOE only.  Topic 2: CMA / IDE. As there is a lot here, for some topics
> we may be looking at introduce the topic + questions rather than resolving
> everything on the day.
> 
> Thanks,
> 
> Jonathan
> 
> p.s. Perhaps it is a little unusual to have this level of 'planning' discussion
> explicitly on list, but we are working under some unusual constraints and
> inclusiveness and openness always good anyway!