<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#467886" vlink="#96607D" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">(CC'ing the SPDM chain maintainers directly for visibility; posting to the list so the discussion stays searchable alongside the April 2 thread.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I'd like input from the SPDM chain maintainers on how you'd prefer to receive these patches before I start pushing to Gerrit.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This is the commit I'm least sure about architecturally.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">## Questions for the chain maintainers<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Before I start pushing, could you let me know:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> 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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Gary<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">[1] <a href="https://lists.ozlabs.org/pipermail/openbmc/2026-April/038553.html">
https://lists.ozlabs.org/pipermail/openbmc/2026-April/038553.html</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">[2] <a href="https://lists.ozlabs.org/pipermail/openbmc/2026-April/038554.html">
https://lists.ozlabs.org/pipermail/openbmc/2026-April/038554.html</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none"> Gary Beihl <garybeihl@microsoft.com>
<br>
<b>Sent:</b> Tuesday, April 7, 2026 4:51 PM<br>
<b>To:</b> Matt Johnston <matt@codeconstruct.com.au>; openbmc@lists.ozlabs.org<br>
<b>Cc:</b> Thirupathaiah Annapureddy <thiruan@microsoft.com>; Sagar Dharia <Sagar.Dharia@microsoft.com>; Giri Mudusuru <girimudusuru@microsoft.com><br>
<b>Subject:</b> RE: [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Matt,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">All 14 SPDM E2E Robot Framework tests continue to pass with this change, including the multi-endpoint scenarios that previously hit EADDRINUSE.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Gary<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-ligatures:none"> Matt Johnston <<a href="mailto:matt@codeconstruct.com.au">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">garybeihl@microsoft.com</a>>;
<a href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a><br>
<b>Cc:</b> Thirupathaiah Annapureddy <<a href="mailto:thiruan@microsoft.com">thiruan@microsoft.com</a>>; Sagar Dharia <<a href="mailto:Sagar.Dharia@microsoft.com">Sagar.Dharia@microsoft.com</a>>; Giri Mudusuru <<a href="mailto:girimudusuru@microsoft.com">girimudusuru@microsoft.com</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [RFC] SPDM attestation E2E findings from Renode testing<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%">
<tbody>
<tr>
<td width="0" style="width:.3pt;background:#A6A6A6;padding:5.25pt 1.5pt 5.25pt 1.5pt">
</td>
<td width="100%" style="width:100.0%;background:#EAEAEA;padding:5.25pt 3.75pt 5.25pt 11.25pt;aspect-ratio: revert !important;background:revert !important;block-size: revert !important;border:revert !important;bottom: revert !important;color:revert !important;color-scheme: revert !important;content-visibility: revert !important;cursor:revert !important;direction:revert !important;display:revert !important;font-size:revert !important;height:revert !important;hyphens: revert !important;letter-spacing:revert !important;line-height:revert !important;margin:revert !important;opacity: revert !important;order: revert !important;outline: revert !important;overflow:revert !important;padding:revert !important;position:revert !important;resize: revert !important;rotate: revert !important;scale: revert !important;tab-size: revert !important;table-layout:revert !important;text-align:revert !important;text-indent:revert !important;text-orientation: revert !important;text-overflow: revert !important;text-shadow:revert !important;text-transform:revert !important;text-wrap: revert !important;top:revert !important;transition: revert !important;user-select: revert !important;vertical-align:revert !important;visibility:revert !important;white-space:revert !important;width:revert !important;word-break:revert !important;word-spacing:revert !important;writing-mode:revert !important;zoom: revert !important">
<div>
<p class="MsoNormal" style="mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly">
<span style="font-size:9.0pt;font-family:"Segoe UI",sans-serif;color:#212121;mso-ligatures:none">You don't often get email from
<a href="mailto:matt@codeconstruct.com.au">matt@codeconstruct.com.au</a>. <a href="https://aka.ms/LearnAboutSenderIdentification">
Learn why this is important</a> <o:p></o:p></span></p>
</div>
</td>
<td width="75" style="width:56.25pt;background:#EAEAEA;padding:5.25pt 3.75pt 5.25pt 3.75pt;aspect-ratio: revert !important;background:revert !important;block-size: revert !important;border:revert !important;bottom: revert !important;color:revert !important;color-scheme: revert !important;content-visibility: revert !important;cursor:revert !important;direction:revert !important;display:revert !important;font-size:revert !important;height:revert !important;hyphens: revert !important;letter-spacing:revert !important;line-height:revert !important;margin:revert !important;opacity: revert !important;order: revert !important;outline: revert !important;overflow:revert !important;padding:revert !important;position:revert !important;resize: revert !important;rotate: revert !important;scale: revert !important;tab-size: revert !important;table-layout:revert !important;text-align:revert !important;text-indent:revert !important;text-orientation: revert !important;text-overflow: revert !important;text-shadow:revert !important;text-transform:revert !important;text-wrap: revert !important;top:revert !important;transition: revert !important;user-select: revert !important;vertical-align:revert !important;visibility:revert !important;white-space:revert !important;width:revert !important;word-break:revert !important;word-spacing:revert !important;writing-mode:revert !important;zoom: revert !important;align: left !important">
</td>
</tr>
</tbody>
</table>
<div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">Hi Gary,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">On Wed, 2026-04-01 at 21:35 +0000, Gary Beihl wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #729FCF 1.5pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt">(c) Shared AF_MCTP socket (affects 80311: mctp_helper.hpp)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">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().<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">Is the SPDM implementation using asynchronous messages sent by the responder? (KEY_UPDATE, HEARTBEAT, END_SESSION)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">If not, I think the bind() could be removed altogether.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">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].<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">[1] <a href="https://lore.kernel.org/all/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au/">https://lore.kernel.org/all/20250710-mctp-bind-v4-6-8ec2f6460c56@codeconstruct.com.au/</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">[2] <a href="https://gerrit.openbmc.org/c/openbmc/pldm/+/83626">https://gerrit.openbmc.org/c/openbmc/pldm/+/83626</a> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">Cheers,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none">Matt<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>