[202211] Add Secure Boot Support backport with fixes#37
Closed
DavidZagury wants to merge 6 commits into202211from
Closed
[202211] Add Secure Boot Support backport with fixes#37DavidZagury wants to merge 6 commits into202211from
DavidZagury wants to merge 6 commits into202211from
Conversation
- Why I did it Add Secure Boot support to SONiC OS. Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process before the operating system has been loaded. - How I did it Added a signing process to sign the following components: shim, grub, Linux kernel, and kernel modules when doing the build, and when feature is enabled in build time according to the HLD explanations (the feature is disabled by default). - How to verify it There are self-verifications of each boot component when building the image, in addition, there is an existing end-to-end test in sonic-mgmt repo that checks that the boot succeeds when loading a secure system (details below). How to build a sonic image with secure boot feature: (more description in HLD) Required to use the following build flags from rules/config: SECURE_UPGRADE_MODE="dev" SECURE_UPGRADE_DEV_SIGNING_KEY="/path/to/private/key.pem" SECURE_UPGRADE_DEV_SIGNING_CERT="/path/to/cert/key.pem" After setting those flags should build the sonic-buildimage. Before installing the image, should prepared the setup (switch device) with the follow: check that the device support UEFI stored pub keys in UEFI DB enabled Secure Boot flag in UEFI How to run a test that verify the Secure Boot flow: The existing test "test_upgrade_path" under "sonic-mgmt/tests/upgrade_path/test_upgrade_path", is enough to validate proper boot You need to specify the following arguments: Base_image_list your_secure_image Taget_image_list your_second_secure_image Upgrade_type cold And run the test, basically the test will install the base image given in the parameter and then upgrade to target image by doing cold reboot and validates all the services are up and working correctly
…4582) This is done because when there is a default value, we mount to this path, and this creates this folder on the host. #### Why I did it Fix issue that running without overwriting SECURE_UPGRADE_DEV_SIGNING_KEY and SECURE_UPGRADE_DEV_SIGNING_CERT dummy folders are being created on the host. #### How I did it Removed the default assignment to SECURE_UPGRADE_DEV_SIGNING_KEY and SECURE_UPGRADE_DEV_SIGNING_CERT #### How to verify it Build SONiC using your own prod script
…sonic-net#14591) Depends on sonic-net/sonic-linux-kernel#315 #### Why I did it The name SECURE_UPGRADE_DEV_SIGNING_CERT is misleading, this flag is relevant to both to dev and prod signing. #### How I did it Rename all mentions of name SECURE_UPGRADE_DEV_SIGNING_CERT to SECURE_UPGRADE_SIGNING_CERT - this is also done with PR in sonic-linux-kernel repository #### How to verify it Build SONiC using your own prod script
…s to pass their own arguments on the prod signing script
… with flags to align to the dev script
davidpil2002
approved these changes
May 3, 2023
DavidZagury
pushed a commit
that referenced
this pull request
Apr 14, 2025
…sonic-net#22170) #### Why I did it src/dhcpmon ``` * fb808e0 - (HEAD -> master, origin/master, origin/HEAD) Update key in COUNTERS_DB (#37) (4 days ago) [Yaqiang Zhu] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Apr 27, 2025
…tically (sonic-net#22376) #### Why I did it src/sonic-dash-api ``` * 817c0f4 - (HEAD -> master, origin/master, origin/HEAD) Add attributes for FNIC (#37) (27 hours ago) [Lawrence Lee] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Apr 28, 2025
…lly (sonic-net#639) #### Why I did it src/sonic-swss ``` * 4baf54f - (HEAD -> 202412, origin/202412) SRv6: add dscp_mode configuration for MySID entry (#38) (6 hours ago) [mssonicbld] * ff491ba - [SRv6] Add support for SRv6 VPN (#37) (9 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Apr 28, 2025
… automatically (sonic-net#693) #### Why I did it src/sonic-platform-common ``` * 16bb721 - (HEAD -> 202412, origin/202412) [code sync] Merge code from sonic-net/sonic-platform-common:202411 to 202412 (#37) (21 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Apr 28, 2025
…tomatically (sonic-net#887) #### Why I did it src/sonic-linux-kernel ``` * 26b1192 - (HEAD -> 202412, origin/HEAD, origin/202412) [code sync] Merge code from sonic-net/sonic-linux-kernel:202411 to 202412 (#37) (21 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Apr 28, 2025
…omatically (sonic-net#909) #### Why I did it src/sonic-swss-common ``` * c55ee84 - (HEAD -> 202412, origin/HEAD, origin/202412) [FC] remove FLEX_COUNTER_DELAY_STATUS_FIELD (sonic-net#982) (#37) (22 hours ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Apr 28, 2025
…tically (sonic-net#926) #### Why I did it src/sonic-sairedis ``` * a2ee5d6 - (HEAD -> 202412, origin/HEAD, origin/202412) Update build_and_install_module.sh to match newer Linux kernel version (#37) (11 seconds ago) [mssonicbld] ``` #### How I did it #### How to verify it #### Description for the changelog
DavidZagury
pushed a commit
that referenced
this pull request
Mar 9, 2026
…tomatically (sonic-net#25498) #### Why I did it src/sonic-platform-pde ``` * 6e36a87 - (HEAD -> master, origin/master, origin/HEAD) Merge pull request #37 from rustiqly/add-copilot-instructions (11 hours ago) [rustiqly] * 4fd3ff9 - Add .github/copilot-instructions.md for AI-assisted development (3 days ago) [Rustiqly] ``` #### How I did it #### How to verify it #### Description for the changelog
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
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.
Backport of sonic-net#12692
And following fixes:
sonic-net#14591
sonic-net#14582
sonic-net#14581
sonic-net#14589
Why I did it
Add Secure Boot support to SONiC OS.
Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process before the operating system has been loaded.
Work item tracking
How I did it
Added a signing process to sign the following components:
shim, grub, Linux kernel, and kernel modules when doing the build, and when feature is enabled in build time according to the HLD explanations (the feature is disabled by default).
How to verify it
There are self-verifications of each boot component when building the image, in addition, there is an existing end-to-end test in sonic-mgmt repo that checks that the boot succeeds when loading a secure system (details below).
How to build a sonic image with secure boot feature: (more description in HLD)
Required to use the following build flags from rules/config:
SECURE_UPGRADE_MODE="dev"
SECURE_UPGRADE_DEV_SIGNING_KEY="/path/to/private/key.pem"
SECURE_UPGRADE_DEV_SIGNING_CERT="/path/to/cert/key.pem"
After setting those flags should build the sonic-buildimage.
Before installing the image, should prepared the setup (switch device) with the follow:
check that the device support UEFI
stored pub keys in UEFI DB
enabled Secure Boot flag in UEFI
How to run a test that verify the Secure Boot flow:
The existing test "test_upgrade_path" under "sonic-mgmt/tests/upgrade_path/test_upgrade_path", is enough to validate proper boot
You need to specify the following arguments:
Base_image_list your_secure_image
Taget_image_list your_second_secure_image
Upgrade_type cold
And run the test, basically the test will install the base image given in the parameter and then upgrade to target image by doing cold reboot and validates all the services are up and working correctly
note: the path to the existing sonic-mgmt test can be found in the link in the HLD description.
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)