Skip to content

Add SLOT_MANAGEMENT command to spdm-emu#496

Open
jyao1 wants to merge 1 commit into
DMTF:mainfrom
jyao1:slot_management
Open

Add SLOT_MANAGEMENT command to spdm-emu#496
jyao1 wants to merge 1 commit into
DMTF:mainfrom
jyao1:slot_management

Conversation

@jyao1

@jyao1 jyao1 commented Jun 4, 2026

Copy link
Copy Markdown
Member

@jyao1 jyao1 requested a review from steven-bellock as a code owner June 4, 2026 13:13
@jyao1 jyao1 marked this pull request as draft June 4, 2026 13:13
@jyao1 jyao1 force-pushed the slot_management branch from feb4833 to c485286 Compare June 4, 2026 16:34
@jyao1 jyao1 marked this pull request as ready for review June 5, 2026 01:38
@jyao1 jyao1 force-pushed the slot_management branch from b12a651 to 38b8c3f Compare June 6, 2026 06:03
Wire the SPDM 1.4 SLOT_MANAGEMENT command into the requester and
responder emulators, mirroring the existing key_pair_info layering:

- spdm_emu_common: EXE_CONNECTION_SLOT_MGMT / EXE_SESSION_SLOT_MGMT flags,
  string-table entries, default enablement, and usage/help text.
- responder: advertise its extended capability flags via
  LIBSPDM_DATA_CAPABILITY_EXT_FLAGS (m_use_responder_capability_ext_flags,
  which defaults to SLOT_MGMT_CAP when built with SLOT_MGMT_CAP).
- requester: do_slot_management_via_spdm exercises the full set of
  SubCodes the Responder advertises (SupportedSubCodes, GetBankInfo,
  GetBankDetails, GetCertificateChain, GetCSR, ManageBank, SetCertificate,
  and ManageSlot), invoked from both the connection and session flows,
  gated on SPDM 1.4. SetCertificate is issued only for Bank 0, since the
  Responder rejects writing a non-zero Bank outside a trusted environment;
  ManageSlot Erase is issued last, on the last enumerated Bank, because it
  changes the SlotMask reported for subsequent SubCodes. The Requester only
  sends SLOT_MANAGEMENT when the Responder negotiated SLOT_MGMT_CAP.

Add command-line control of the extended capability flags
(GET_CAPABILITIES ExtendedFlags), mirroring --cap / --peer_cap:

- --ext_cap NO|SLOT_MGMT selects the extended flags this endpoint
  advertises; --peer_ext_cap selects the peer's (used with --exe_conn
  VER_ONLY, like --peer_cap). By default the Requester advertises NO and
  the Responder advertises SLOT_MGMT, via the new
  m_use_requester_capability_ext_flags / m_use_responder_capability_ext_flags
  globals.
- Because the empty selection "NO" is the encoded value 0 yet must still
  override a non-zero default, a *_set flag records whether the option was
  given (a non-zero test, as --cap uses, cannot express "clear to NO").

The extended capability flags are a generic SPDM 1.4 field (SLOT_MGMT is
only one bit, more may follow), so the ExtendedFlags plumbing - advertising
it, reading the negotiated value, and persisting it in save_state /
load_state - is unconditional; only the SLOT_MGMT bit default and the
SLOT_MANAGEMENT command itself are gated on SLOT_MGMT_CAP. The negotiated
state struct gains requester_cap_ext_flags / responder_cap_ext_flags
(struct version bumped to 2).

Document --ext_cap / --peer_ext_cap and the SLOT_MGMT exe options in
doc/spdm_emu.md.

Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
@jyao1 jyao1 force-pushed the slot_management branch from 38b8c3f to f6fba3d Compare June 11, 2026 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant