Re: [edk2-devel] [RFC] Secure boot default key


Samer El-Haj-Mahmoud
 

Adding SecurityPkg and Arm maintainers

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Friday, April 16, 2021 8:16 AM
To: rfc@edk2.groups.io; gjb@semihalf.com
Cc: Marcin Wojtas <mw@semihalf.com>; Samer El-Haj-Mahmoud <Samer.El-
Haj-Mahmoud@arm.com>; Sunny Wang <Sunny.Wang@arm.com>; Paul Yang
<Paul.Yang@arm.com>
Subject: Re: [edk2-rfc] [edk2-devel] [RFC] Secure boot default key

On 04/16/21 14:10, Laszlo Ersek wrote:
On 04/15/21 13:59, Grzegorz Bernacki wrote:
Hello,

I would like to ask you to review the proposal for new application
for enrolling Secure Boot keys. The application uses content of
PKDefault, KEKDefault, dbDefault, dbtDefault and dbxDefault to set
Secure Boot key. Default variables are initialized based on keys
embedded in flash binary file. Please find details in following document:

https://drive.google.com/file/d/1rC6BjRWKODdXPdAa5cIeBG8_ye2L8aSZ/vie
w?usp=sharing
- A new platform DXE driver (which need not even stay resident), for
locating some FFS files and their sections, and for copying their
contents into PKDefault and friends, seems like a good / useful idea to me.

- Regarding the following sentence:

However there is no need to keep these variables as non-volatile in
order to avoid unnecessary bloating of the consumed non-volatile
storage space.
This is valid, but redundant (or at least somewhat redundantly
expressed), IMO. The UEFI spec already marks PKDefault as "BS, RT"
(section 3.3).

- The setting of PK from PKDefault (and similarly for the other
variables) is indeed a separate action. The UEFI spec says this is
primarily an OS action (again section 3.3), but I agree having a
dedicated UEFI app for this may be useful.

- Regarding the following sentence:

In case when default variables are already initialized a warning
message will be printed and variables will not be changed.

A warning is possible perhaps via status code reporting, or DEBUG. A
platform DXE driver is not supposed to write to the console.

- The idea as a whole looks good to me. I agree it should be testable
with OVMF, provided the FDF file(s) are modified as needed; however, I
wouldn't like to have that in the FDF file(s) permanently -- or at
least it should be gated with a new build time feature test macro.

The

SECTION RAW = ...

statements in the FDF files could perhaps refer to macros as well (for
the pathnames). So a user building a platform with this feature
enabled would have to pass a -D flag (boolean) for enabling the
feature in general (enabling the necessary lines in both the DSC and
the FDF file(s)), and then further -D flags for specifying the pathnames.
You could perhaps introduce DSC and FDF snippets (include files) too, under
SecurityPkg, so that any platform utilizing this feature do so through identical
macro names.

Thanks
Laszlo
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Join rfc@edk2.groups.io to automatically receive all group messages.