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