[RFC] SPDM attestation E2E findings from Renode testing

Wed Apr 15 16:47:49 AEST 2026

Hi Gary,

Thank you for your interest in contributing to the SPDM repository.

Regarding the implementation of connectSPDMDevice(), I would prefer aligning it with the current MCTP commits (80358, 80355, 80311)
and the TCP-related changes introduced in 85916.
I am also fine if you'd like to take ownership of these changes. We can coordinate further on how best to proceed with the commits.

Thanks,
Archana

Get Outlook for Mac<https://aka.ms/GetOutlookForMac>
From: Ratan Gupta <ratankgupta31 at gmail.com>
Date: Tuesday, 14 April 2026 at 4:56 PM
To: Gary Beihl <garybeihl at microsoft.com>
Cc: openbmc at lists.ozlabs.org <openbmc at lists.ozlabs.org>, Thirupathaiah Annapureddy <thiruan at microsoft.com>, Sagar Dharia <Sagar.Dharia at microsoft.com>, Giri Mudusuru <girimudusuru at microsoft.com>, Matt Johnston <matt at codeconstruct.com.au>, Chinmay Shripad Hegde <hosmanechinmay at gmail.com>, Archana Kakani <Archana.Kakani at ibm.com>, Manjeet Singh <itsmanjeet1998 at gmail.com>
Subject: [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing

This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.
Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-XFVHHmZWiRUXb_5568ucU7v1C1Ij5IpUpWbx537iczHHWUHLQQ0ll81z7ZsMjYi1twhsPInc6qcD-g5cWL0aybPnYnBOlxCtYOEtGLPQfxiip2Hqi09uSBFWFzK$>

Hi Gary,

Thanks for highlighting the issues. Since most of the Gerrit commits are still not merged, you can continue leaving comments on those. However, for issue 2, you may go ahead and push the fix as that code has already been merged.

As part of SPDM 1.1, the Challenge was optional - however, you can still proceed with the change for Challenge handling if needed.

We should coordinate closely to ensure all commits are applied in a proper sequence.

Thanks
Ratan

On Mon, Apr 13, 2026 at 9:40 PM Gary Beihl <garybeihl at microsoft.com<mailto:garybeihl at microsoft.com>> wrote:
(CC'ing the SPDM chain maintainers directly for visibility; posting to the list so the discussion stays searchable alongside the April 2 thread.)

Following up on the April 2 RFC [1] and Matt's reply [2]: I now have a group of six patches on a local branch that take the SPDM E2E suite
from 0/13 to 17/17 passing on Renode evb-ast2600 (14 attestation scenarios + 1 boot + 2 new SPDMGetSignedMeasurements scenarios I added to cover the on-demand D-Bus path).

I'd like input from the SPDM chain maintainers on how you'd prefer to receive these patches before I start pushing to Gerrit.

Here are the 6 patches: All are small and independent. Each has a one-paragraph rationale in the commit message plus a "Tested:" trailer describing what the Renode E2E suite exercises.

1. spdmd: Handle missing MCTP endpoints gracefully - mctp_transport_discovery.cpp. Catches ResourceNotFound and per-endpoint query exceptions so spdmd doesn't terminate on a freshly booted system with no MCTP endpoints yet configured. Same pattern as Archana's fix in 88794 for the TCP discovery path.

2. spdmd: Search the full object tree in mapper lookups - utils/mapper.cpp. Changes get_sub_tree("/xyz/openbmc_project", ...) to get_sub_tree("/", ...) so the search finds mctpd-managed endpoints under /au/com/codeconstruct/mctp1/... — mctpd implements both xyz.openbmc_project.MCTP.Endpoint and au.com.codeconstruct.MCTP.Endpoint1 on the same object, but the xyz-rooted search never finds it.

3. spdmd: Remove unnecessary MCTP socket bind() - mctp_helper.hpp. This is the fix Matt recommended in [2]. Removes the wildcard bind(ANY, ANY, SPDM, OWNER) that prevented multi-device discovery from working — multiple MctpIoClass instances would collide on the same bound tuple. spdmd is a pure synchronous requester so no bind() is needed. Same pattern as the pldmtool fix Matt referenced (openbmc/pldm 83626).

4. spdmd: Set MCTP socket receive timeout in mctp_helper.hpp. Adds SO_RCVTIMEO=10s at socket creation. The existing MctpIoClass::read() marks its timeout parameter as [[maybe_unused]] and recvfrom() blocks forever on unreachable devices, so libspdm never returns LIBSPDM_STATUS_RECEIVE_FAIL and systemd's start-timeout kills spdmd before it becomes active.

5. spdmd: Implement eager SPDM attestation on discovery spdm_dbus_responder.cpp/hpp, spdmd.cpp. Adds a performEagerAttestation() method that runs VCA + GET_DIGESTS + GET_CERTIFICATE + CHALLENGE on every discovered device and updates the ComponentIntegrity.ResponderVerificationStatus D-Bus property. Called from main() after ctx.request_name() so attestation timing can't trigger systemd's TimeoutStartSec.

CHALLENGE is the critical step for the security gap I mentioned in the original RFC — without it, a wrong or compromised private key still passes attestation because GET_CERTIFICATE alone does not prove key ownership.

This is the commit I'm least sure about architecturally.

Archana: I see 88873 adds an SPDMResponderManager with a connectSPDMDevice() stub. Would you rather I rebase the attestation logic into your manager class instead of adding it as a method on SPDMDBusResponder? Happy to do either.

6. spdmd: Surface SPDMGetSignedMeasurements errors component_integrity_dbus.cpp. The catch block in method_call() currently swallows all std::exception subtypes and returns a tuple of empty strings as if the call had succeeded, so bmcweb returns HTTP 200 with "SignedMeasurements":"" on any libspdm failure. Fix is to split the catch: sdbusplus::exception::exception subtypes are rethrown (preserving InvalidArgument), generic std::exception is converted to InternalFailure. Bmcweb then maps the D-Bus error to HTTP 500 with a Redfish @Message.ExtendedInfo body.

TCP discovery exception handling — I had also fixed the TCP ResourceNotFound crash, but then noticed Archana's 88794 already does this. So that one's dropped from my stack.

## Questions for the chain maintainers

The chain I'm targeting is NVIDIA's (80262, 80355, 80264, 80272, 80311, 80358, 84019, ...) since my fixes touch files that only exist there. I understand the IBM chain (88112, 88124, 88873, 88794, 89179) is a parallel track — fixes 1-4 and 6 are on files IBM's chain doesn't touch, and fix 5 will need to be reconciled once the two chains merge.

Before I start pushing, could you let me know:

  a) Are you okay with fixes 1, 2, 3, 4, and 6 landing as a five-commit stack on Gerrit depending on the NVIDIA chain (specifically 80262 PS19, 80355, and 84019)? I'd submit them under my Microsoft email and reference the April 2 RFC in each commit message.

  b) For fix 5 (eager attestation): does it make more sense to (i) post it as a stand-alone Gerrit change stacked on 84019 now, and reconcile with 88873's SPDMResponderManager later, (ii) post it as an amendment to 88873 that fills in the connectSPDMDevice() TODO, or (iii) hold until the NVIDIA and IBM chains converge upstream?

  c) Is there a planned coordination point where the two chains merge? I see 88873 intends to drive NVIDIA's SpdmTransport eventually. Happy to help bridge them if that's a blocker for landing the attestation flow.

If any of the six descriptions look off to you, please push back before I push them to Gerrit — I'd rather have the discussion in email than after N patchsets back-and-forth.

Full commit messages and diffs are on a local branch; I can either (a) upload to Gerrit as a draft and share links, (b) post patches inline to the list as a v1 series, or (c) share them privately if you'd prefer. Let me know which you'd like.

Thanks,
Gary

[1] https://lists.ozlabs.org/pipermail/openbmc/2026-April/038553.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2026-2DApril_038553.html&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=5LG9QqsUa9F7APmEKeatoKA-iVg28ER0WwiLE78xo1U&m=WZOGGnJwGhKyNk7oVY3v2O6Cv6bgiYQJEf-qi6XP3LqxBXr9eQRaC2XQ4lYyWAhc&s=vCpgEQxDKyOF79dWwjAptft60ClPukw2rBvxSyAEzm8&e=>
[2] https://lists.ozlabs.org/pipermail/openbmc/2026-April/038554.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_pipermail_openbmc_2026-2DApril_038554.html&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=5LG9QqsUa9F7APmEKeatoKA-iVg28ER0WwiLE78xo1U&m=WZOGGnJwGhKyNk7oVY3v2O6Cv6bgiYQJEf-qi6XP3LqxBXr9eQRaC2XQ4lYyWAhc&s=jpKHTi1YYBLd6BhAnA5_sw-fL3BzeWkkCGL5vQpvGns&e=>

From: Gary Beihl <garybeihl at microsoft.com<mailto:garybeihl at microsoft.com>>
Sent: Tuesday, April 7, 2026 4:51 PM
To: Matt Johnston <matt at codeconstruct.com.au<mailto:matt at codeconstruct.com.au>>; openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>
Cc: Thirupathaiah Annapureddy <thiruan at microsoft.com<mailto:thiruan at microsoft.com>>; Sagar Dharia <Sagar.Dharia at microsoft.com<mailto:Sagar.Dharia at microsoft.com>>; Giri Mudusuru <girimudusuru at microsoft.com<mailto:girimudusuru at microsoft.com>>
Subject: RE: [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing

Hi Matt,

Thank you for the recommendation – I followed your suggestion and dropped the call to bind() altogether. Since spdmd only does request/response (no async SPDM messages), regular sendto()/recvfrom() with SO_RCVTIMEO) works just fine. Each endpoint gets its own socket with no EADDRINUSE conflict.

All 14 SPDM E2E Robot Framework tests continue to pass with this change, including the multi-endpoint scenarios that previously hit EADDRINUSE.

Per-endpoint bind() from Linux 6.17 is good to know about for future work in case we need to handle async SPDM notifications (e.g, KEY_UPDATE).

Thanks,
Gary

From: Matt Johnston <matt at codeconstruct.com.au<mailto:matt at codeconstruct.com.au>>
Sent: Wednesday, April 1, 2026 10:09 PM
To: Gary Beihl <garybeihl at microsoft.com<mailto:garybeihl at microsoft.com>>; openbmc at lists.ozlabs.org<mailto:openbmc at lists.ozlabs.org>
Cc: Thirupathaiah Annapureddy <thiruan at microsoft.com<mailto:thiruan at microsoft.com>>; Sagar Dharia <Sagar.Dharia at microsoft.com<mailto:Sagar.Dharia at microsoft.com>>; Giri Mudusuru <girimudusuru at microsoft.com<mailto:girimudusuru at microsoft.com>>
Subject: [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing

You don't often get email from matt at codeconstruct.com.au<mailto:matt at codeconstruct.com.au>. Learn why this is important<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=5LG9QqsUa9F7APmEKeatoKA-iVg28ER0WwiLE78xo1U&m=WZOGGnJwGhKyNk7oVY3v2O6Cv6bgiYQJEf-qi6XP3LqxBXr9eQRaC2XQ4lYyWAhc&s=LsM4P7Y8FjFkp4RD3gxE0XTMYW-29QfgHNOpNEWKKSo&e=>
Hi Gary,

On Wed, 2026-04-01 at 21:35 +0000, Gary Beihl wrote:
(c) Shared AF_MCTP socket (affects 80311: mctp_helper.hpp)

Only one socket can bind to (MCTP_ADDR_ANY, MCTP_TYPE_SPDM).  When spdmd attests multiple endpoints sequentially, the second   MctpIoClass::createSocket() fails with EADDRINUSE. The fix is a process-lifetime shared socket (singleton pattern), draining stale responses between endpoint attestations with recv(MSG_DONTWAIT).

Since Linux 6.17 it is possible to restrict a bind() to only receive from a single remote endpoint [1]. Call connect() with the remote address before the bind().

Is the SPDM implementation using asynchronous messages sent by the responder? (KEY_UPDATE, HEARTBEAT, END_SESSION)
If not, I think the bind() could be removed altogether.
bind() isn't needed in the case where the Linux host is performing a plain send() then receiving a response. A similar situation was fixed in pldmtool [2].

[1] https://lore.kernel.org/all/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au/<https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_all_20250710-2Dmctp-2Dbind-2Dv4-2D6-2D8ec2f6460c56-40codeconstruct.com.au_&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=5LG9QqsUa9F7APmEKeatoKA-iVg28ER0WwiLE78xo1U&m=WZOGGnJwGhKyNk7oVY3v2O6Cv6bgiYQJEf-qi6XP3LqxBXr9eQRaC2XQ4lYyWAhc&s=yvueK1Sn02hvuUhycvYUIAjdAbIDoQa-c_DRXUkZPes&e=>
[2] https://gerrit.openbmc.org/c/openbmc/pldm/+/83626<https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc.org_c_openbmc_pldm_-2B_83626&d=DwMFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=5LG9QqsUa9F7APmEKeatoKA-iVg28ER0WwiLE78xo1U&m=WZOGGnJwGhKyNk7oVY3v2O6Cv6bgiYQJEf-qi6XP3LqxBXr9eQRaC2XQ4lYyWAhc&s=iQjwwvYyaSgr9b64ry_bP59N-FiQ_U5wReF487Qrz2I&e=>

Cheers,
Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20260415/f0157f0f/attachment.htm>