From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Neil Jones <neil.jones@blaize.com>
Cc: xypron.glpk@gmx.de, "u-boot@lists.denx.de" <u-boot@lists.denx.de>
Subject: Re: EFI Secure boot default keys
Date: Thu, 6 Jul 2023 10:38:12 +0900 [thread overview]
Message-ID: <ZKYbBBNR_dDdF4bD@laputa> (raw)
In-Reply-To: <MAZPR01MB6847BF1F949A6F3EA55BE3D5F12FA@MAZPR01MB6847.INDPRD01.PROD.OUTLOOK.COM>
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.glpk@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.akashi@linaro.org>
> Sent: 29 June 2023 02:01
> To: Neil Jones <neil.jones@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.glpk@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
> >
> >
> >
next prev parent reply other threads:[~2023-07-06 1:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 16:26 EFI Secure boot default keys Neil Jones
2023-06-29 1:01 ` AKASHI Takahiro
2023-07-05 13:24 ` Neil Jones
2023-07-06 1:38 ` AKASHI Takahiro [this message]
2023-07-06 8:23 ` Neil Jones
2023-07-06 9:25 ` AKASHI Takahiro
2023-07-06 15:22 ` Heinrich Schuchardt
2023-07-06 18:02 ` Heinrich Schuchardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZKYbBBNR_dDdF4bD@laputa \
--to=takahiro.akashi@linaro.org \
--cc=neil.jones@blaize.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.