[PATCH] EFI: update the documentation to correctly order loading SB keys

[Luca Boccassi]

On Mon, 28 Nov 2022 at 00:45, AKASHI Takahiro
<takahiro.akashi at linaro.org> wrote:
>
> On Fri, Nov 25, 2022 at 01:30:11PM +0000, luca.boccassi at gmail.com wrote:
> > From: Luca Boccassi <bluca at debian.org>
> >
> > Loading the PK locks down the EFI variables, so it needs to be done last.
>
> No, it's not (always) correct.
>
> > Fix the order in the documentation and add a note.
> >
> > Signed-off-by: Luca Boccassi <bluca at debian.org>
> > ---
> >  doc/develop/uefi/uefi.rst | 12 ++++++++----
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > index e0835beba4..68a0bb6832 100644
> > --- a/doc/develop/uefi/uefi.rst
> > +++ b/doc/develop/uefi/uefi.rst
> > @@ -169,12 +169,16 @@ Sign an image with one of the keys in "db" on your host
> >
> >  Now in U-Boot install the keys on your board::
> >
> > -    fatload mmc 0:1 <tmpaddr> PK.auth
> > -    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK
> > -    fatload mmc 0:1 <tmpaddr> KEK.auth
> > -    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK
> >      fatload mmc 0:1 <tmpaddr> db.auth
> >      setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize db
> > +    fatload mmc 0:1 <tmpaddr> KEK.auth
> > +    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize KEK
> > +    fatload mmc 0:1 <tmpaddr> PK.auth
> > +    setenv -e -nv -bs -rt -at -i <tmpaddr>:$filesize PK
> > +
> > +Note that loading a key into PK automatically enables Secure Boot, and further
> > +unsigned updates of secure EFI variables will no longer be allowed, so PK should
> > +be loaded last.
>
> KEK.auth and db.auth are created by sign-efi-sig-list command
> (with valid keys) and contain authentication headers necessary
> for signature verification.
> So the original sequence works perfectly.

In theory. In practice u-boot (both 2022.07 and 2022.10 in qemu)
refused to allow setting those variables after PK is set, which made
me waste an unnecessary amount of time. Otherwise I wouldn't have
bothered sending this...

Kind regards,
Luca Boccassi