Create Secureboot_uefi_key_management.md #1451
Conversation
Secure boot UEFI key management HLD
Added picture for key hierarchies
Image size change
|
community review recording https://zoom.us/rec/share/2iI8PrtCImHig7wTVU0JLRj2TmnqlzWugD7yJuCpN866CbS2CKLS6jAR94vMOMKs.YmbqVw1-zSzQI03F |
|
|
||
|  | ||
|
|
||
| ### 5.2 OVMF based platform can use Linux implementation to access UEFI variable |
There was a problem hiding this comment.
can you clarify the cisco code contribution here?
There was a problem hiding this comment.
The HLD is referred to as OVMF since it is Open firmware and available for someone to experiment with. Cisco BIOS has implemented a similar approach to OVMF. When Cisco8000 implements SONiC UEFI key management for Cisco hardware similar code will be added under Cisco platform-specific code. That means the common contribution here is the SONiC CLI and Python module defining the base class that is mentioned in the document.
There was a problem hiding this comment.
Great to see some progress in SONiC around UEFI Secure Boot features!
Please see my inline comments, but I also have some general comments:
- enrolling and managing custom keys for Secure Boot is probably the pinnacle of security in this area, and the hardest to achieve for average users, yet these commands are really only helpful for that specific use-case
- using custom keys particularly in
dbcan have dire consequences particularly ifSecureBoot=1 - the system should also provide access to the
SecureBootvariable - if
SecureBoot=1, there should be protection of the boot chain: ifdbordbxget updated, the system should ensure that the current boot entries are actually still going to work. As you mentioned updating these databases requires a reboot, but theshimof a normal SONiC installation will need to be signed correctly as well for this to still work. So either there should be a check of at least the SONiC OS boot entry against thedb/dbxbefore updating it, or maybe the system should refuse to reboot otherwise (?) --> this requires some more discussion IMHO - the same goes for SONiC updates, they should fail if an update leads to installing a
shimwhich is not going to be able to boot any longer - I understand that the idea for specific SONiC CLI commands is to abstract potentially platform specific implementations away. However, would you mind providing examples where different implementations would be necessary? At least on x86 I would have yet to encounter hardware where the standard tooling would be insufficient.
| 2. platform security uefi variables update kek <file> | ||
| 3. platform security uefi variables update db <file> | ||
| 4. platform security uefi variables update dbx <file> | ||
| ``` |
There was a problem hiding this comment.
a couple of comments here:
- can we call the subcommand
securebootinstead ofuefi? This is more fitting as these commands are all specifically dealing with secureboot variables, and not other UEFI variables - You outlined really well all the steps which are necessary in order to create an authenticated variable file. Honestly, this is the hard part, while running a command to update the variable will on most platforms simply translate to an
efi-updatevarcommand or by direct access throughefivarfs. It would be nice to see an easy UX here - I'm missing access to the general
SecureBootvariable which can get information if UEFI Secure Boot is enabled or not on the platform
| cat db-orig-1.esl db-orig-3.esl > DB-new.esl | ||
| 7. Create authenticated variable and sign it | ||
| sign-efi-sig-list -g "<GUID>" -k KEK.key -c KEK.crt db DB-new.esl DB-new.auth | ||
| 8. Copy DB-new.auth to the system and use CLI to update UEFI database |
There was a problem hiding this comment.
What is the command used here?
Can you copy the DB-new.auth without providing the KEK.key to the system?
There was a problem hiding this comment.
I believe the idea is to perform the signing outside of the system, and then in (8) only copy the new file to the system where you can then update it with the CLI
There was a problem hiding this comment.
I understand, but there might be UEFI cases where you cannot upload a new entry to the UEFI without providing the private KEK key (worth checking if this is true, when I played with these items a few years ago this was the case).
Or if you are entering a new KEK, you'll need the PK.
| ``` | ||
|
|
||
| ## 7 Test considerations | ||
| The sonic-mgmt can cover UEFI key management such as adding, updating, removing, and revoking UEFI keys. |
There was a problem hiding this comment.
Should add a note that this feature should enhance secure boot tests where we can install an image with a specific key, then move it to the dbx and therefor - the same image cannot be installed anymore (signed with the previous key).
|
|
||
| ```` | ||
|
|
||
| ### 4.4 Revoke keys |
There was a problem hiding this comment.
Worth mentioning that key revocation is a potentially destructive action.
If we are removing a DB entry that is currently being used - this will cause the system to enter fatal mode (recoverable only via UEFI).
There was a problem hiding this comment.
totally agree. See also my comment above about protection of boot chain.
| The platform plugin for this OVMF type UEFI can use either sysfs or efi-readvar and efi-updatevar to implement getVariable() and setVariable() methods. | ||
|
|
||
|
|
||
| ## 6 SONiC CLI commands |
There was a problem hiding this comment.
What are the potential return values here?
Updatevar might fail (it being immutable, specific platform constraints, etc').
What is the expected design for these type of commands? As I see that they only receive a file and perform an action.
|
@xumia for reference |
|
code PR is not ready, move to backlog for future release |
Secure boot UEFI key management HLD