RFC: Plumbers microconf topic: PCI DOE and related.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi All,

There have been several mentions already of discussing some of the topics
around DOE mailboxes and the various things they enable at the upcoming
Plumbers VFIO/IOMMU/PCI microconf.

A few references:
https://lore.kernel.org/linux-pci/CAPcyv4i2ukD4ZQ_KfTaKXLyMakpSk=Y3_QJGV2P_PLHHVkPwFw@xxxxxxxxxxxxxx/
https://lore.kernel.org/linux-pci/20210520092205.000044ee@xxxxxxxxxx/

The intent of this email thread is to consolidate those suggestions into
a reasonable list of things to talk about (that I can then put into the
CFP system). Obviously Plumbers is still some time away and we will
"hopefully" resolve some of this stuff on this list before then. Also
open is who will lead this session if accepted.
(Perhaps Dan Williams + myself?)

Note this may be full of inaccuracies and (whilst I've tried not to) some
of my own opinions, so please do poke holes in it!

The latter parts are about CMA / SPDM for which a kernel RFC should be public
shortly (subject to summer holidays etc).

Quick background:

The elephant in the room for this topic is that there is on going related
specification work that we cannot discuss due to various confidentiality
rules. Everything in this email is based on published specs / public
discussions on the mailing lists.
Having said that there is plenty to talk about today, we just might
need a round 2 next year :)

Terms:

DOE - Data Object Exchange (PCI ECN) https://pcisig.com
 * A mailbox in PCI config space.
 
CDAT - Coherent Device Attribute table (UEFI hosted separate public spec)
 * Uses DOE mailbox to retrieve info on (CXL) EP such as bandwidth and
   latency of access to memory. 

CMA - Component Measurement and Authentication (PCI ECN) https://pcisig.com
 * Uses DMTF SPDM 1.1 based exchanges over DOE to authenticate EPs and
   carry out runtime measurements (kind of IMA for devices).

IDE - Integrity and Data Encryption (PCI ECN) https://pcisig.com
 * Link and selective (through switches) encryption.  Uses DOE / SPDM 1.1
   and builds on top of CMA.

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)
   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!




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux