linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhi Wang <zhiw@nvidia.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-coco@lists.linux.dev,
	"Isaku Yamahata" <isaku.yamahata@intel.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	"Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Xu Yilun" <yilun.xu@linux.intel.com>,
	"Wu Hao" <hao.wu@intel.com>, "Samuel Ortiz" <sameo@rivosinc.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
	"Sami Mujawar" <sami.mujawar@arm.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Steven Price" <steven.price@arm.com>,
	"Xiaoyao Li" <xiaoyao.li@intel.com>,
	"Yilun Xu" <yilun.xu@intel.com>,
	"Alexey Kardashevskiy" <aik@amd.com>,
	"John Allen" <john.allen@amd.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	gregkh@linuxfoundation.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP)
Date: Wed, 7 May 2025 13:47:27 +0300	[thread overview]
Message-ID: <20250507134727.5384d33b@inno-thin-client> (raw)
In-Reply-To: <174107245357.1288555.10863541957822891561.stgit@dwillia2-xfh.jf.intel.com>

On Mon, 03 Mar 2025 23:14:14 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

Hi Dan,

Thanks for the patches!

I tested this patch series along with the example devices you provided,
and it works well. The current design and interface reflect the outcomes
of our numerous discussions during kernel SIG meetings with Gobi and
our brainstorm sessions at tech summits.

From my perspective, it should fit most modern TDISP devices, such as
GPUs and other accelerators, although the TDI bind interfaces are
still under discussion.

It's great to see this patch series progressing from the early RFC stage
to a formal merge request, definitely a significant step for bringing
TDISP support is in the mainline and benefits end-users.

It would be helpful if a minimal (my gut feeling would be it could be
very much basically functional, e.g. support one device and one IDE
stream, no advanced features) Intel TSM driver could be added later. So
that we can validate this framework basically on the Intel platform, and
confidently gives an Acked-by:

Z.

> Changes since v1 [1]:
>  - [configfs-tsm: Namespace TSM report symbols]
>    - collect tags
>  - [coco/guest: Move shared guest CC infrastructure to
> drivers/virt/coco/guest/]
>    - collect tags
>  - [coco/tsm: Introduce a core device for TEE Security Managers]
>    - Rename 'tsm_subsys' => 'tsm_core_dev' (Jonathan)
>  - [PCI/IDE: Enumerate Selective Stream IDE capabilities]
>    - Fix the reference PCIe 6.2 specification chapter to 7.9.26
> (Bjoen)
>    - Treat all specification terms as proper nouns, like "Stream ID"
> (Bjorn)
>    - Rename PCI_IDE_LINK_STREAM to PCI_IDE_LINK_STREAM_0 to indicate
>      first of a series (Jonathan)
>    - Stop saving sel_ide_cap in pci_dev as it is not a capability
> block (Jonathan)
>    - Add support for the "Configuration cycles over Selective Stream"
>      mechanism (Alexey, Jonathan)
>    - Cache the number of Link Stream register blocks in pci_dev to
> save IDE capability re-reads
>    - Clarify 'from Endpoint to Root Port' comment in pci_ide_init()
>      (Jonathan)
>    - Fix "Number of Selective IDE Streams Supported" 1-based field
>      interpretation (Aneesh, Yilun, Jonathan)
>    - Switch all register mask definitions to use __GENMASK() to fix
>      bugs, cleanup readability, and support usage of
> FIELD_{PREP,GET}() in ide.c (Alexey, Jonathan, Yilun, Aneesh)
>  - [PCI/TSM: Authenticate devices via platform TSM]
>    - Line wrap documentation, and fixup fidelity to specification
>      terminology (Bjorn)
>    - Prepare for calling tsm_ops->probe() for Physical Functions
> beyond 0 and Virtual Functions, introduce 'struct pci_tsm_pf0' as the
>      object to wrap 'struct pci_tsm' in the Physical Function 0 case.
>      Call tsm_ops->probe() and tsm_ops->remove() for all functions on
> a device if Physical Function 0 sets pdev->tsm. (Yilun, Aneesh)
>    - Drop the complicated 'struct pci_dsm' scheme (Alexey)
>    - Fix tsm->state validation, 'init before connect' (Yilun)
>    - Move on from if_not_guard(), but not onto the whitespace column
>      pressure of scoped_cond_guard() (Jonathan)
>    - Rename pci_tsm_register() pci_tsm_core_register() to disambiguate
>      from device init in pci_tsm_init() (Jonathan)
>  - [samples/devsec: Introduce a PCI device-security bus + endpoint
> sample]
>    - Fix CONFIG_VIRT_DRIVERS=n compilation dependency (0day Kbuild
> Robot)
>    - Switch from a single devm action to remove emulated devices and
>      ports to a per-device / per-port scheme (Jonathan)
>    - Fix "Number of Selective IDE Streams Supported"
>    - Use devm_gen_pool_create() (Jonathan)
>  - [PCI: Add PCIe Device 3 Extended Capability enumeration]
>  - [PCI/IDE: Add IDE establishment helpers]
>    - Drop PCI_IDE_SETUP_ROOT_PORT and its related complications. Push
>      Root Port programming responsibility to leaf drivers. (Alexey,
>      Jonathan, Bjorn)
>    - Clarify that some TSM technologies do not allow system-software
> to allocate the Stream ID (Aneesh)
>    - Fundamentally rework the API to stop tying the Stream ID to the
>      Endpoint register block index, the Root Port register block
> index, and the platform stream slot. Add pci_ide_strem_alloc() to grab
>      those resources and clarify that Stream IDs only need to be
> unique within a Partner Port pairing. The 'struct pci_ide' object is
>      updated accordingly to carry all the Partner Port details.
> (Alexey, Jonathan, Aneesh)
>    - Add kernel-doc commentary for all exported APIs (Bjorn)
>    - Miscellaneous specific terminology fixups and pci.h comment
>      cleanups (Bjorn)
>    - Drop address association setup for now given the questions around
>      its value (Alexey, Yilun)
>    - Switch from "devid" to "RID" to match specification language,
> add a comment to address the discrepancy in Linux terms vs PCIe spec
>      terms (Bjorn)
>    - Setup RID association registers relative to which RIDs are seen
> at either Partner Port (Yilun, Alexey)
>  - [PCI/IDE: Report available IDE streams]
>    - Rename pci_set_nr_ide_streams() to pci_ide_init_nr_streams() to
>      clarify why this one symbols is in the "PCI_IDE" symbol namespace
>      since PCI init code is typically built-in. (Alexey)
>    - Fix missing quotes in usage of EXPORT_SYMBOL_NS_GPL() and
>      MODULE_IMPORT() (Alexey)
>  - [PCI/TSM: Report active IDE streams]
>    - Documentation fixups (Bjorn)
>    - Rename tsm_register_ide_stream() to tsm_ide_stream_register() for
>      naming consistency
>    - Reflect that the format of the stream link changed from:
>      pciDDDD:BB/streamN:DDDD:BB:DD:F
>      ...to:
>      pciDDDD:BB/streamH.R.E:DDDD:BB:DD:F
>  - [samples/devsec: Add sample IDE establishment]
>    - Mirror the devsec_tsm_disconnect() sequence in the
>      devsec_tsm_connect() error unwind path (Jonathan)
>    - Other miscellaneous symmetry on error unwind fixups (Jonathan)
> 
> [1]:
> http://lore.kernel.org/173343739517.1074769.13134786548545925484.stgit@dwillia2-xfh.jf.intel.com
> 
> ---
> Towards devsec-next:
> 
> As evidenced by a full page of change notes from v1 to v2 there is
> multi-party interest in this core infrastructure, and more
> importantly, many small details to negotiate. That number of details
> to negotiate only increases with the follow-on "device bind" flows
> and the interactions across VFIO, IOMMUFD and KVM.
> 
> I expect it will continue to be the case that the mainline ingestion
> rate of all this infrastructure results in several more cycles before
> mainline ships a complete solution for one or more vendors. In the
> meantime, I am looking to run a devsec-next integration tree for
> kernel and QEMU. That is, a supplemental staging tree to enable
> end-to-end testing while proposals make their way upstream. For now,
> consider sending a branch and I will aim to do periodic octopus
> merges of submitted branches on top of a kvm-coco-queue + devsec-core
> baseline.
> 
> The main motivation for a "devsec-next" tree, as I mentioned to some
> in the hallway track at Plumbers, is to wrangle private hacks and
> workarounds in vendor trees to coalesce if not mature.  An example of
> multiple vendors solving the same problem in different ways in their
> vendor trees is: [2] vs [3]. Note that devsec-next is not intended to
> replace vendor trees, and instead reflect the snapshot state of
> cross-vendor consensus before topics are ready for linux-next /
> mainline.
> 
> I will send out more details as a follow up.
> 
> [2]: https://github.com/aik/qemu/commit/5256c41f
> [3]:
> http://lore.kernel.org/20250217081833.21568-1-chenyi.qiang@intel.com
> 
> ---
> Original Cover letter:
> 
> 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 [4].
>    
> The devsec_tsm driver 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 [5] 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 [6].
> 
> [4]: http://lore.kernel.org/cover.1719771133.git.lukas@wunner.de
> [5]: http://lore.kernel.org/20240823132137.336874-1-aik@amd.com
> [6]:
> https://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm.git/log/?h=devsec-20250303
> 
> ---
> 
> 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 core device for TEE
> Security Managers PCI/IDE: Enumerate Selective Stream IDE capabilities
>       PCI/TSM: Authenticate devices via platform TSM
>       samples/devsec: Introduce a 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            |   45 +
>  Documentation/ABI/testing/sysfs-class-tsm          |   20 +
>  .../ABI/testing/sysfs-devices-pci-host-bridge      |   44 +
>  MAINTAINERS                                        |   10 
>  drivers/pci/Kconfig                                |   37 +
>  drivers/pci/Makefile                               |    2 
>  drivers/pci/ide.c                                  |  499
> ++++++++++++++ drivers/pci/pci-sysfs.c                            |
>  4 drivers/pci/pci.h                                  |   19 +
>  drivers/pci/probe.c                                |   26 +
>  drivers/pci/remove.c                               |    3 
>  drivers/pci/tsm.c                                  |  377 +++++++++++
>  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                  |  144 ++++
>  drivers/virt/coco/sev-guest/sev-guest.c            |   12 
>  drivers/virt/coco/tdx-guest/tdx-guest.c            |    8 
>  include/linux/pci-ide.h                            |   60 ++
>  include/linux/pci-tsm.h                            |  135 ++++
>  include/linux/pci.h                                |   25 +
>  include/linux/tsm.h                                |   33 +
>  include/uapi/linux/pci_regs.h                      |   89 +++
>  samples/Kconfig                                    |   16 
>  samples/Makefile                                   |    1 
>  samples/devsec/Makefile                            |   10 
>  samples/devsec/bus.c                               |  698
> ++++++++++++++++++++ samples/devsec/common.c
>   |   26 + samples/devsec/devsec.h                            |    7 
>  samples/devsec/tsm.c                               |  192 ++++++
>  36 files changed, 2564 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: 7eb172143d5508b4da468ed59ee857c6e5e01da6
> 


      parent reply	other threads:[~2025-05-07 10:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-04  7:14 [PATCH v2 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP) Dan Williams
2025-03-04  7:14 ` [PATCH v2 01/11] configfs-tsm: Namespace TSM report symbols Dan Williams
2025-03-05 10:11   ` Steven Price
2025-03-10 16:26   ` Sathyanarayanan Kuppuswamy
2025-03-10 22:19   ` Huang, Kai
2025-03-04  7:14 ` [PATCH v2 02/11] coco/guest: Move shared guest CC infrastructure to drivers/virt/coco/guest/ Dan Williams
2025-03-10 16:26   ` Sathyanarayanan Kuppuswamy
2025-03-10 22:57   ` Huang, Kai
2025-04-18 23:28     ` Dan Williams
2025-03-04  7:14 ` [PATCH v2 03/11] coco/tsm: Introduce a core device for TEE Security Managers Dan Williams
2025-03-04  7:14 ` [PATCH v2 04/11] PCI/IDE: Enumerate Selective Stream IDE capabilities Dan Williams
2025-03-11  5:46   ` Aneesh Kumar K.V
2025-03-11  6:33     ` Alexey Kardashevskiy
2025-04-25 21:03       ` Dan Williams
2025-03-04  7:14 ` [PATCH v2 05/11] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2025-04-16  5:33   ` Aneesh Kumar K.V
2025-04-25 22:51     ` Dan Williams
2025-03-04  7:14 ` [PATCH v2 06/11] samples/devsec: Introduce a PCI device-security bus + endpoint sample Dan Williams
2025-03-11 14:17   ` [PATCH v2 06/11] samples/devsec: Introduce a PCI device-security Suzuki K Poulose
2025-03-11 14:45     ` [RESEND RFC PATCH 1/3] pci: ide: Fix build failure Suzuki K Poulose
2025-03-11 14:46       ` [RESEND RFC PATCH 2/3] pci: generic-domains: Add helpers to alloc/free dynamic bus numbers Suzuki K Poulose
2025-03-11 14:46       ` [RESEND RFC PATCH 3/3] samples: devsec: Add support for PCI_DOMAINS_GENERIC Suzuki K Poulose
2025-04-20 18:29         ` Dan Williams
2025-04-22 15:45           ` Suzuki K Poulose
2025-05-13 10:18   ` [PATCH v2 06/11] samples/devsec: Introduce a PCI device-security bus + endpoint sample Zhi Wang
2025-03-04  7:14 ` [PATCH v2 07/11] PCI: Add PCIe Device 3 Extended Capability enumeration Dan Williams
2025-03-04  7:15 ` [PATCH v2 08/11] PCI/IDE: Add IDE establishment helpers Dan Williams
2025-03-04 20:44   ` kernel test robot
2025-03-05 12:32   ` kernel test robot
2025-03-11 10:51   ` Suzuki K Poulose
2025-04-19 17:50     ` Dan Williams
2025-03-18  3:18   ` Alexey Kardashevskiy
2025-04-25 21:42     ` Dan Williams
2025-04-21  6:13   ` Aneesh Kumar K.V
2025-04-25 16:29     ` Xu Yilun
2025-04-25 23:31     ` Dan Williams
2025-04-27  9:33       ` Aneesh Kumar K.V
2025-03-04  7:15 ` [PATCH v2 09/11] PCI/IDE: Report available IDE streams Dan Williams
2025-03-04 13:49   ` kernel test robot
2025-03-04 16:54   ` Dionna Amalie Glaze
2025-04-25 20:42     ` Dan Williams
2025-03-04  7:15 ` [PATCH v2 10/11] PCI/TSM: Report active " Dan Williams
2025-03-04  7:15 ` [PATCH v2 11/11] samples/devsec: Add sample IDE establishment Dan Williams
2025-05-07 10:47 ` Zhi Wang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250507134727.5384d33b@inno-thin-client \
    --to=zhiw@nvidia.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=aik@amd.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hao.wu@intel.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=john.allen@amd.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=sameo@rivosinc.com \
    --cc=sami.mujawar@arm.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=thomas.lendacky@amd.com \
    --cc=xiaoyao.li@intel.com \
    --cc=yilun.xu@intel.com \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).