Hi,

On Wed, Jul 05, 2023 at 01:24:32PM +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.g...@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

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

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.aka...@linaro.org>
> Sent: 29 June 2023 02:01
> To: Neil Jones <neil.jo...@blaize.com>
> Cc: u-boot@lists.denx.de <u-boot@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.g...@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
> >
> >
> >

Reply via email to