From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>, linux-coco@lists.linux.dev
Cc: Lukas Wunner <lukas@wunner.de>, Samuel Ortiz <sameo@rivosinc.com>,
Alexey Kardashevskiy <aik@amd.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Xu Yilun <yilun.xu@linux.intel.com>,
gregkh@linuxfoundation.org, linux-pci@vger.kernel.org,
aik@amd.com, lukas@wunner.de
Subject: Re: [PATCH v2 05/11] PCI/TSM: Authenticate devices via platform TSM
Date: Wed, 16 Apr 2025 11:03:34 +0530 [thread overview]
Message-ID: <yq5asem84qmp.fsf@kernel.org> (raw)
In-Reply-To: <174107248456.1288555.10068789075179290465.stgit@dwillia2-xfh.jf.intel.com>
Dan Williams <dan.j.williams@intel.com> writes:
....
> diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h
> new file mode 100644
> index 000000000000..17657b7ef66c
> --- /dev/null
> +++ b/include/linux/pci-tsm.h
> @@ -0,0 +1,135 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __PCI_TSM_H
> +#define __PCI_TSM_H
> +#include <linux/mutex.h>
> +#include <linux/pci.h>
> +
> +struct pci_dev;
> +
> +enum pci_tsm_state {
> + PCI_TSM_ERR = -1,
> + PCI_TSM_INIT,
> + PCI_TSM_CONNECT,
> +};
> +
> +enum pci_tsm_type {
> + PCI_TSM_INVALID,
> + PCI_TSM_PF0,
> + PCI_TSM_VIRTFN,
> + PCI_TSM_MFD,
> +};
> +
> +/**
> + * struct pci_tsm - Core TSM context for a given PCIe endpoint
> + * @pdev: indicates the type of pci_tsm object
> + * @type: debug validation of the pci_tsm object type inferred by @pdev
> + *
> + * This structure is wrapped by a low level TSM driver and returned by
> + * tsm_ops.probe(), it is freed by tsm_ops.remove(). Depending on
> + * whether @pdev is physical function 0, another physical function, or a
> + * virtual function determines the pci_tsm object type. E.g. see 'struct
> + * pci_tsm_pf0'.
> + */
> +struct pci_tsm {
> + struct pci_dev *pdev;
> +#ifdef CONFIG_PCI_TSM_DEBUG
> + enum pci_tsm_type type;
> +#endif
> +};
> +
> +#ifdef CONFIG_PCI_TSM_DEBUG
> +static inline void pci_tsm_set_type(struct pci_tsm *pci_tsm, enum pci_tsm_type type)
> +{
> + pci_tsm->type = type;
> +}
> +static inline bool pci_tsm_check_type(struct pci_tsm *pci_tsm, enum pci_tsm_type type)
> +{
> + return pci_tsm->type == type;
> +}
> +#else
> +static inline void pci_tsm_set_type(struct pci_tsm *pci_tsm, enum pci_tsm_type type)
> +{
> +}
> +
> +static inline bool pci_tsm_check_type(struct pci_tsm *pci_tsm, enum pci_tsm_type type)
> +{
> + return true;
> +}
> +#endif
> +
> +/**
> + * struct pci_tsm_pf0 - Physical Function 0 TDISP context
> + * @state: reflect device initialized, connected, or bound
> + * @lock: protect @state vs pci_tsm_ops invocation
> + * @doe_mb: PCIe Data Object Exchange mailbox
> + */
> +struct pci_tsm_pf0 {
> + struct pci_tsm tsm;
> + enum pci_tsm_state state;
> + struct mutex lock;
> + struct pci_doe_mb *doe_mb;
> +};
>
While working with a multifunction device, I found that adding lock and
state to struct pci_tsm simplified the code considerably.
In multifunction setups, it’s possible that multiple functions may
expose DOE capabilities. In this case, when sending SPDM messages for a
TDI, should we always use the DOE mailbox of function 0, or should we
address the mailbox of the specific function involved?
If the latter is preferred, would it make sense to rename the current
structure—currently representing the base pci_tsm plus the DOE
mailbox—to something more generic? because it is not more tied to
physical function 0
> +
> +static inline bool is_pci_tsm_pf0(struct pci_dev *pdev)
> +{
> + if (!pci_is_pcie(pdev))
> + return false;
> +
> + if (pdev->is_virtfn)
> + return false;
> +
> + if (pci_pcie_type(pdev) != PCI_EXP_TYPE_ENDPOINT)
> + return false;
> +
> + return PCI_FUNC(pdev->devfn) == 0;
> +}
> +
> +/**
> + * struct pci_tsm_ops - Low-level TSM-exported interface to the PCI core
> + * @probe: probe/accept device for tsm operation, setup DSM context
> + * @remove: destroy DSM context
> + * @connect: establish / validate a secure connection (e.g. IDE) with the device
> + * @disconnect: teardown the secure connection
> + *
> + * @probe and @remove run in pci_tsm_rwsem held for write context. All
> + * other ops run under the @pdev->tsm->lock mutex and pci_tsm_rwsem held
> + * for read.
> + */
> +struct pci_tsm_ops {
> + struct pci_tsm *(*probe)(struct pci_dev *pdev);
> + void (*remove)(struct pci_tsm *tsm);
> + int (*connect)(struct pci_dev *pdev);
> + void (*disconnect)(struct pci_dev *pdev);
> +};
> +
> +enum pci_doe_proto {
> + PCI_DOE_PROTO_CMA = 1,
> + PCI_DOE_PROTO_SSESSION = 2,
> +};
> +
> +#ifdef CONFIG_PCI_TSM
> +int pci_tsm_core_register(const struct pci_tsm_ops *ops,
> + const struct attribute_group *grp);
> +void pci_tsm_core_unregister(const struct pci_tsm_ops *ops);
> +int pci_tsm_doe_transfer(struct pci_dev *pdev, enum pci_doe_proto type,
> + const void *req, size_t req_sz, void *resp,
> + size_t resp_sz);
> +int pci_tsm_pf0_initialize(struct pci_dev *pdev, struct pci_tsm_pf0 *tsm);
> +#else
> +static inline int pci_tsm_core_register(const struct pci_tsm_ops *ops,
> + const struct attribute_group *grp)
> +{
> + return 0;
> +}
> +static inline void pci_tsm_core_unregister(const struct pci_tsm_ops *ops)
> +{
> +}
> +static inline int pci_tsm_doe_transfer(struct pci_dev *pdev,
> + enum pci_doe_proto type, const void *req,
> + size_t req_sz, void *resp,
> + size_t resp_sz)
> +{
> + return -ENOENT;
> +}
> +#endif
> +#endif /*__PCI_TSM_H */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 628f9f5fdac9..57cfa0e3f2bd 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -537,6 +537,9 @@ struct pci_dev {
> u8 nr_link_ide; /* Link Stream count (Selective Stream offset) */
> unsigned int ide_cfg:1; /* Config cycles over IDE */
> unsigned int ide_tee_limit:1; /* Disallow T=0 traffic over IDE */
> +#endif
> +#ifdef CONFIG_PCI_TSM
> + struct pci_tsm *tsm; /* TSM operation state */
> #endif
> u16 acs_cap; /* ACS Capability offset */
> u8 supported_speeds; /* Supported Link Speeds Vector */
> diff --git a/include/linux/tsm.h b/include/linux/tsm.h
> index 9253b79b8582..59d3848404e1 100644
> --- a/include/linux/tsm.h
> +++ b/include/linux/tsm.h
> @@ -111,7 +111,9 @@ struct tsm_report_ops {
> int tsm_report_register(const struct tsm_report_ops *ops, void *priv);
> int tsm_report_unregister(const struct tsm_report_ops *ops);
> struct tsm_core_dev;
> +struct pci_tsm_ops;
> struct tsm_core_dev *tsm_register(struct device *parent,
> - const struct attribute_group **groups);
> + const struct attribute_group **groups,
> + const struct pci_tsm_ops *ops);
> void tsm_unregister(struct tsm_core_dev *tsm_core);
> #endif /* __TSM_H */
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 000258cd93c8..713588a29813 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -499,6 +499,7 @@
> #define PCI_EXP_DEVCAP_PWR_VAL 0x03fc0000 /* Slot Power Limit Value */
> #define PCI_EXP_DEVCAP_PWR_SCL 0x0c000000 /* Slot Power Limit Scale */
> #define PCI_EXP_DEVCAP_FLR 0x10000000 /* Function Level Reset */
> +#define PCI_EXP_DEVCAP_TEE 0x40000000 /* TEE I/O (TDISP) Support */
> #define PCI_EXP_DEVCTL 0x08 /* Device Control */
> #define PCI_EXP_DEVCTL_CERE 0x0001 /* Correctable Error Reporting En. */
> #define PCI_EXP_DEVCTL_NFERE 0x0002 /* Non-Fatal Error Reporting Enable */
next prev parent reply other threads:[~2025-04-16 5:34 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 [this message]
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 ` [PATCH v2 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP) Zhi Wang
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=yq5asem84qmp.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=aik@amd.com \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sameo@rivosinc.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).