EFI: update the documentation to correctly order loading SB keys

From: Luca Boccassi <bluca@debian.org>

Loading the PK locks down the EFI variables, so it needs to be done last.
Fix the order in the documentation and add a note.

Signed-off-by: Luca Boccassi <bluca@debian.org>
---
 doc/develop/uefi/uefi.rst | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

On Fri, Nov 25, 2022 at 01:30:11PM +0000, luca.boccassi@gmail.com wrote:
> From: Luca Boccassi <bluca@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@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.

-Takahiro Akashi

>  Set up boot parameters on your board::
>  
> -- 
> 2.34.1
>

On Mon, 28 Nov 2022 at 00:45, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
>
> On Fri, Nov 25, 2022 at 01:30:11PM +0000, luca.boccassi@gmail.com wrote:
> > From: Luca Boccassi <bluca@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@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

On Mon, Nov 28, 2022 at 01:27:53AM +0000, Luca Boccassi wrote:
> On Mon, 28 Nov 2022 at 00:45, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > On Fri, Nov 25, 2022 at 01:30:11PM +0000, luca.boccassi@gmail.com wrote:
> > > From: Luca Boccassi <bluca@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@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...

I re-ran my test_efi_secboot test on v2022.10 with sandbox_defconfig
and didn't see any error.
(Test case 1 verified that we could install PK, KEK and db
in this order.)

If you see this kind of error, it's likely that you have
wrong configuration.
If you're not sure, please describe what you did and saw
in details.

-Takahiro Akashi


> Kind regards,
> Luca Boccassi