Secureboot modifications for ephemeral key signing#499
Merged
lguohan merged 2 commits intosonic-net:masterfrom Oct 18, 2025
Merged
Secureboot modifications for ephemeral key signing#499lguohan merged 2 commits intosonic-net:masterfrom
lguohan merged 2 commits intosonic-net:masterfrom
Conversation
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 is backwards-compatible so it can be applied prior to the sonic-buildimage patches.
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
Author
|
@davidpil2002 can you review this since you contributed the initial secureboot implementation? |
Contributor
|
Hi Brad,
Yes, I can
Thanks,
David
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Brad House - NextHop ***@***.***>
Sent: Tuesday, July 22, 2025 1:15:49 am
To: sonic-net/sonic-linux-kernel ***@***.***>
Cc: David Pilnik ***@***.***>; Mention ***@***.***>
Subject: Re: [sonic-net/sonic-linux-kernel] Secureboot modifications for ephemeral key signing (PR #499)
[https://avatars.githubusercontent.com/u/201617817?s=20&v=4]bhouse-nexthop left a comment (sonic-net/sonic-linux-kernel#499)<#499 (comment)>
@davidpil2002<https://github.com/davidpil2002> can you review this since you contributed the initial secureboot implementation?
—
Reply to this email directly, view it on GitHub<#499 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AV3JOAPCIKTQYS4BBJAQRDL3JVRA7AVCNFSM6AAAAACB7ZJEJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOJZGU2DONZSGY>.
You are receiving this because you were mentioned.
|
Contributor
|
In general the most of the flows look good to me. |
saiarcot895
approved these changes
Sep 9, 2025
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Contributor
|
You provided a pull request diff for https://github.com/sonic-net/sonic-linux-kernel/pull/499/files. Here is a review based on the changes shown: Summary of ChangesMakefile
manage-config
Purpose & ImpactPurpose:
Impact:
Technical ReviewCorrectness:
Backward Compatibility:
Documentation & Clarity:
Testing:
Suggestions
SummaryThis PR is a sensible refactor to clarify the purpose of a configuration variable used in secure kernel upgrades. The implementation is clean, and backward compatibility is considered. Please verify that any dependent scripts or documentation are updated accordingly. If you need a more detailed review regarding usage or possible edge cases, let me know! |
lguohan
pushed a commit
to sonic-net/sonic-buildimage
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
…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
6 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.
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 is backwards-compatible so it can be applied prior to the sonic-buildimage patches.
Related PRs: sonic-net/sonic-buildimage#23405
Fixes sonic-net/sonic-buildimage#23406