[EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing

[Gary Beihl]

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>
Sent: Wednesday, April 1, 2026 10:09 PM
To: Gary Beihl <garybeihl at microsoft.com>; openbmc at lists.ozlabs.org
Cc: Thirupathaiah Annapureddy <thiruan at microsoft.com>; Sagar Dharia <Sagar.Dharia at microsoft.com>; Giri Mudusuru <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://aka.ms/LearnAboutSenderIdentification>
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/
[2] https://gerrit.openbmc.org/c/openbmc/pldm/+/83626

Cheers,
Matt

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