<div dir="ltr"><p>Hi Gary,</p><p>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.</p>
<p>As part of SPDM 1.1, the Challenge was optional - however, you can still proceed with the change for Challenge handling if needed.</p>
<p>We should coordinate closely to ensure all commits are applied in a proper sequence.</p><div>Thanks</div><div>Ratan</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2026 at 9:40 PM Gary Beihl <<a href="mailto:garybeihl@microsoft.com">garybeihl@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg8586052932577486402">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_8586052932577486402WordSection1">
<p class="MsoNormal"><span style="font-size:11pt">(CC'ing the SPDM chain maintainers directly for visibility; posting to the list so the discussion stays searchable alongside the April 2 thread.)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">I'd like input from the SPDM chain maintainers on how you'd prefer to receive these patches before I start pushing to Gerrit.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">This is the commit I'm least sure about architecturally.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">## Questions for the chain maintainers<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Before I start pushing, could you let me know:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">  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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">  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?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">  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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Gary<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">[1] <a href="https://lists.ozlabs.org/pipermail/openbmc/2026-April/038553.html" target="_blank">
https://lists.ozlabs.org/pipermail/openbmc/2026-April/038553.html</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">[2] <a href="https://lists.ozlabs.org/pipermail/openbmc/2026-April/038554.html" target="_blank">
https://lists.ozlabs.org/pipermail/openbmc/2026-April/038554.html</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Gary Beihl <<a href="mailto:garybeihl@microsoft.com" target="_blank">garybeihl@microsoft.com</a>>
<br>
<b>Sent:</b> Tuesday, April 7, 2026 4:51 PM<br>
<b>To:</b> Matt Johnston <<a href="mailto:matt@codeconstruct.com.au" target="_blank">matt@codeconstruct.com.au</a>>; <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br>
<b>Cc:</b> Thirupathaiah Annapureddy <<a href="mailto:thiruan@microsoft.com" target="_blank">thiruan@microsoft.com</a>>; Sagar Dharia <<a href="mailto:Sagar.Dharia@microsoft.com" target="_blank">Sagar.Dharia@microsoft.com</a>>; Giri Mudusuru <<a href="mailto:girimudusuru@microsoft.com" target="_blank">girimudusuru@microsoft.com</a>><br>
<b>Subject:</b> RE: [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">Hi Matt,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">All 14 SPDM E2E Robot Framework tests continue to pass with this change, including the multi-endpoint scenarios that previously hit EADDRINUSE.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Gary<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"> Matt Johnston <<a href="mailto:matt@codeconstruct.com.au" target="_blank">matt@codeconstruct.com.au</a>>
<br>
<b>Sent:</b> Wednesday, April 1, 2026 10:09 PM<br>
<b>To:</b> Gary Beihl <<a href="mailto:garybeihl@microsoft.com" target="_blank">garybeihl@microsoft.com</a>>;
<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a><br>
<b>Cc:</b> Thirupathaiah Annapureddy <<a href="mailto:thiruan@microsoft.com" target="_blank">thiruan@microsoft.com</a>>; Sagar Dharia <<a href="mailto:Sagar.Dharia@microsoft.com" target="_blank">Sagar.Dharia@microsoft.com</a>>; Giri Mudusuru <<a href="mailto:girimudusuru@microsoft.com" target="_blank">girimudusuru@microsoft.com</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<table border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100%">
<tbody>
<tr>
<td width="0" style="width:0.3pt;background:rgb(166,166,166);padding:5.25pt 1.5pt">
</td>
<td width="100%" style="background:revert;border:revert;color:revert;direction:revert;display:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;padding:revert;table-layout:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;width:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert">
<div>
<p class="MsoNormal">
<span style="font-size:9pt;font-family:"Segoe UI",sans-serif;color:rgb(33,33,33)">You don't often get email from
<a href="mailto:matt@codeconstruct.com.au" target="_blank">matt@codeconstruct.com.au</a>. <a href="https://aka.ms/LearnAboutSenderIdentification" target="_blank">
Learn why this is important</a> <u></u><u></u></span></p>
</div>
</td>
<td width="75" style="background:revert;border:revert;color:revert;direction:revert;display:revert;font-size:revert;height:revert;letter-spacing:revert;line-height:revert;margin:revert;opacity:revert;outline:revert;overflow:revert;padding:revert;table-layout:revert;text-align:revert;text-indent:revert;text-orientation:revert;text-overflow:revert;text-transform:revert;vertical-align:revert;white-space:revert;width:revert;word-break:revert;word-spacing:revert;writing-mode:revert;zoom:revert">
</td>
</tr>
</tbody>
</table>
<div>
<div>
<p class="MsoNormal"><span>Hi Gary,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>On Wed, 2026-04-01 at 21:35 +0000, Gary Beihl wrote:<u></u><u></u></span></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid rgb(114,159,207);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal"><span style="font-size:11pt">(c) Shared AF_MCTP socket (affects 80311: mctp_helper.hpp)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt">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).</span><u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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().<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Is the SPDM implementation using asynchronous messages sent by the responder? (KEY_UPDATE, HEARTBEAT, END_SESSION)<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>If not, I think the bind() could be removed altogether.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>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].<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>[1] <a href="https://lore.kernel.org/all/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au/" target="_blank">https://lore.kernel.org/all/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au/</a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>[2] <a href="https://gerrit.openbmc.org/c/openbmc/pldm/+/83626" target="_blank">https://gerrit.openbmc.org/c/openbmc/pldm/+/83626</a> <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Cheers,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span>Matt<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>

</div></blockquote></div>