Re: [PATCH kernel 1/6] PCI/TSM: Add secure SPDM DOE mailbox
From: Alexey Kardashevskiy
Date: Sun Nov 16 2025 - 20:50:00 EST
On 14/11/25 12:51, dan.j.williams@xxxxxxxxx wrote:
Alexey Kardashevskiy wrote:
The IDE key programming happens via Secure SPDM channel, initialise it
at the PF0 probing.
Add the SPDM certificate slot (up to 8 are allowed by SPDM), the platform
is expected to select one.
While at this, add a common struct for SPDM request/response as these
are going to needed by every platform.
Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxx>
---
(!tsm->doe_mb_sec) is definitely an error on AMD SEV-TIO, is not it on other platforms?
I think you just happen to have a multi-DOE test device, or a device
that has a PCI_DOE_FEATURE_SSESSION DOE and not a PCI_DOE_FEATURE_CMA
DOE.
---
include/linux/pci-tsm.h | 14 ++++++++++++++
drivers/pci/tsm.c | 4 ++++
2 files changed, 18 insertions(+)
diff --git a/include/linux/pci-tsm.h b/include/linux/pci-tsm.h
index 40c5e4c31a3f..b6866f7c14b4 100644
--- a/include/linux/pci-tsm.h
+++ b/include/linux/pci-tsm.h
@@ -10,6 +10,14 @@ struct tsm_dev;
struct kvm;
enum pci_tsm_req_scope;
+/* SPDM control structure for DOE */
+struct tsm_spdm {
+ unsigned long req_len;
+ void *req;
+ unsigned long rsp_len;
+ void *rsp;
+};
I would only add things to the core that the core needs, or all
implementations can unify. You can see that tdx_spdm_msg_exchange() can
not use this common definition for example.
Oh I missed that we have tdx_spdm_msg_exchange() now, cool :)
+
/*
* struct pci_tsm_ops - manage confidential links and security state
* @link_ops: Coordinate PCIe SPDM and IDE establishment via a platform TSM.
@@ -130,11 +138,17 @@ struct pci_tsm {
* @base_tsm: generic core "tsm" context
* @lock: mutual exclustion for pci_tsm_ops invocation
* @doe_mb: PCIe Data Object Exchange mailbox
+ * @doe_mb_sec: DOE mailbox used when secured SPDM is requested
+ * @spdm: cached SPDM request/response buffers for the link
+ * @cert_slot: SPDM certificate slot
*/
struct pci_tsm_pf0 {
struct pci_tsm base_tsm;
struct mutex lock;
struct pci_doe_mb *doe_mb;
+ struct pci_doe_mb *doe_mb_sec;
See below, pci_tsm_pf0 should only ever need one doe_mb instance.
+ struct tsm_spdm spdm;
Per above, just move @tsm_spdm into the TIO object that wraps
pci_tsm_pf0.
Sure, can do that.
+ u8 cert_slot;
};
struct pci_tsm_mmio {
diff --git a/drivers/pci/tsm.c b/drivers/pci/tsm.c
index ed8a280a2cf4..378748b15825 100644
--- a/drivers/pci/tsm.c
+++ b/drivers/pci/tsm.c
@@ -1067,6 +1067,10 @@ int pci_tsm_pf0_constructor(struct pci_dev *pdev, struct pci_tsm_pf0 *tsm,
pci_warn(pdev, "TSM init failure, no CMA mailbox\n");
return -ENODEV;
}
+ tsm->doe_mb_sec = pci_find_doe_mailbox(pdev, PCI_VENDOR_ID_PCI_SIG,
+ PCI_DOE_FEATURE_SSESSION);
+ if (!tsm->doe_mb_sec)
+ pci_warn(pdev, "TSM init failed to init SSESSION mailbox\n");
So it is surprising to find that a device supports PCI_DOE_FEATURE_CMA,
but requires the TSM to also use the PCI_DOE_FEATURE_SSESSION mailbox?
A PCI_DOE_FEATURE_CMA mailbox is capable of supporting secure sessions
and IDE.
What does guarantee that CMA supports SSESSION?
When a device supports multiple DOE, the VMM does need to pick one, but the
hope was that "first CMA DOE" would work, but apparently you have a
device that wants to violate this simple heuristic?
What happens on this device if you use the CMA mailbox for IDE
establishment and secure sessions?
Nah, my devices have one DOE cap with 3 protocols supported, I just did not see any good reason to limit ourselves to one DOE MB. We will either have to BUG_ON on DOE MB which does CMA but does not do SSESSION, or just have 2 struct doe_mb pointers. Thanks,
--
Alexey