[PATCH] 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(-)
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.
Set up boot parameters on your board::
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
participants (3)
-
AKASHI Takahiro -
Luca Boccassi -
luca.boccassi＠gmail.com