Re: [PATCH 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP)

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

Greg KH wrote:
> On Thu, Dec 05, 2024 at 02:23:15PM -0800, Dan Williams wrote:
> > Changes since the RFC [1]:
> > - Wording changes and cleanups in "PCI/TSM: Authenticate devices via
> >   platform TSM" (Bjorn)
> > - Document /sys/class/tsm/tsm0 (Bjorn)
> > - Replace the single ->exec(@op_code) operation with named operations
> >   (Alexey, Yilun)
> > - Locking fixup in drivers/pci/tsm.c (Yilun)
> > - Drop pci_tsm_devs xarray (Alexey, Yilun)
> > - Finish the host bridge stream id allocator implementation (Alexey)
> > - Clarify pci_tsm_init() relative to IDE && !TEE devices (Alexey)
> > - Add the IDE core helpers
> > - Add devsec_tsm and devsec_bus sample driver and emulation
> > 
> > [1]: http://lore.kernel.org/171291190324.3532867.13480405752065082171.stgit@dwillia2-xfh.jf.intel.com
> > 
> > ---
> > 
> > Trusted execution environment (TEE) Device Interface Security Protocol
> > (TDISP) is a chapter name in the PCI specification. It describes an
> > alphabet soup of mechanisms, SPDM, CMA, IDE, TSM/DSM, that system
> > software uses to establish trust in a device and assign it to a
> > confidential virtual machine (CVM). It is protocol for dynamically
> > extending the trusted computing boundary (TCB) of a CVM with a PCI
> > device interface that can issue DMA to CVM private memory.
> > 
> > The acronym soup problem is enhanced by every major platform vendor
> > having distinct TEE Security Manager (TSM) API implementations /
> > capabilities, and to a lesser extent, every potential endpoint Device
> > Security Manager (DSM) having its own idiosyncratic behaviors around
> > TDISP state transitions.
> 
> Wow, you aren't kidding about the acronym soup problem, this is a mess.
> And does any of this relate to the existing drivers/tee/ subsystem in
> any way?

No relation to the subsystem, but if I understand correctly the modern
AMD security co-processor that runs SEV-SNP firmware is a descendant, at
least conceptually, of the 'amdtee' device.

Meanwhile Intel, RISC-V and ARM implemented new CPU execution modes to
run their platform security software.

> Anyhow, this patch series looks sane, nice work.
> 
> > Note that devsec_tsm is for near term staging of vendor TSM
> > implementations. The expectation is that every piece of new core
> > infrastructure that devsec_tsm consumes must also have a vendor TSM
> > driver consumer within 1 to 2 kernel development cycles.
> 
> How are you going to enforce this?

Mainly by moving slowly and carefully.

> By removing infrastructure?

If necessary.

> Normally we can't add infrastructure unless there's a real user, and
> when you add a real user then you see all the things that need to be
> chagned.

What you see here is only 1/3 of the solution, and it has taken quite a
while to get to this point. Meanwhile there are several "hardware
validation" / RFC quality stacks floating around with the end-to-end
flow supported (3/3 solution).

So, there is a wealth of RFCs to draw from and have near constant line
of sight on the next topic to build an upstream consensus solution.
There is low risk that upstream carries something that does not have 2-3
vendor implementations in mind or needs more than a couple kernel cycles
to follow in behind the sample implementation.

I hope to corral all those vendor staging trees into a unified staging
tree where upstream-ready infra can bubble out of that cauldron, similar
to Paolo's kvm-coco-queue.

> So are you ok with the apis and interfaces moving around over time here?
> I think I only see sysfs files being exported so hopefully this
> shouldn't be that big of a deal for userspace to deal with, but I don't
> know what userspace is supposed to do with any of this, is there
> external tools to talk to / set up, these devices?

For this first 1/3 of the effort I expect just a simple udev policy to
say "for the 4 potential PCIe links that can be encrypted on this host,
these are the 4 endpoint devices that get those resources, echo 1 to
'connect' when you see them".

For the 2nd 1/3 of the effort the ABI changes will be augmenting VFIO,
GUEST_MEM_FD, and IOMMUFD ABI to coordinate secure device assignment to
confidential VMs.

The last 1/3 of the ABI will be guest side to fetch and validate device
certificates and security measurements. Here I expect work-in-progress
efforts like the TDM effort [1] to be the consumer of a new netlink ABI
to pull this security collateral. At least, that was the consensus ABI
discussed at Plumbers in this year's PCI device authentication BoF.

So I expect to still be enjoying a large bowl of acronym soup well into
next year.

[1]: https://github.com/confidential-containers/guest-components/pull/290
     (Samuel, is there a newer version of this somewhere?)