EFI Secure boot default keys
Heinrich Schuchardt
xypron.glpk at gmx.de
Thu Jul 6 17:22:40 CEST 2023
On 06.07.23 11:25, AKASHI Takahiro wrote:
> On Thu, Jul 06, 2023 at 08:23:06AM +0000, Neil Jones wrote:
>>>>>> Please can someone describe the format of the file needed for the default / built-in EFI secure boot keys (ubootefi.var)
>>>>>>
>>>>>> The only docs I have found suggest its best to enroll the keys from within u-boot onto some removable media, then copy this off and use this as the default, this is not very helpful and doesn't work for me:
>>>>>>
>>>>>> => fatload mmc 0:1 ${loadaddr} PK.aut
>>>>>> 2053 bytes read in 18 ms (111.3 KiB/s)
>>>>>> => setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
>>>>>> setenv - set environment variables
>>>>>>
>>>>>> Usage:
>>>>>> setenv setenv [-f] name value ...
>>>>>> - [forcibly] set environment variable 'name' to 'value ...'
>>>>>> setenv [-f] name
>>>>>> - [forcibly] delete environment variable 'name'
>>>>>>
>>>>>> my setenv doesn't support all the extra switches ? This is with 2022.04, all other EFI options seem to be in this release and I can boot unsigned EFI images ok.
>>>>>
>>>>> Please turn on CONFIG_CMD_NVEDIT_EFI when building your U-Boot.
>>>>>
>>>>> This option was disabled by the commit:
>>>>> commit 3b728f8728fa (tag: efi-2020-01-rc1)
>>>>> Author: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>> Date: Sun Oct 6 15:44:22 2019 +0200
>>>>>
>>>>> cmd: disable CMD_NVEDIT_EFI by default
>>>>>
>>>>> The binary size of efi has grown much since in the past, though.
>>>>>
>>>>> -Takahiro Akashi
>>>>
>>>> Thanks, I have secure boot working now. A tool to generate the ubootefi.var offline or even just a description of the file format would be very useful.
>>>
>>> Thank you for the suggestion. While I'd like to defer to Heinrich,
>>> the C definition of the file format can be found as struct efi_var_file
>>> in include/efi_variable.h
>>>
>>
>> Thanks!
>>
>>>> I have noticed one issue when using ubootefi.var on mmc, when I switch boot order it wipes out the keys and I have to re-enrol them:
>>>>
>>>> => fatls mmc 0:1
>>>> 3040 ubootefi.var
>>>>
>>>> 1 file(s), 0 dir(s)
>>>
>>> I'm not sure that secure boot related variables have been loaded
>>> at this point.
>>
>> This is during initial generation / enrollment of the variables
Hello Neil,
If you want to use secure boot, please either use
CONFIG_EFI_VARIABLES_PRESEED or CONFIG_EFI_MM_COMM_TEE.
U-Boot will never load the security database from file.
Without CONFIG_EFI_MM_COMM_TEE=y setting up the security database via
setenv -e is only usable for one time testing. After reboot the security
database will be gone (or fallback to the preseed for
CONFIG_EFI_VARIABLES_PRESEED=y).
Best regards
Heinrich
>>
>>> Anyhow, please try to enable CONFIG_EFI_VARIABLES_PRESEED with
>>> EFI_VAR_FILE_NAME set. Otherwise, those variables will never be
>>> restored.
>>> (This is another topic that are not described in doc/develop/uefi.)
>>
>> I have CONFIG_EFI_VARIABLES_PRESEED working, but while generating the file ubootefi.var for the first time (without CONFIG_EFI_VARIABLES_PRESEED set) you have to follow a specific order, or the file gets overwritten eg:
>>
>> Working:
>>
>> efidebug boot order 1 2
>> efidebug boot add -b 1 Signed mmc 0:1 /ImageSig.efi
>> efidebug boot add -b 2 UnSigned mmc 0:1 /Image
>> fatload mmc 0:1 ${loadaddr} PK.aut
>> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
>> fatload mmc 0:1 ${loadaddr} KEK.aut
>> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
>> fatload mmc 0:1 ${loadaddr} DB.aut
>> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
>>
>>
>> Failing:
>>
>> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
>> fatload mmc 0:1 ${loadaddr} KEK.aut
>> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize KEK
>> fatload mmc 0:1 ${loadaddr} DB.aut
>> setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize db
>> efidebug boot order 1 2 ### This command overwrites the keys just loaded
>
> Are you sure that "env print -e" shows all the variables including
> PK, KEK and db at this point?
>
> Since I don't have enough time to examine this issue, can you please
> try to trace efi_var_collect() in efi_var_file.c which is responsible
> for enumerating all the non-volatile variables to be saved at each
> SET_VARIABLE api call?
>
> -Takahiro Akashi
>
>> Cheers,
>>
>> Neil
>>
>>>
>>> Thanks,
>>> -Takahiro Akashi
>>>
>>>> => efidebug boot order 2 1
>>>> => fatls mmc 0:1
>>>> 440 ubootefi.var
>>>>
>>>> (Size drops from 3040 to 440 bytes and keys have gone)
>>
>>> ________________________________
>>> From: AKASHI Takahiro <takahiro.akashi at linaro.org>
>>> Sent: 29 June 2023 02:01
>>> To: Neil Jones <neil.jones at blaize.com>
>>> Cc: u-boot at lists.denx.de <u-boot at lists.denx.de>
>>> Subject: Re: EFI Secure boot default keys
>>>
>>> On Wed, Jun 28, 2023 at 04:26:58PM +0000, Neil Jones wrote:
>>>> Please can someone describe the format of the file needed for the default / built-in EFI secure boot keys (ubootefi.var)
>>>>
>>>> The only docs I have found suggest its best to enroll the keys from within u-boot onto some removable media, then copy this off and use this as the default, this is not very helpful and doesn't work for me:
>>>>
>>>> => fatload mmc 0:1 ${loadaddr} PK.aut
>>>> 2053 bytes read in 18 ms (111.3 KiB/s)
>>>> => setenv -e -nv -bs -rt -at -i ${loadaddr}:$filesize PK
>>>> setenv - set environment variables
>>>>
>>>> Usage:
>>>> setenv setenv [-f] name value ...
>>>> - [forcibly] set environment variable 'name' to 'value ...'
>>>> setenv [-f] name
>>>> - [forcibly] delete environment variable 'name'
>>>>
>>>> my setenv doesn't support all the extra switches ? This is with 2022.04, all other EFI options seem to be in this release and I can boot unsigned EFI images ok.
>>>
>>> Please turn on CONFIG_CMD_NVEDIT_EFI when building your U-Boot.
>>>
>>> This option was disabled by the commit:
>>> commit 3b728f8728fa (tag: efi-2020-01-rc1)
>>> Author: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>> Date: Sun Oct 6 15:44:22 2019 +0200
>>>
>>> cmd: disable CMD_NVEDIT_EFI by default
>>>
>>> The binary size of efi has grown much since in the past, though.
>>>
>>> -Takahiro Akashi
>>>
>>>> Cheers,
>>>>
>>>> Neil
>>>>
>>>>
>>>>
More information about the U-Boot
mailing list