mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-09-21 07:01:57 +00:00
doc/efi: rework secure boot description
Ensure a uniform formatting. Some rephrasing. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This commit is contained in:
Heinrich Schuchardt
parent
11078bb262
commit
788bd90bf8
1 changed files with 62 additions and 48 deletions
|
|
@ -100,47 +100,57 @@ See doc/uImage.FIT/howto.txt for an introduction to FIT images.
|
|||
Configuring UEFI secure boot
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
UEFI specification[1] defines a secure way of executing UEFI images
|
||||
The UEFI specification[1] defines a secure way of executing UEFI images
|
||||
by verifying a signature (or message digest) of image with certificates.
|
||||
This feature on U-Boot is enabled with::
|
||||
|
||||
CONFIG_UEFI_SECURE_BOOT=y
|
||||
|
||||
To make the boot sequence safe, you need to establish a chain of trust;
|
||||
In UEFI secure boot, you can make it with the UEFI variables, "PK"
|
||||
(Platform Key), "KEK" (Key Exchange Keys), "db" (white list database)
|
||||
and "dbx" (black list database).
|
||||
In UEFI secure boot the chain trust is defined by the following UEFI variables
|
||||
|
||||
There are many online documents that describe what UEFI secure boot is
|
||||
and how it works. Please consult some of them for details.
|
||||
* PK - Platform Key
|
||||
* KEK - Key Exchange Keys
|
||||
* db - white list database
|
||||
* dbx - black list database
|
||||
|
||||
Here is a simple example that you can follow for your initial attempt
|
||||
(Please note that the actual steps would absolutely depend on your system
|
||||
and environment.):
|
||||
An in depth description of UEFI secure boot is beyond the scope of this
|
||||
document. Please, refer to the UEFI specification and available online
|
||||
documentation. Here is a simple example that you can follow for your initial
|
||||
attempt (Please note that the actual steps will depend on your system and
|
||||
environment.):
|
||||
|
||||
Install the required tools on your host
|
||||
|
||||
1. Install utility commands on your host
|
||||
* openssl
|
||||
* efitools
|
||||
* sbsigntool
|
||||
|
||||
2. Create signing keys and key database files on your host
|
||||
for PK::
|
||||
Create signing keys and the key database on your host:
|
||||
|
||||
$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \
|
||||
The platform key
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_PK/ \
|
||||
-keyout PK.key -out PK.crt -nodes -days 365
|
||||
$ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
|
||||
cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
|
||||
PK.crt PK.esl;
|
||||
$ sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
|
||||
sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl PK.auth
|
||||
|
||||
for KEK::
|
||||
The key exchange keys
|
||||
|
||||
$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \
|
||||
.. code-block:: bash
|
||||
|
||||
openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_KEK/ \
|
||||
-keyout KEK.key -out KEK.crt -nodes -days 365
|
||||
$ cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
|
||||
cert-to-efi-sig-list -g 11111111-2222-3333-4444-123456789abc \
|
||||
KEK.crt KEK.esl
|
||||
$ sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
|
||||
sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl KEK.auth
|
||||
|
||||
for db::
|
||||
The whitelist database
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_db/ \
|
||||
-keyout db.key -out db.crt -nodes -days 365
|
||||
|
|
@ -148,31 +158,35 @@ and environment.):
|
|||
db.crt db.esl
|
||||
$ sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl db.auth
|
||||
|
||||
Copy \*.auth to media, say mmc, that is accessible from U-Boot.
|
||||
Copy the \*.auth files to media, say mmc, that is accessible from U-Boot.
|
||||
|
||||
3. Sign an image with one key in "db" on your host::
|
||||
Sign an image with one of the keys in "db" on your host
|
||||
|
||||
$ sbsign --key db.key --cert db.crt helloworld.efi
|
||||
.. code-block:: bash
|
||||
|
||||
4. Install keys on your board::
|
||||
sbsign --key db.key --cert db.crt helloworld.efi
|
||||
|
||||
==> 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
|
||||
Now in U-Boot install the keys on your board::
|
||||
|
||||
5. Set up boot parameters 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
|
||||
|
||||
==> efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed ""
|
||||
Set up boot parameters on your board::
|
||||
|
||||
Then your board runs that image from Boot manager (See below).
|
||||
efidebug boot add 1 HELLO mmc 0:1 /helloworld.efi.signed ""
|
||||
|
||||
Now your board can run the signed image via the boot manager (see below).
|
||||
You can also try this sequence by running Pytest, test_efi_secboot,
|
||||
on sandbox::
|
||||
on the sandbox
|
||||
|
||||
$ cd <U-Boot source directory>
|
||||
$ pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
|
||||
.. code-block:: bash
|
||||
|
||||
cd <U-Boot source directory>
|
||||
pytest.py test/py/tests/test_efi_secboot/test_signed.py --bd sandbox
|
||||
|
||||
Executing the boot manager
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
Loading…
Reference in a new issue