Secureboot: install secureboot shim/grub if image is built with secureboot#23735
Merged
lguohan merged 1 commit intosonic-net:masterfrom Oct 18, 2025
Merged
Secureboot: install secureboot shim/grub if image is built with secureboot#23735lguohan merged 1 commit intosonic-net:masterfrom
lguohan merged 1 commit intosonic-net:masterfrom
Conversation
…eboot support During an ONIE install, secureboot shim/grub were only being installed if ONIE was booted in secureboot mode. This is undesirable as it would prevent the user from enabling secureboot after the fact. The secureboot signed shim and grub will operate normally with secureboot disabled.
Collaborator
|
/azp run Azure.sonic-buildimage |
Collaborator
Author
|
@DavidZagury @davidpil2002 @qiluo-msft please review |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This was referenced Aug 17, 2025
Enhancement: Secureboot production signing of kernel modules using ephemeral keys + bug fixes
#23406
Closed
Collaborator
Author
|
@Yarden-Z any comments? |
Collaborator
|
This pull request makes significant changes to the logic for detecting and handling UEFI Secure Boot in the installer script default_platform.conf. Here’s a review of the PR: Summary of Changes
Motivation (from code comments)
Pros
Cons / Considerations
Suggestions
ConclusionThis PR streamlines Secure Boot image detection by focusing on image content rather than system state. It improves predictability and reduces the risk of confusing reinstall requirements. However, it trades off dynamic detection for build-time certainty, so clear documentation and communication are important. Let me know if you want an in-depth review of code style, security, or potential edge cases! |
lguohan
approved these changes
Oct 18, 2025
lguohan
pushed a commit
that referenced
this pull request
Oct 27, 2025
…s and bugfixes) (#23405) #### Why I did it The current sonic secureboot implementation assumes all assets are signed with the DB Key. There are roughly 3600 kernel modules that get signed in the process. Organizations may have varying security policy requirements where any signing requests may require signoff by one or more parties, this may simply be infeasible for that many requests. Given that the DB key may be a long-lived key, and only RSA 2048 is often used or available, it is a security best-practice to sign as few assets as possible with such a key. This PR is fully backwards compatible with any pre-existing usages. It introduces a new `rules/config` setting of `SECURE_UPGRADE_KERNEL_CAFILE` which is a path to a file for all trusted keys to embed into the kernel. If that setting is not specified, it defaults to `SECURE_UPGRADE_SIGNING_CERT`. There are no other infrastructure changes to support ephemeral keys for kernel module signing. It is up to the organization to generate the ephemeral keys and pass them into their own signing scripts as required. Dependent PR: * sonic-net/sonic-linux-kernel#499 Related PRs: * sonic-net/sonic-utilities#3989 * #23732 * #23733 * #23734 * #23735 * #23736 Fixes #23406 ##### Work item tracking #### How I did it Worked through production signing steps and hit issues when requiring signing approval with our HSM. This was the most elegant solution that required the minimal changes. This has been fully tested. #### How to verify it Since there are no provided production signing script examples this would require a vendor with an existing implementation to validate. Nexthop has validated this internally. #### Which release branch to backport (provide reason below if selected) #### Tested branch (Please provide the tested image version) master as of 20250721 #### Description for the changelog Secureboot: Production signing enhancement to allow ephemeral kernel module keys #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Brad House <bhouse@nexthop.ai>
FengPan-Frank
pushed a commit
to FengPan-Frank/sonic-buildimage
that referenced
this pull request
Dec 4, 2025
…eboot support (sonic-net#23735) During an ONIE install, secureboot shim/grub were only being installed if ONIE was booted in secureboot mode. This is undesirable as it would prevent the user from enabling secureboot after the fact. The secureboot signed shim and grub will operate normally with secureboot disabled. Signed-off-by: Feng Pan <fenpan@microsoft.com>
FengPan-Frank
pushed a commit
to FengPan-Frank/sonic-buildimage
that referenced
this pull request
Dec 4, 2025
…s and bugfixes) (sonic-net#23405) #### Why I did it The current sonic secureboot implementation assumes all assets are signed with the DB Key. There are roughly 3600 kernel modules that get signed in the process. Organizations may have varying security policy requirements where any signing requests may require signoff by one or more parties, this may simply be infeasible for that many requests. Given that the DB key may be a long-lived key, and only RSA 2048 is often used or available, it is a security best-practice to sign as few assets as possible with such a key. This PR is fully backwards compatible with any pre-existing usages. It introduces a new `rules/config` setting of `SECURE_UPGRADE_KERNEL_CAFILE` which is a path to a file for all trusted keys to embed into the kernel. If that setting is not specified, it defaults to `SECURE_UPGRADE_SIGNING_CERT`. There are no other infrastructure changes to support ephemeral keys for kernel module signing. It is up to the organization to generate the ephemeral keys and pass them into their own signing scripts as required. Dependent PR: * sonic-net/sonic-linux-kernel#499 Related PRs: * sonic-net/sonic-utilities#3989 * sonic-net#23732 * sonic-net#23733 * sonic-net#23734 * sonic-net#23735 * sonic-net#23736 Fixes sonic-net#23406 ##### Work item tracking #### How I did it Worked through production signing steps and hit issues when requiring signing approval with our HSM. This was the most elegant solution that required the minimal changes. This has been fully tested. #### How to verify it Since there are no provided production signing script examples this would require a vendor with an existing implementation to validate. Nexthop has validated this internally. #### Which release branch to backport (provide reason below if selected) #### Tested branch (Please provide the tested image version) master as of 20250721 #### Description for the changelog Secureboot: Production signing enhancement to allow ephemeral kernel module keys #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Brad House <bhouse@nexthop.ai> Signed-off-by: Feng Pan <fenpan@microsoft.com>
xwjiang-ms
pushed a commit
to xwjiang-ms/sonic-buildimage
that referenced
this pull request
Dec 22, 2025
…s and bugfixes) (sonic-net#23405) #### Why I did it The current sonic secureboot implementation assumes all assets are signed with the DB Key. There are roughly 3600 kernel modules that get signed in the process. Organizations may have varying security policy requirements where any signing requests may require signoff by one or more parties, this may simply be infeasible for that many requests. Given that the DB key may be a long-lived key, and only RSA 2048 is often used or available, it is a security best-practice to sign as few assets as possible with such a key. This PR is fully backwards compatible with any pre-existing usages. It introduces a new `rules/config` setting of `SECURE_UPGRADE_KERNEL_CAFILE` which is a path to a file for all trusted keys to embed into the kernel. If that setting is not specified, it defaults to `SECURE_UPGRADE_SIGNING_CERT`. There are no other infrastructure changes to support ephemeral keys for kernel module signing. It is up to the organization to generate the ephemeral keys and pass them into their own signing scripts as required. Dependent PR: * sonic-net/sonic-linux-kernel#499 Related PRs: * sonic-net/sonic-utilities#3989 * sonic-net#23732 * sonic-net#23733 * sonic-net#23734 * sonic-net#23735 * sonic-net#23736 Fixes sonic-net#23406 ##### Work item tracking #### How I did it Worked through production signing steps and hit issues when requiring signing approval with our HSM. This was the most elegant solution that required the minimal changes. This has been fully tested. #### How to verify it Since there are no provided production signing script examples this would require a vendor with an existing implementation to validate. Nexthop has validated this internally. #### Which release branch to backport (provide reason below if selected) #### Tested branch (Please provide the tested image version) master as of 20250721 #### Description for the changelog Secureboot: Production signing enhancement to allow ephemeral kernel module keys #### Link to config_db schema for YANG module changes N/A #### A picture of a cute animal (not mandatory but encouraged) Signed-off-by: Brad House <bhouse@nexthop.ai> Signed-off-by: xiaweijiang <xiaweijiang@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why I did it
During an ONIE install, secureboot shim/grub were only being installed if ONIE was booted in secureboot mode. This is undesirable as it would prevent the user from enabling secureboot after the fact. The secureboot signed shim and grub will operate normally with secureboot disabled.
Work item tracking
How I did it
Update installer script to always install the signed secureboot grub and shim if found in the relevant paths.
How to verify it
Build a secureboot enabled image. Boot into a machine with secureboot disabled in the BIOS. Install SONiC via ONIE. Reboot and enable secureboot in the BIOS. Observe SONiC boots as expected with secureboot enabled. Prior to this patch it would not.
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
master as of 20250817
Description for the changelog
Secureboot: install secureboot shim/grub if image is built with secureboot
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)
Fixes: #23406
Signed-off-by: Brad House bhouse@nexthop.ai