feat: add CustomSecureBootKeysAllower for out-of-band custom key acceptance by mcanevet · Pull Request #466 · bmc-toolbox/bmclib

mcanevet · 2026-09-10T13:42:04Z

Summary

Adds bmc.CustomSecureBootKeysAllower, a new interface controlling whether a platform will accept custom UEFI Secure Boot keys (as opposed to only the vendor-shipped key set). This is distinct from SecureBootSetter (enabling/disabling Secure Boot itself) and from SecureBootCertificateImporter (enrolling a specific certificate) - it's the out-of-band gate some vendors require before a certificate import will be accepted at all.

Implemented for Dell, which models this as the SecureBootPolicy BIOS attribute (Standard/Custom). Not implemented for Lenovo yet: XCC-based systems have an analogous SecureBootPolicy attribute, but it's unconfirmed whether it's reachable through the same generic /Bios attribute PATCH this package already uses, or requires Lenovo's proprietary OneCLI/XCC transport - documented as a known gap with links to Lenovo's public docs (including the FQXSFPU4097G error code callers will hit without it).

rebootRequired reports that a successful change is staged and takes effect only after a power cycle, matching how BIOS Setup attribute changes work generally.

Also fixes a bug in AllowCustomSecureBootKeys itself: it returned early when the attribute's currently applied value already matched the request, which is unsafe if a different value is genuinely pending from an earlier call in the same boot cycle - confirmed live, that left a stale pending value in place, silently reverting an explicit request on the next reboot (observed as a certificate import rejected because SecureBootPolicy committed as Standard despite requesting Custom moments earlier). The write is now unconditional; the attribute is still read first, but only to reject platforms that don't expose it at all. Relies on stmcginnis/gofish#571 (via #468, merged) to correctly detect a stale-but-different pending value.

Test plan

bmc/secure_boot_test.go: TestAllowCustomSecureBootKeysFromInterfaces covering success/no-implementation/error cases.
providers/dell/secure_boot_test.go: enable-from-Standard, already-Custom-but-stale-pending, disable-from-Custom, already-Standard-but-stale-pending, and the attribute-absent (ErrUnsupportedHardware) case.
go build ./..., go vet ./..., golangci-lint run ./... (0 new issues), go test ./... all pass.

bmclib gained a Dell-only SecureBootKeyManagementSetter capability for enabling/disabling out-of-band acceptance of custom UEFI Secure Boot keys. Rufio had no Secure Boot support of any kind yet, so this adds the first action for it: SecureBootKeyManagement{Enable bool} on the shared bmc.Action type (v1alpha1 only - v1alpha2 isn't wired to any controller yet), reusable from both bmc.Task/Job and Workflow's preparingActions/postActions since they embed the same Action type. runTask calls bmcClient.SetSecureBootKeyManagement directly; no status polling is needed since, like BootDevice/VirtualMedia, it's a single synchronous call rather than a converging state. The web UI's task-type label (bmcTaskType) is updated too, so these tasks don't render as "Unknown". CRD manifests and deepcopy code regenerated via make manifests-v1alpha1 and make generate-deepcopy. TEMPORARY: go.mod/go.sum replace bmclib with mcanevet/bmclib's secure-boot-key-management branch (bmc-toolbox/bmclib#466), since SetSecureBootKeyManagement isn't in any bmclib release yet. Drop this replace and bump the real require once bmclib tags a release containing it, or CI/reviewers will rightly reject it. Signed-off-by: Mickael Canevet <mickael.canevet@proton.ch>

Matches the corresponding rename in bmc-toolbox/bmclib#466, made per maintainer review feedback there: the old name read like it managed something generic, when it actually just toggles whether the platform accepts non-factory UEFI Secure Boot keys. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickael Canevet <mickael.canevet@proton.ch>

Matches the rename in bmc-toolbox/bmclib#466, made per maintainer review feedback there: the old name read like it managed something generic, when it actually just toggles whether the platform accepts non-factory UEFI Secure Boot keys. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickael Canevet <mickael.canevet@proton.ch>

…ptance New interface controlling whether a platform will accept custom UEFI Secure Boot keys, as opposed to only the vendor-shipped key set. Distinct from SecureBootSetter (enabling/disabling Secure Boot itself) and from SecureBootCertificateImporter (enrolling a specific certificate) - it's the out-of-band gate some vendors require before a certificate import will be accepted at all. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

Implements bmc.CustomSecureBootKeysAllower via the SecureBootPolicy BIOS attribute (Standard/Custom). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

XCC-based systems have an analogous SecureBootPolicy attribute, but it's unconfirmed whether it's reachable through the same generic /Bios attribute PATCH this package already uses, or requires Lenovo's proprietary OneCLI/XCC transport - left undocumented otherwise, this is the FQXSFPU4097G error code callers will hit without it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

…atches AllowCustomSecureBootKeys read the attribute's currently applied value and returned early when it already matched what was requested. Confirmed live, that's unsafe: currently-applied state can match while a different value is genuinely pending from an earlier call in the same boot cycle (e.g. a stale pending PATCH left staged by an interrupted, unrelated caller). Skipping the write left that stale pending value in place, silently reverting an explicit request on the next reboot - observed as a certificate import rejected because SecureBootPolicy committed as Standard despite requesting Custom moments earlier. It's the same class of bug stmcginnis/gofish#571 fixes one layer down, in SetBiosConfiguration's own diff baseline - but this early return happens before SetBiosConfiguration is ever called, so #571 can't reach it. The attribute is still read first, but only to reject platforms that don't expose it at all. The write itself is now unconditional. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

Matches the rename in bmc-toolbox/bmclib#466, made per maintainer review feedback there: the old name read like it managed something generic, when it actually just toggles whether the platform accepts non-factory UEFI Secure Boot keys. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickael Canevet <mickael.canevet@proton.ch>

bmclib gained a Dell-only AllowCustomSecureBootKeys capability for enabling/disabling out-of-band acceptance of custom UEFI Secure Boot keys. Rufio had no Secure Boot support of any kind yet, so this adds the first action for it: AllowCustomSecureBootKeys{Enable bool} on the shared bmc.Action type (v1alpha1 only - v1alpha2 isn't wired to any controller yet), reusable from both bmc.Task/Job and Workflow's preparingActions/postActions since they embed the same Action type. runTask calls bmcClient.AllowCustomSecureBootKeys directly; no status polling is needed since, like BootDevice/VirtualMedia, it's a single synchronous call rather than a converging state. The web UI's task-type label (bmcTaskType) is updated too, so these tasks don't render as "Unknown". CRD manifests and deepcopy code regenerated via make manifests-v1alpha1 and make generate-deepcopy. TEMPORARY: go.mod/go.sum replace bmclib with mcanevet/bmclib's secure-boot-key-management branch (bmc-toolbox/bmclib#466), since AllowCustomSecureBootKeys isn't in any bmclib release yet. Drop this replace and bump the real require once bmclib tags a release containing it, or CI/reviewers will rightly reject it. Signed-off-by: Mickael Canevet <mickael.canevet@proton.ch>

mergify · 2026-09-25T06:03:31Z

bmc-toolbox/bmclib#466 (CustomSecureBootKeysAllower) merged upstream, so the temporary go.mod/go.sum replace pointing at mcanevet/bmclib's PR branch is no longer needed - point the require directly at the real bmc-toolbox/bmclib commit instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

bmclib gained a Dell-only AllowCustomSecureBootKeys capability for enabling/disabling out-of-band acceptance of custom UEFI Secure Boot keys. Rufio had no Secure Boot support of any kind yet, so this adds the first action for it: AllowCustomSecureBootKeys{Enable bool} on the shared bmc.Action type (v1alpha1 only - v1alpha2 isn't wired to any controller yet), reusable from both bmc.Task/Job and Workflow's preparingActions/postActions since they embed the same Action type. runTask calls bmcClient.AllowCustomSecureBootKeys directly; no status polling is needed since, like BootDevice/VirtualMedia, it's a single synchronous call rather than a converging state. The web UI's task-type label (bmcTaskType) is updated too, so these tasks don't render as "Unknown". CRD manifests and deepcopy code regenerated via make manifests-v1alpha1 and make generate-deepcopy. TEMPORARY: go.mod/go.sum replace bmclib with mcanevet/bmclib's secure-boot-key-management branch (bmc-toolbox/bmclib#466), since AllowCustomSecureBootKeys isn't in any bmclib release yet. Drop this replace and bump the real require once bmclib tags a release containing it, or CI/reviewers will rightly reject it. Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

bmc-toolbox/bmclib#466 (CustomSecureBootKeysAllower) merged upstream, so the temporary go.mod/go.sum replace pointing at mcanevet/bmclib's PR branch is no longer needed - point the require directly at the real bmc-toolbox/bmclib commit instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

bmclib gained a Dell-only AllowCustomSecureBootKeys capability for enabling/disabling out-of-band acceptance of custom UEFI Secure Boot keys. Rufio had no Secure Boot support of any kind yet, so this adds the first action for it: AllowCustomSecureBootKeys{Enable bool} on the shared bmc.Action type (v1alpha1 only - v1alpha2 isn't wired to any controller yet), reusable from both bmc.Task/Job and Workflow's preparingActions/postActions since they embed the same Action type. runTask calls bmcClient.AllowCustomSecureBootKeys directly; no status polling is needed since, like BootDevice/VirtualMedia, it's a single synchronous call rather than a converging state. The web UI's task-type label (bmcTaskType) is updated too, so these tasks don't render as "Unknown". CRD manifests and deepcopy code regenerated via make manifests-v1alpha1 and make generate-deepcopy. Requires bmclib at the merged bmc-toolbox/bmclib#466 (CustomSecureBootKeysAllower), so go.mod points at that upstream commit directly. Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

mcanevet marked this pull request as draft September 10, 2026 14:24

mcanevet force-pushed the secure-boot-key-management branch from 9be4fae to bc1cdab Compare September 10, 2026 14:39

mcanevet mentioned this pull request Sep 10, 2026

fix(dell): merge BIOS writes into the pending job instead of failing #467

Open

mcanevet force-pushed the secure-boot-key-management branch 2 times, most recently from dfd74c5 to 9be4fae Compare September 10, 2026 15:10

mcanevet marked this pull request as ready for review September 10, 2026 15:43

mcanevet mentioned this pull request Sep 11, 2026

fix(dell): don't skip the SecureBootPolicy write when applied state matches #472

Closed

mcanevet force-pushed the secure-boot-key-management branch from 9be4fae to b8a17f6 Compare September 11, 2026 08:06

mcanevet force-pushed the secure-boot-key-management branch 2 times, most recently from ec4a204 to ab9fc16 Compare September 14, 2026 06:28

joelrebel reviewed Sep 15, 2026

View reviewed changes

Comment thread bmc/secure_boot.go Outdated

mcanevet changed the title ~~feat: add SecureBootKeyManagementSetter for out-of-band custom key acceptance~~ feat: add CustomSecureBootKeysAllower for out-of-band custom key acceptance Sep 15, 2026

joelrebel force-pushed the secure-boot-key-management branch from c85a686 to 7d76db0 Compare September 16, 2026 10:49

mcanevet force-pushed the secure-boot-key-management branch from 7d76db0 to 58a7d1b Compare September 17, 2026 14:13

mcanevet and others added 4 commits September 17, 2026 16:17

feat(dell): wire CustomSecureBootKeysAllower

17c947c

Implements bmc.CustomSecureBootKeysAllower via the SecureBootPolicy BIOS attribute (Standard/Custom). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Signed-off-by: Mickaël Canévet <mickael.canevet@proton.ch>

mcanevet force-pushed the secure-boot-key-management branch from 58a7d1b to 0964644 Compare September 17, 2026 14:18

joelrebel approved these changes Sep 25, 2026

View reviewed changes

joelrebel added the ready-to-merge label Sep 25, 2026

mergify Bot added the queued label Sep 25, 2026

mergify Bot merged commit fec875d into bmc-toolbox:main Sep 25, 2026
4 of 5 checks passed

mergify Bot removed the queued label Sep 25, 2026

mcanevet mentioned this pull request Sep 25, 2026

feat(rufio): surface AllowCustomSecureBootKeys as a BMC Task/Job action tinkerbell/tinkerbell#987

Open

nuxster mentioned this pull request Oct 6, 2026

Feature/lenovo core interfaces (PR2) #442

Open

2 tasks done

Navigation Menu

Repository navigation

feat: add CustomSecureBootKeysAllower for out-of-band custom key acceptance - #466

feat: add CustomSecureBootKeysAllower for out-of-band custom key acceptance#466
mergify[bot] merged 4 commits into
bmc-toolbox:mainfrom
mcanevet:secure-boot-key-management

mcanevet commented Sep 10, 2026 •

edited

Loading

Uh oh!

Uh oh!

mergify Bot commented Sep 25, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mcanevet commented Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

Uh oh!

mergify Bot commented Sep 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge Queue Status

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mcanevet commented Sep 10, 2026 •

edited

Loading

mergify Bot commented Sep 25, 2026 •

edited

Loading