Add hld for secure_upgrade_certificate_management_cli - #2534
rameshraghupathy wants to merge 5 commits into
Conversation
Signed-off-by: Ramesh Babu Raghupathy <ram@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
Signed-off-by: Ramesh Babu Raghupathy <ram@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
Signed-off-by: Ramesh Babu Raghupathy <ram@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
| | SB-CERT-REQ-1 | SONiC shall provide show commands for Secure Boot backend state. | | ||
| | SB-CERT-REQ-2 | SONiC shall provide a show command for Secure Boot mode/policy when supported. | | ||
| | SB-CERT-REQ-3 | SONiC shall show state for `PK`, `KEK`, `db`, and `dbx`. | | ||
| | SB-CERT-REQ-4 | SONiC may distinguish vendor/platform and customer stores when the backend exposes that distinction. | |
There was a problem hiding this comment.
Is there an example of this, where a backend distinguishes between vendor and customer?
There was a problem hiding this comment.
@saiarcot895 Yes. One example is a platform secure-variable implementation that maintains
separate platform/vendor-owned and customer-owned copies of the Secure Boot
variables, for example PKVendor/PKCustomer, KEKVendor/KEKCustomer,
dbVendor/dbCustomer, and dbxVendor/dbxCustomer. The distinction is not mandated by UEFI and SONiC does not require every platform to implement separate stores. This requirement is intentionally optional. In our case it is: PKCisco / PKCustomer
KEKCisco / KEKCustomer
dbCisco / dbCustomer
dbxCisco / dbxCustomer
| The SONiC CLI communicates with a platform-provided Secure Boot backend through the platform-neutral executable interface: | ||
|
|
||
| ```text | ||
| /usr/sbin/secure-boot-backend | ||
| ``` |
There was a problem hiding this comment.
Does each platform really need to define/provide a platform-specific backend? There is a UEFI standard for this that can work for amd64; for arm64, if uboot is being used, then uboot itself supports enabling a UEFI-compatible interface for this.
I recommend having a generic file that can be used if a platform doesn't use a platform-specific interface.
There was a problem hiding this comment.
@saiarcot895 Agreed. The intent was not to require every platform to implement a unique backend.
I will clarify the HLD so that /usr/sbin/secure-boot-backend (A platform supporting this CLI shall provide this entry point.) is the stable SONiC-facing contract, while its implementation may be:
- a generic SONiC backend using the standard UEFI variable interface, or
- a platform-specific backend when the platform requires additional secure
storage, policy, hardware RoT, or vendor/customer-store handling.
This allows amd64/arm64 platforms exposing standard UEFI variable services to
use a common implementation while preserving an override point for platforms
with specialized secure-variable mechanisms.
@saiarcot895 Conceptually I can do something like the following:
-
If a platform backend is explicitly registered:
use platform backend -
Else if standard UEFI variable services are available:
use SONiC generic UEFI backend -
Else:
report Secure Boot management unsupported
…t. Otherwise, when standard UEFI variable services are available, SONiC uses the generic UEFI backend. If neither is available, Secure Boot management is reported as unsupported. Signed-off-by: Ramesh Babu Raghupathy <ram@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
Signed-off-by: Ramesh Babu Raghupathy <ram@cisco.com>
|
/azp run |
|
No pipelines are associated with this pull request. |
This branch has not been deployed
3 participants
What I did
Added the High-Level Design for a platform-agnostic SONiC Secure Boot Certificate Management CLI.
The HLD defines the architecture and management model for Secure Boot certificate and authenticated-variable lifecycle operations for the standard UEFI Secure Boot variables:
PK)KEK)db)dbx)The design defines:
The upstream SONiC CLI communicates with the platform through the platform-neutral backend entry point:
Related implementation:
sonic-utilities PR #4830 - Add Secure Boot show and config CLI support
How I did it
Defined the design in three logical layers:
SONiC Secure Boot CLI
Secure Boot backend contract
Platform implementation
The HLD preserves standard UEFI authenticated-variable semantics while allowing different platforms to use different secure storage implementations underneath the SONiC interface.
The CLI does not directly modify protected storage and does not become the cryptographic authorization boundary.
The backend remains responsible for:
Private signing keys remain off the target device.
The HLD also defines the corresponding CLI model:
show secure-boot status
show secure-boot mode
show secure-boot keys
show secure-boot key <PK|KEK|db|dbx> [--store vendor|customer|unified]
config secure-boot certificate update <PK|KEK|db|dbx> [--operation append|update|remove]