| Message ID | 173343739517.1074769.13134786548545925484.stgit@dwillia2-xfh.jf.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | PCI/TSM: Core infrastructure for PCI device security (TDISP) | expand |
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? 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? By removing infrastructure? 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. 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? thanks, greg k-h
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?)
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. Despite all that opportunity for differentiation, there is a significant portion of the implementation that is cross-vendor common. However, it is difficult to develop, debate, test and settle all those pieces absent a low level TSM driver implementation to pull it all together. The proposal is incrementally develop the shared infrastructure on top of a sample TSM driver implementation to enable clean vendor agnostic discussions about the commons. "samples/devsec/" is meant to be: just enough emulation to exercise all the core infrastructure, a reference implementation, and a simple unit test. The sample also enables coordination with the native PCI device security effort [2]. The devsec_tsm driver is already yielding benefits as it drove many of the fixes and enhancements of this patch-kit relative to the last RFC [1]. Future development would either reuse established devsec_tsm paths, or extend the sample alongside the vendor-specific implementation. This first batch is just enough infrastructure for IDE (link Integrity and Data Encryption) establishment via TSM APIs. It is based on a review and curation of the IDE establishment flows from the SEV-TIO RFC [3] and a work-in-progress TDX Connect RFC (see the Co-developed-by and thanks yous in the changelogs for where code was copied). It deliberately avoids SPDM details and does not touch upon the "bind" flows, or guest-side flows, simply to allow for upstream digestion of all the assumptions and tradeoffs for the "simple" IDE establishment baseline. 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. The full series is available via devsec/tsm.git [4]. [2]: http://lore.kernel.org/cover.1719771133.git.lukas@wunner.de [3]: http://lore.kernel.org/20240823132137.336874-1-aik@amd.com [4]: https://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm.git/log/?h=devsec-20241205 --- Dan Williams (11): configfs-tsm: Namespace TSM report symbols coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/ coco/tsm: Introduce a class device for TEE Security Managers PCI/IDE: Selective Stream IDE enumeration PCI/TSM: Authenticate devices via platform TSM samples/devsec: PCI device-security bus / endpoint sample PCI: Add PCIe Device 3 Extended Capability enumeration PCI/IDE: Add IDE establishment helpers PCI/IDE: Report available IDE streams PCI/TSM: Report active IDE streams samples/devsec: Add sample IDE establishment Documentation/ABI/testing/configfs-tsm-report | 0 Documentation/ABI/testing/sysfs-bus-pci | 42 + Documentation/ABI/testing/sysfs-class-tsm | 20 + .../ABI/testing/sysfs-devices-pci-host-bridge | 39 + MAINTAINERS | 10 drivers/pci/Kconfig | 16 drivers/pci/Makefile | 2 drivers/pci/ide.c | 311 +++++++++ drivers/pci/pci-sysfs.c | 4 drivers/pci/pci.h | 34 + drivers/pci/probe.c | 15 drivers/pci/remove.c | 3 drivers/pci/tsm.c | 293 ++++++++ drivers/virt/coco/Kconfig | 8 drivers/virt/coco/Makefile | 3 drivers/virt/coco/arm-cca-guest/arm-cca-guest.c | 8 drivers/virt/coco/guest/Kconfig | 7 drivers/virt/coco/guest/Makefile | 3 drivers/virt/coco/guest/report.c | 32 - drivers/virt/coco/host/Kconfig | 6 drivers/virt/coco/host/Makefile | 6 drivers/virt/coco/host/tsm-core.c | 145 ++++ drivers/virt/coco/sev-guest/sev-guest.c | 12 drivers/virt/coco/tdx-guest/tdx-guest.c | 8 include/linux/pci-ide.h | 33 + include/linux/pci-tsm.h | 83 ++ include/linux/pci.h | 22 + include/linux/tsm.h | 33 + include/uapi/linux/pci_regs.h | 92 +++ samples/Kconfig | 15 samples/Makefile | 1 samples/devsec/Makefile | 10 samples/devsec/bus.c | 695 ++++++++++++++++++++ samples/devsec/common.c | 26 + samples/devsec/devsec.h | 7 samples/devsec/tsm.c | 192 ++++++ 36 files changed, 2185 insertions(+), 51 deletions(-) rename Documentation/ABI/testing/{configfs-tsm => configfs-tsm-report} (100%) create mode 100644 Documentation/ABI/testing/sysfs-class-tsm create mode 100644 Documentation/ABI/testing/sysfs-devices-pci-host-bridge create mode 100644 drivers/pci/ide.c create mode 100644 drivers/pci/tsm.c create mode 100644 drivers/virt/coco/guest/Kconfig create mode 100644 drivers/virt/coco/guest/Makefile rename drivers/virt/coco/{tsm.c => guest/report.c} (93%) create mode 100644 drivers/virt/coco/host/Kconfig create mode 100644 drivers/virt/coco/host/Makefile create mode 100644 drivers/virt/coco/host/tsm-core.c create mode 100644 include/linux/pci-ide.h create mode 100644 include/linux/pci-tsm.h create mode 100644 samples/devsec/Makefile create mode 100644 samples/devsec/bus.c create mode 100644 samples/devsec/common.c create mode 100644 samples/devsec/devsec.h create mode 100644 samples/devsec/tsm.c base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37