Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Secure Boot Support #12692

Merged
merged 13 commits into from
Mar 14, 2023
Merged

Conversation

davidpil2002
Copy link
Contributor

@davidpil2002 davidpil2002 commented Nov 13, 2022

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)

  1. 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.
  1. 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
  1. 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)

  • master
  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111
  • 202205
  • 202211

Description for the changelog

Link to config_db schema for YANG module changes

No REDIS DB used in this feature

HLD link: sonic-net/SONiC#1028

A picture of a cute animal (not mandatory but encouraged)

@davidpil2002
Copy link
Contributor Author

davidpil2002 commented Nov 14, 2022

hi @lguohan,

Apparently, there is some test issue when connecting to the host, the attached error is below.
For now, I didn't find something related to this specific commit, can you help with this issue?

details from log:
link: https://www.testbed-tools.org/scheduler/testplan/7215
error msg:
E AnsibleConnectionFailure: Host unreachable

@liat-grozovik ++

PS: sent an email to buildimage team
@yxieca FYI

rules/config Outdated Show resolved Hide resolved
@lguohan
Copy link
Collaborator

lguohan commented Nov 25, 2022

how can we test this SB feature? is there a virtual environment that we can test and validate?

@liat-grozovik
Copy link
Collaborator

liat-grozovik commented Nov 25, 2022 via email

@lguohan
Copy link
Collaborator

lguohan commented Nov 25, 2022

the design doc says only signing mellanox specific kernel module, wonder why?

@lguohan
Copy link
Collaborator

lguohan commented Nov 25, 2022

the pr needs to provide steps how to build sb-enabled image for other to try it out. otherwise, it would be difficult for community members to check.

@davidpil2002
Copy link
Contributor Author

davidpil2002 commented Nov 27, 2022

how can we test this SB feature? is there a virtual environment that we can test and validate?

with a physical device:

  1. enable the Secure Boot flag in UEFI.
  2. store the public keys in UEFI.
  3. build the sonic-buildimage using the Secure Boot flags according to the HLD explanations.
  4. manually, check that the boot and init flow works.
  5. automation - run the corresponding sonic-mgmt tests. (pointer to sonic-mgmt test should be attached in the HLD description)

In general - a successful secure boot flow is one where you load all kernel modules and nothing fails.

With a virtual machine:

  1. should verify that the VM supports UEFI and supports storing pub keys in the DB and Secure Boot UEFI flag.
    In addition - currently the Linux is pulling the public key from the UEFI DB in order to verify the sbsign output for each secure boot component. The VM would have to support this basic Linux flow.
  2. Do steps like a physical device.

@davidpil2002
Copy link
Contributor Author

the design doc says only signing mellanox specific kernel module, wonder why?

fix the doc to generic vendor:
fsroot-vendor_name instead fsroot-mellanox

@davidpil2002
Copy link
Contributor Author

the pr needs to provide steps how to build sb-enabled image for other to try it out. otherwise, it would be difficult for community members to check.

The HLD shows all the steps in general, but I added as per your requested more description in this PR.

@davidpil2002
Copy link
Contributor Author

the pr needs to provide steps how to build sb-enabled image for other to try it out. otherwise, it would be difficult for community members to check.

done

@davidpil2002
Copy link
Contributor Author

the design doc says only signing mellanox specific kernel module, wonder why?

fixed

Copy link
Contributor Author

@davidpil2002 davidpil2002 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack all the comments/concerns & add one commit

Copy link
Contributor Author

@davidpil2002 davidpil2002 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix all comments, pls approve/review @qiluo-msft @Yarden-Z

@abdosi
Copy link
Contributor

abdosi commented Mar 6, 2023

/ azp run Azure.sonic-buildimage

@abdosi
Copy link
Contributor

abdosi commented Mar 6, 2023

@qiluo-msft and @xumia can we review again this please

@abdosi
Copy link
Contributor

abdosi commented Mar 6, 2023

@sacnaik can you create PR for 202205 for this change ?

@abdosi abdosi added the Chassis 🤖 Modular chassis support label Mar 6, 2023
@davidpil2002
Copy link
Contributor Author

@sacnaik can you create PR for 202205 for this change ?

This PR is pending the @qiluo-msft approval, after the approval, we can cherry-pick. is it that OK?

@liat-grozovik liat-grozovik merged commit 8098bc4 into sonic-net:master Mar 14, 2023
sacnaik added a commit to sacnaik/sonic-buildimage that referenced this pull request Mar 15, 2023
   Backporting sonic-net#12692 PR on 202205 branch.

   The diffs of sonic-net#12692 does not cleanly gets apply.

   on 202205 branch. Hence the patch sonic-net#12692 slightly

   modified so that it can get applied on 202205 branch

   without functional break.

Signed-off-by: Sachin Naik <sachnaik@cisco.com>
@sacnaik sacnaik mentioned this pull request Mar 15, 2023
8 tasks
@ITJamie
Copy link

ITJamie commented Mar 18, 2023

Please note the following issue with a build of master: #14316. install failed due to missing mokutil

DavidZagury pushed a commit to keboliu/sonic-buildimage that referenced this pull request Mar 22, 2023
- 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
keboliu pushed a commit to keboliu/sonic-buildimage that referenced this pull request Apr 4, 2023
- 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
DavidZagury pushed a commit to DavidZagury/sonic-buildimage that referenced this pull request May 1, 2023
- 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
DavidZagury pushed a commit to DavidZagury/sonic-buildimage that referenced this pull request May 7, 2023
- 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
StormLiangMS pushed a commit that referenced this pull request May 15, 2023
- 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

Co-authored-by: davidpil2002 <91657985+davidpil2002@users.noreply.github.com>
abdosi added a commit to sonic-net/sonic-buildimage-msft that referenced this pull request May 17, 2023
Why I did it
To support UEFI secure boot on the 202205 branch

How I did it
The feature is supported at the master branch see
sonic-net/sonic-buildimage#12692

Backported sonic-net/sonic-buildimage#12692 from master to msft/202205 branch

How to verify it
Booted on UEFI secure boot enabled and disabled hardware.
mlok-nokia pushed a commit to mlok-nokia/sonic-buildimage that referenced this pull request Jun 5, 2024
   Backporting sonic-net#12692 PR on 202205 branch.

   The diffs of sonic-net#12692 does not cleanly gets apply.

   on 202205 branch. Hence the patch sonic-net#12692 slightly

   modified so that it can get applied on 202205 branch

   without functional break.

Signed-off-by: Sachin Naik <sachnaik@cisco.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.