[U-Boot,v2,00/16] efi_loader: add secure boot support
mbox series

Message ID 20191126005120.31156-1-takahiro.akashi@linaro.org
Headers show
Series
  • efi_loader: add secure boot support
Related show

Message

AKASHI Takahiro Nov. 26, 2019, 12:51 a.m. UTC
One of major missing features in current UEFI implementation is "secure boot."
The ultimate goal of my attempt is to implement image authentication based
on signature and provide UEFI secure boot support which would be fully
compliant with UEFI specification, section 32[1].
(The code was originally developed by Patrick Wildt.)

While this patch/RFC is still rough-edged, the aim here is to get early
feedbacks from the community as the patch is quite huge (in total) and also
as it's a security enhancement.

Please note, however, this patch doesn't work on its own; there are
a couple of functional dependencies[2] and [3], that I have submitted
before. For complete workable patch set, see my repository[4],
which also contains exeperimental timestamp-based revocation suuport.

My "non-volatile" support[5], which is under discussion, is not mandatory
and so not included here, but this inevitably implies that, for example,
signature database variables, like db and dbx, won't be persistent unless you
explicitly run "env save" command and that UEFI variables are not separated
from U-Boot environment. Anyhow, Linaro is also working on implementing
real "secure storage" solution based on TF-A and OP-TEE.


Supported features:
* image authentication based on db and dbx
* supported signature types are
    EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images)
    EFI_CERT_X509_GUID (x509 certificate for signed images)
* SecureBoot/SignatureSupport variables
* SetupMode and user mode
* variable authentication based on PK and KEK
    EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
* basic pytest test cases

Unsupported features: (marked as TODO in most cases in the source code,
			and won't be included in this series)
* hash algorithms other than SHA256
* dbt: timestamp(RFC6131)-based certificate revocation
* dbr: OS recovery 
* xxxDefault: default values for signature stores
* transition to AuditMode and DeployedMode
* recording rejected images in EFI_IMAGE_EXECUTION_INFO_TABLE
* verification "policy", in particular, check against signature's owner
* private authenticated variables
* variable authentication with EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS
* real secure storage support, including hardware-specific PK (Platform Key)
  installation

TODO's other than "Unsupported features": (won't be included in this series)
* struct efi_image_regions cannot have arbitrary number of regions
* fail recovery, in particular, in modifying authenticated variables
* support read-only attributes of well-defined global variables
  in particular, "SignatureSupport"
* Extensive test suite (or more test cases) to confirm compatibility
  with EDK2
	=> I requested EDK SCT community to add tests[6].

Test:
* my pytest, included in this patch set, passed.
* efi_selftest passed. (At least no reguression.)
* Travis CI tests, except the following two, have passed:
  - test/py sandbox
    test/py/tests/test_fs/test_unlink.py test_unlink2
  - test/py sandbox with clang
    cmd/efidebug.c:703:15: error: result of comparison of constant 
    9223372036854775822 with expression of type 'int' is always false 
    [-Werror,-Wtautological-constant-out-of-range-compare]
  But as you can see, those have nothing to do with my UEFI secure boot
  patch and are existing bugs.

Known issues:
* efitools is used in pytest, and its version must be v1.5.2 or later.
  (Solution: You can define EFITOOLS_PATH in defs.py for your own efitools.)
* Pytest depends on standalone "helloworld" app for sandbox
  (Solution: You can define HELLO_PATH in defs.py or Heinrich's [7].)
* Travis CI errors mentioned above
        => I will send *separate* bug-fix patches once fixed.


Hints about how to use:
(Please see other documents, or my pytest scripts, for details.)
* You can create your own certificates with openssl.
* You can sign your application with sbsign (on Ubuntu).
* You can create raw data for signature database with efitools, and
  install/manage authenticated variables with "env -set -e" command
  or efitools' "UpdateVars.efi" application.


[1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
[2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html
    (import x509/pkcs7 parsers from linux)
[3] https://lists.denx.de/pipermail/u-boot/2019-November/390150.html
    (extend rsa_verify() for UEFI secure boot)
[4] http://git.linaro.org/people/takahiro.akashi/u-boot.git/ efi/secboot
[5] https://lists.denx.de/pipermail/u-boot/2019-September/382835.html
    (non-volatile variables support)
[6] https://bugzilla.tianocore.org/show_bug.cgi?id=2230
[7] https://lists.denx.de/pipermail/u-boot/2019-November/389593.html


Changes in v2 (Nov 26, 2019)
* rebased to v2020.01-rc3
* rename IMAGE_DIRECTORY_ENTRY_CERTTABLE to IMAGE_DIRECTORY_ENTRY_SECURITY
  (patch#1,#9)
* add comments (patch#1)
* drop v1's patch#2 as it is no longer necessary
* drop v1's patch#3 as other "SECURE_BOOT" architectures have renamed
  this option and no longer use it
* add structure descriptions (patch#3)
* rework hash calculation code in efi_signature_verify() and remove
  an odd constant, WinIndrectSha256 (patch#3)
* move travis.yml changes to a seprate patch (patch#12, #16)
* yield_fixture() -> fixture() (patch#12)
* call console.restart_uboot() at every test case (13,#14)
* add patch#15; enable UEFI-related configurations by default on sandbox
* add patch#16; modify Travis CI environment to run UEFI secure boot test

Changes in v1 (Nov 13, 2019)
* rebased to v2020.01-rc
* remove already-merged patches
* re-work the patch set for easier reviews, including
  - move a config definition patch forward (patch#4)
  - refactor/rename verification functions (patch#5/#10)
  - split signature database parser as a separate patch (patch#6)
  - split secure state transition code as a separate patch (patch#8)
  - move most part of init_secure_boot() into init_variables() (patch#8)
  - split test environment setup from test patches (patch#14)
* add function descriptions (patch#5-#11)
* make sure the section list is sorted in ascending order in hash
  calculation of PE image (patch#10)
* add a new "-at" (authenticated access) option to "env -e" (patch#13)
* list required host packages, in particular udisks2, in pytest
  (patch#14)
* modify conftest.py to run under python3 (patch#14)
* use a partition on a disk instead of a whole disk without partition
  table (patch#14)
* reduce depencendy on efitools, yet relying on its host tools (patch#14)
* modify pytests to catch up wth latest changes of "env -e" syntax
  (patch#15,#16)

RFC (Sept 18, 2019)

AKASHI Takahiro (16):
  include: pe.h: add signature-related definitions
  efi_loader: add CONFIG_EFI_SECURE_BOOT config option
  efi_loader: add signature verification functions
  efi_loader: add signature database parser
  efi_loader: variable: support variable authentication
  efi_loader: variable: add secure boot state transition
  efi_loader: variable: add VendorKeys variable
  efi_loader: image_loader: support image authentication
  efi_loader: set up secure boot
  cmd: env: use appropriate guid for authenticated UEFI variable
  cmd: env: add "-at" option to "env set -e" command
  efi_loader, pytest: set up secure boot environment
  efi_loader, pytest: add UEFI secure boot tests (authenticated
    variables)
  efi_loader, pytest: add UEFI secure boot tests (image)
  sandbox: add extra configurations for UEFI and related tests
  travis: add packages for UEFI secure boot test

 .travis.yml                                   |  11 +-
 cmd/nvedit.c                                  |   5 +-
 cmd/nvedit_efi.c                              |  23 +-
 configs/sandbox64_defconfig                   |   3 +
 configs/sandbox_defconfig                     |   3 +
 include/efi_api.h                             |  87 ++
 include/efi_loader.h                          |  85 +-
 include/pe.h                                  |  18 +
 lib/efi_loader/Kconfig                        |  16 +
 lib/efi_loader/Makefile                       |   1 +
 lib/efi_loader/efi_boottime.c                 |   2 +-
 lib/efi_loader/efi_image_loader.c             | 443 +++++++-
 lib/efi_loader/efi_setup.c                    |  38 +
 lib/efi_loader/efi_signature.c                | 811 +++++++++++++++
 lib/efi_loader/efi_variable.c                 | 950 ++++++++++++++++--
 test/py/README.md                             |   8 +
 test/py/tests/test_efi_secboot/conftest.py    | 151 +++
 test/py/tests/test_efi_secboot/defs.py        |  21 +
 .../py/tests/test_efi_secboot/test_authvar.py | 282 ++++++
 test/py/tests/test_efi_secboot/test_signed.py |  99 ++
 .../tests/test_efi_secboot/test_unsigned.py   | 103 ++
 21 files changed, 3032 insertions(+), 128 deletions(-)
 create mode 100644 lib/efi_loader/efi_signature.c
 create mode 100644 test/py/tests/test_efi_secboot/conftest.py
 create mode 100644 test/py/tests/test_efi_secboot/defs.py
 create mode 100644 test/py/tests/test_efi_secboot/test_authvar.py
 create mode 100644 test/py/tests/test_efi_secboot/test_signed.py
 create mode 100644 test/py/tests/test_efi_secboot/test_unsigned.py

Comments

AKASHI Takahiro Nov. 26, 2019, 1:23 a.m. UTC | #1
Some updates,

On Tue, Nov 26, 2019 at 09:51:04AM +0900, AKASHI Takahiro wrote:
> One of major missing features in current UEFI implementation is "secure boot."
> The ultimate goal of my attempt is to implement image authentication based
> on signature and provide UEFI secure boot support which would be fully
> compliant with UEFI specification, section 32[1].
> (The code was originally developed by Patrick Wildt.)
> 
> While this patch/RFC is still rough-edged, the aim here is to get early
> feedbacks from the community as the patch is quite huge (in total) and also
> as it's a security enhancement.

Oops, this sentence should have been deleted.

[...]

> Test:
> * my pytest, included in this patch set, passed.
> * efi_selftest passed. (At least no reguression.)
> * Travis CI tests, except the following two, have passed:
>   - test/py sandbox
>     test/py/tests/test_fs/test_unlink.py test_unlink2

I cannot reproduce this issue even if I re-submit a specific job.
It may be a transient error as Heinrich has reported on fat write before?

>   - test/py sandbox with clang
>     cmd/efidebug.c:703:15: error: result of comparison of constant 
>     9223372036854775822 with expression of type 'int' is always false 
>     [-Werror,-Wtautological-constant-out-of-range-compare]

Sent out a patch.

Thanks,
-Takahiro Akashi

>   But as you can see, those have nothing to do with my UEFI secure boot
>   patch and are existing bugs.
> 
> Known issues:
> * efitools is used in pytest, and its version must be v1.5.2 or later.
>   (Solution: You can define EFITOOLS_PATH in defs.py for your own efitools.)
> * Pytest depends on standalone "helloworld" app for sandbox
>   (Solution: You can define HELLO_PATH in defs.py or Heinrich's [7].)
> * Travis CI errors mentioned above
>         => I will send *separate* bug-fix patches once fixed.
> 
> 
> Hints about how to use:
> (Please see other documents, or my pytest scripts, for details.)
> * You can create your own certificates with openssl.
> * You can sign your application with sbsign (on Ubuntu).
> * You can create raw data for signature database with efitools, and
>   install/manage authenticated variables with "env -set -e" command
>   or efitools' "UpdateVars.efi" application.
> 
> 
> [1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
> [2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html
>     (import x509/pkcs7 parsers from linux)
> [3] https://lists.denx.de/pipermail/u-boot/2019-November/390150.html
>     (extend rsa_verify() for UEFI secure boot)
> [4] http://git.linaro.org/people/takahiro.akashi/u-boot.git/ efi/secboot
> [5] https://lists.denx.de/pipermail/u-boot/2019-September/382835.html
>     (non-volatile variables support)
> [6] https://bugzilla.tianocore.org/show_bug.cgi?id=2230
> [7] https://lists.denx.de/pipermail/u-boot/2019-November/389593.html
> 
> 
> Changes in v2 (Nov 26, 2019)
> * rebased to v2020.01-rc3
> * rename IMAGE_DIRECTORY_ENTRY_CERTTABLE to IMAGE_DIRECTORY_ENTRY_SECURITY
>   (patch#1,#9)
> * add comments (patch#1)
> * drop v1's patch#2 as it is no longer necessary
> * drop v1's patch#3 as other "SECURE_BOOT" architectures have renamed
>   this option and no longer use it
> * add structure descriptions (patch#3)
> * rework hash calculation code in efi_signature_verify() and remove
>   an odd constant, WinIndrectSha256 (patch#3)
> * move travis.yml changes to a seprate patch (patch#12, #16)
> * yield_fixture() -> fixture() (patch#12)
> * call console.restart_uboot() at every test case (13,#14)
> * add patch#15; enable UEFI-related configurations by default on sandbox
> * add patch#16; modify Travis CI environment to run UEFI secure boot test
> 
> Changes in v1 (Nov 13, 2019)
> * rebased to v2020.01-rc
> * remove already-merged patches
> * re-work the patch set for easier reviews, including
>   - move a config definition patch forward (patch#4)
>   - refactor/rename verification functions (patch#5/#10)
>   - split signature database parser as a separate patch (patch#6)
>   - split secure state transition code as a separate patch (patch#8)
>   - move most part of init_secure_boot() into init_variables() (patch#8)
>   - split test environment setup from test patches (patch#14)
> * add function descriptions (patch#5-#11)
> * make sure the section list is sorted in ascending order in hash
>   calculation of PE image (patch#10)
> * add a new "-at" (authenticated access) option to "env -e" (patch#13)
> * list required host packages, in particular udisks2, in pytest
>   (patch#14)
> * modify conftest.py to run under python3 (patch#14)
> * use a partition on a disk instead of a whole disk without partition
>   table (patch#14)
> * reduce depencendy on efitools, yet relying on its host tools (patch#14)
> * modify pytests to catch up wth latest changes of "env -e" syntax
>   (patch#15,#16)
> 
> RFC (Sept 18, 2019)
> 
> AKASHI Takahiro (16):
>   include: pe.h: add signature-related definitions
>   efi_loader: add CONFIG_EFI_SECURE_BOOT config option
>   efi_loader: add signature verification functions
>   efi_loader: add signature database parser
>   efi_loader: variable: support variable authentication
>   efi_loader: variable: add secure boot state transition
>   efi_loader: variable: add VendorKeys variable
>   efi_loader: image_loader: support image authentication
>   efi_loader: set up secure boot
>   cmd: env: use appropriate guid for authenticated UEFI variable
>   cmd: env: add "-at" option to "env set -e" command
>   efi_loader, pytest: set up secure boot environment
>   efi_loader, pytest: add UEFI secure boot tests (authenticated
>     variables)
>   efi_loader, pytest: add UEFI secure boot tests (image)
>   sandbox: add extra configurations for UEFI and related tests
>   travis: add packages for UEFI secure boot test
> 
>  .travis.yml                                   |  11 +-
>  cmd/nvedit.c                                  |   5 +-
>  cmd/nvedit_efi.c                              |  23 +-
>  configs/sandbox64_defconfig                   |   3 +
>  configs/sandbox_defconfig                     |   3 +
>  include/efi_api.h                             |  87 ++
>  include/efi_loader.h                          |  85 +-
>  include/pe.h                                  |  18 +
>  lib/efi_loader/Kconfig                        |  16 +
>  lib/efi_loader/Makefile                       |   1 +
>  lib/efi_loader/efi_boottime.c                 |   2 +-
>  lib/efi_loader/efi_image_loader.c             | 443 +++++++-
>  lib/efi_loader/efi_setup.c                    |  38 +
>  lib/efi_loader/efi_signature.c                | 811 +++++++++++++++
>  lib/efi_loader/efi_variable.c                 | 950 ++++++++++++++++--
>  test/py/README.md                             |   8 +
>  test/py/tests/test_efi_secboot/conftest.py    | 151 +++
>  test/py/tests/test_efi_secboot/defs.py        |  21 +
>  .../py/tests/test_efi_secboot/test_authvar.py | 282 ++++++
>  test/py/tests/test_efi_secboot/test_signed.py |  99 ++
>  .../tests/test_efi_secboot/test_unsigned.py   | 103 ++
>  21 files changed, 3032 insertions(+), 128 deletions(-)
>  create mode 100644 lib/efi_loader/efi_signature.c
>  create mode 100644 test/py/tests/test_efi_secboot/conftest.py
>  create mode 100644 test/py/tests/test_efi_secboot/defs.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_authvar.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_signed.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_unsigned.py
> 
> -- 
> 2.24.0
>
Ilias Apalodimas Nov. 28, 2019, 1:48 p.m. UTC | #2
On Tue, Nov 26, 2019 at 09:51:04AM +0900, AKASHI Takahiro wrote:
> One of major missing features in current UEFI implementation is "secure boot."
> The ultimate goal of my attempt is to implement image authentication based
> on signature and provide UEFI secure boot support which would be fully
> compliant with UEFI specification, section 32[1].
> (The code was originally developed by Patrick Wildt.)
> 
> While this patch/RFC is still rough-edged, the aim here is to get early
> feedbacks from the community as the patch is quite huge (in total) and also
> as it's a security enhancement.
> 
> Please note, however, this patch doesn't work on its own; there are
> a couple of functional dependencies[2] and [3], that I have submitted
> before. For complete workable patch set, see my repository[4],
> which also contains exeperimental timestamp-based revocation suuport.
> 
> My "non-volatile" support[5], which is under discussion, is not mandatory
> and so not included here, but this inevitably implies that, for example,
> signature database variables, like db and dbx, won't be persistent unless you
> explicitly run "env save" command and that UEFI variables are not separated
> from U-Boot environment. Anyhow, Linaro is also working on implementing
> real "secure storage" solution based on TF-A and OP-TEE.
> 
> 
> Supported features:
> * image authentication based on db and dbx
> * supported signature types are
>     EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images)
>     EFI_CERT_X509_GUID (x509 certificate for signed images)
> * SecureBoot/SignatureSupport variables
> * SetupMode and user mode
> * variable authentication based on PK and KEK
>     EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
> * basic pytest test cases
> 
> Unsupported features: (marked as TODO in most cases in the source code,
> 			and won't be included in this series)
> * hash algorithms other than SHA256
> * dbt: timestamp(RFC6131)-based certificate revocation
> * dbr: OS recovery 
> * xxxDefault: default values for signature stores
> * transition to AuditMode and DeployedMode
> * recording rejected images in EFI_IMAGE_EXECUTION_INFO_TABLE
> * verification "policy", in particular, check against signature's owner
> * private authenticated variables
> * variable authentication with EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS
> * real secure storage support, including hardware-specific PK (Platform Key)
>   installation
> 
> TODO's other than "Unsupported features": (won't be included in this series)
> * struct efi_image_regions cannot have arbitrary number of regions
> * fail recovery, in particular, in modifying authenticated variables
> * support read-only attributes of well-defined global variables
>   in particular, "SignatureSupport"
> * Extensive test suite (or more test cases) to confirm compatibility
>   with EDK2
> 	=> I requested EDK SCT community to add tests[6].
> 
> Test:
> * my pytest, included in this patch set, passed.
> * efi_selftest passed. (At least no reguression.)
> * Travis CI tests, except the following two, have passed:
>   - test/py sandbox
>     test/py/tests/test_fs/test_unlink.py test_unlink2
>   - test/py sandbox with clang
>     cmd/efidebug.c:703:15: error: result of comparison of constant 
>     9223372036854775822 with expression of type 'int' is always false 
>     [-Werror,-Wtautological-constant-out-of-range-compare]
>   But as you can see, those have nothing to do with my UEFI secure boot
>   patch and are existing bugs.
> 
> Known issues:
> * efitools is used in pytest, and its version must be v1.5.2 or later.
>   (Solution: You can define EFITOOLS_PATH in defs.py for your own efitools.)
> * Pytest depends on standalone "helloworld" app for sandbox
>   (Solution: You can define HELLO_PATH in defs.py or Heinrich's [7].)
> * Travis CI errors mentioned above
>         => I will send *separate* bug-fix patches once fixed.
> 
> 
> Hints about how to use:
> (Please see other documents, or my pytest scripts, for details.)
> * You can create your own certificates with openssl.
> * You can sign your application with sbsign (on Ubuntu).
> * You can create raw data for signature database with efitools, and
>   install/manage authenticated variables with "env -set -e" command
>   or efitools' "UpdateVars.efi" application.
> 
> 
> [1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
> [2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html
>     (import x509/pkcs7 parsers from linux)
> [3] https://lists.denx.de/pipermail/u-boot/2019-November/390150.html
>     (extend rsa_verify() for UEFI secure boot)
> [4] http://git.linaro.org/people/takahiro.akashi/u-boot.git/ efi/secboot
> [5] https://lists.denx.de/pipermail/u-boot/2019-September/382835.html
>     (non-volatile variables support)
> [6] https://bugzilla.tianocore.org/show_bug.cgi?id=2230
> [7] https://lists.denx.de/pipermail/u-boot/2019-November/389593.html
> 
> 
> Changes in v2 (Nov 26, 2019)
> * rebased to v2020.01-rc3
> * rename IMAGE_DIRECTORY_ENTRY_CERTTABLE to IMAGE_DIRECTORY_ENTRY_SECURITY
>   (patch#1,#9)
> * add comments (patch#1)
> * drop v1's patch#2 as it is no longer necessary
> * drop v1's patch#3 as other "SECURE_BOOT" architectures have renamed
>   this option and no longer use it
> * add structure descriptions (patch#3)
> * rework hash calculation code in efi_signature_verify() and remove
>   an odd constant, WinIndrectSha256 (patch#3)
> * move travis.yml changes to a seprate patch (patch#12, #16)
> * yield_fixture() -> fixture() (patch#12)
> * call console.restart_uboot() at every test case (13,#14)
> * add patch#15; enable UEFI-related configurations by default on sandbox
> * add patch#16; modify Travis CI environment to run UEFI secure boot test
> 
> Changes in v1 (Nov 13, 2019)
> * rebased to v2020.01-rc
> * remove already-merged patches
> * re-work the patch set for easier reviews, including
>   - move a config definition patch forward (patch#4)
>   - refactor/rename verification functions (patch#5/#10)
>   - split signature database parser as a separate patch (patch#6)
>   - split secure state transition code as a separate patch (patch#8)
>   - move most part of init_secure_boot() into init_variables() (patch#8)
>   - split test environment setup from test patches (patch#14)
> * add function descriptions (patch#5-#11)
> * make sure the section list is sorted in ascending order in hash
>   calculation of PE image (patch#10)
> * add a new "-at" (authenticated access) option to "env -e" (patch#13)
> * list required host packages, in particular udisks2, in pytest
>   (patch#14)
> * modify conftest.py to run under python3 (patch#14)
> * use a partition on a disk instead of a whole disk without partition
>   table (patch#14)
> * reduce depencendy on efitools, yet relying on its host tools (patch#14)
> * modify pytests to catch up wth latest changes of "env -e" syntax
>   (patch#15,#16)
> 
> RFC (Sept 18, 2019)
> 
> AKASHI Takahiro (16):
>   include: pe.h: add signature-related definitions
>   efi_loader: add CONFIG_EFI_SECURE_BOOT config option
>   efi_loader: add signature verification functions
>   efi_loader: add signature database parser
>   efi_loader: variable: support variable authentication
>   efi_loader: variable: add secure boot state transition
>   efi_loader: variable: add VendorKeys variable
>   efi_loader: image_loader: support image authentication
>   efi_loader: set up secure boot
>   cmd: env: use appropriate guid for authenticated UEFI variable
>   cmd: env: add "-at" option to "env set -e" command
>   efi_loader, pytest: set up secure boot environment
>   efi_loader, pytest: add UEFI secure boot tests (authenticated
>     variables)
>   efi_loader, pytest: add UEFI secure boot tests (image)
>   sandbox: add extra configurations for UEFI and related tests
>   travis: add packages for UEFI secure boot test
> 
>  .travis.yml                                   |  11 +-
>  cmd/nvedit.c                                  |   5 +-
>  cmd/nvedit_efi.c                              |  23 +-
>  configs/sandbox64_defconfig                   |   3 +
>  configs/sandbox_defconfig                     |   3 +
>  include/efi_api.h                             |  87 ++
>  include/efi_loader.h                          |  85 +-
>  include/pe.h                                  |  18 +
>  lib/efi_loader/Kconfig                        |  16 +
>  lib/efi_loader/Makefile                       |   1 +
>  lib/efi_loader/efi_boottime.c                 |   2 +-
>  lib/efi_loader/efi_image_loader.c             | 443 +++++++-
>  lib/efi_loader/efi_setup.c                    |  38 +
>  lib/efi_loader/efi_signature.c                | 811 +++++++++++++++
>  lib/efi_loader/efi_variable.c                 | 950 ++++++++++++++++--
>  test/py/README.md                             |   8 +
>  test/py/tests/test_efi_secboot/conftest.py    | 151 +++
>  test/py/tests/test_efi_secboot/defs.py        |  21 +
>  .../py/tests/test_efi_secboot/test_authvar.py | 282 ++++++
>  test/py/tests/test_efi_secboot/test_signed.py |  99 ++
>  .../tests/test_efi_secboot/test_unsigned.py   | 103 ++
>  21 files changed, 3032 insertions(+), 128 deletions(-)
>  create mode 100644 lib/efi_loader/efi_signature.c
>  create mode 100644 test/py/tests/test_efi_secboot/conftest.py
>  create mode 100644 test/py/tests/test_efi_secboot/defs.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_authvar.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_signed.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_unsigned.py
> 
> -- 
> 2.24.0
> 

I managed to test the functionality using SHA256 in 'db'. 
For that part 

Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
AKASHI Takahiro Dec. 4, 2019, 2:43 a.m. UTC | #3
Tom, Simon, Heinrich,

I have submitted three major patch sets for UEFI secure boot:
* x509/pkcs7 parser
* RSA library extension
* UEFI secure boot

I have no technical issues to fix now and have seen only a few minor
comments on them (if I confirm that you have no more comments,
I can submit new version almost immediately).
Considering those, can I expect that those patches be merged
in v2020.01?

If not, do you need to have more time for your reviewing?
What else do you expect from my side to accelerate the upstream?

Please let me know your review status and your expectation.
(I'm not pushing you, but just asking.)

Thanks,
-Takahiro Akashi

On Tue, Nov 26, 2019 at 09:51:04AM +0900, AKASHI Takahiro wrote:
> One of major missing features in current UEFI implementation is "secure boot."
> The ultimate goal of my attempt is to implement image authentication based
> on signature and provide UEFI secure boot support which would be fully
> compliant with UEFI specification, section 32[1].
> (The code was originally developed by Patrick Wildt.)
> 
> While this patch/RFC is still rough-edged, the aim here is to get early
> feedbacks from the community as the patch is quite huge (in total) and also
> as it's a security enhancement.
> 
> Please note, however, this patch doesn't work on its own; there are
> a couple of functional dependencies[2] and [3], that I have submitted
> before. For complete workable patch set, see my repository[4],
> which also contains exeperimental timestamp-based revocation suuport.
> 
> My "non-volatile" support[5], which is under discussion, is not mandatory
> and so not included here, but this inevitably implies that, for example,
> signature database variables, like db and dbx, won't be persistent unless you
> explicitly run "env save" command and that UEFI variables are not separated
> from U-Boot environment. Anyhow, Linaro is also working on implementing
> real "secure storage" solution based on TF-A and OP-TEE.
> 
> 
> Supported features:
> * image authentication based on db and dbx
> * supported signature types are
>     EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images)
>     EFI_CERT_X509_GUID (x509 certificate for signed images)
> * SecureBoot/SignatureSupport variables
> * SetupMode and user mode
> * variable authentication based on PK and KEK
>     EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
> * basic pytest test cases
> 
> Unsupported features: (marked as TODO in most cases in the source code,
> 			and won't be included in this series)
> * hash algorithms other than SHA256
> * dbt: timestamp(RFC6131)-based certificate revocation
> * dbr: OS recovery 
> * xxxDefault: default values for signature stores
> * transition to AuditMode and DeployedMode
> * recording rejected images in EFI_IMAGE_EXECUTION_INFO_TABLE
> * verification "policy", in particular, check against signature's owner
> * private authenticated variables
> * variable authentication with EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS
> * real secure storage support, including hardware-specific PK (Platform Key)
>   installation
> 
> TODO's other than "Unsupported features": (won't be included in this series)
> * struct efi_image_regions cannot have arbitrary number of regions
> * fail recovery, in particular, in modifying authenticated variables
> * support read-only attributes of well-defined global variables
>   in particular, "SignatureSupport"
> * Extensive test suite (or more test cases) to confirm compatibility
>   with EDK2
> 	=> I requested EDK SCT community to add tests[6].
> 
> Test:
> * my pytest, included in this patch set, passed.
> * efi_selftest passed. (At least no reguression.)
> * Travis CI tests, except the following two, have passed:
>   - test/py sandbox
>     test/py/tests/test_fs/test_unlink.py test_unlink2
>   - test/py sandbox with clang
>     cmd/efidebug.c:703:15: error: result of comparison of constant 
>     9223372036854775822 with expression of type 'int' is always false 
>     [-Werror,-Wtautological-constant-out-of-range-compare]
>   But as you can see, those have nothing to do with my UEFI secure boot
>   patch and are existing bugs.
> 
> Known issues:
> * efitools is used in pytest, and its version must be v1.5.2 or later.
>   (Solution: You can define EFITOOLS_PATH in defs.py for your own efitools.)
> * Pytest depends on standalone "helloworld" app for sandbox
>   (Solution: You can define HELLO_PATH in defs.py or Heinrich's [7].)
> * Travis CI errors mentioned above
>         => I will send *separate* bug-fix patches once fixed.
> 
> 
> Hints about how to use:
> (Please see other documents, or my pytest scripts, for details.)
> * You can create your own certificates with openssl.
> * You can sign your application with sbsign (on Ubuntu).
> * You can create raw data for signature database with efitools, and
>   install/manage authenticated variables with "env -set -e" command
>   or efitools' "UpdateVars.efi" application.
> 
> 
> [1] https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
> [2] https://lists.denx.de/pipermail/u-boot/2019-November/390127.html
>     (import x509/pkcs7 parsers from linux)
> [3] https://lists.denx.de/pipermail/u-boot/2019-November/390150.html
>     (extend rsa_verify() for UEFI secure boot)
> [4] http://git.linaro.org/people/takahiro.akashi/u-boot.git/ efi/secboot
> [5] https://lists.denx.de/pipermail/u-boot/2019-September/382835.html
>     (non-volatile variables support)
> [6] https://bugzilla.tianocore.org/show_bug.cgi?id=2230
> [7] https://lists.denx.de/pipermail/u-boot/2019-November/389593.html
> 
> 
> Changes in v2 (Nov 26, 2019)
> * rebased to v2020.01-rc3
> * rename IMAGE_DIRECTORY_ENTRY_CERTTABLE to IMAGE_DIRECTORY_ENTRY_SECURITY
>   (patch#1,#9)
> * add comments (patch#1)
> * drop v1's patch#2 as it is no longer necessary
> * drop v1's patch#3 as other "SECURE_BOOT" architectures have renamed
>   this option and no longer use it
> * add structure descriptions (patch#3)
> * rework hash calculation code in efi_signature_verify() and remove
>   an odd constant, WinIndrectSha256 (patch#3)
> * move travis.yml changes to a seprate patch (patch#12, #16)
> * yield_fixture() -> fixture() (patch#12)
> * call console.restart_uboot() at every test case (13,#14)
> * add patch#15; enable UEFI-related configurations by default on sandbox
> * add patch#16; modify Travis CI environment to run UEFI secure boot test
> 
> Changes in v1 (Nov 13, 2019)
> * rebased to v2020.01-rc
> * remove already-merged patches
> * re-work the patch set for easier reviews, including
>   - move a config definition patch forward (patch#4)
>   - refactor/rename verification functions (patch#5/#10)
>   - split signature database parser as a separate patch (patch#6)
>   - split secure state transition code as a separate patch (patch#8)
>   - move most part of init_secure_boot() into init_variables() (patch#8)
>   - split test environment setup from test patches (patch#14)
> * add function descriptions (patch#5-#11)
> * make sure the section list is sorted in ascending order in hash
>   calculation of PE image (patch#10)
> * add a new "-at" (authenticated access) option to "env -e" (patch#13)
> * list required host packages, in particular udisks2, in pytest
>   (patch#14)
> * modify conftest.py to run under python3 (patch#14)
> * use a partition on a disk instead of a whole disk without partition
>   table (patch#14)
> * reduce depencendy on efitools, yet relying on its host tools (patch#14)
> * modify pytests to catch up wth latest changes of "env -e" syntax
>   (patch#15,#16)
> 
> RFC (Sept 18, 2019)
> 
> AKASHI Takahiro (16):
>   include: pe.h: add signature-related definitions
>   efi_loader: add CONFIG_EFI_SECURE_BOOT config option
>   efi_loader: add signature verification functions
>   efi_loader: add signature database parser
>   efi_loader: variable: support variable authentication
>   efi_loader: variable: add secure boot state transition
>   efi_loader: variable: add VendorKeys variable
>   efi_loader: image_loader: support image authentication
>   efi_loader: set up secure boot
>   cmd: env: use appropriate guid for authenticated UEFI variable
>   cmd: env: add "-at" option to "env set -e" command
>   efi_loader, pytest: set up secure boot environment
>   efi_loader, pytest: add UEFI secure boot tests (authenticated
>     variables)
>   efi_loader, pytest: add UEFI secure boot tests (image)
>   sandbox: add extra configurations for UEFI and related tests
>   travis: add packages for UEFI secure boot test
> 
>  .travis.yml                                   |  11 +-
>  cmd/nvedit.c                                  |   5 +-
>  cmd/nvedit_efi.c                              |  23 +-
>  configs/sandbox64_defconfig                   |   3 +
>  configs/sandbox_defconfig                     |   3 +
>  include/efi_api.h                             |  87 ++
>  include/efi_loader.h                          |  85 +-
>  include/pe.h                                  |  18 +
>  lib/efi_loader/Kconfig                        |  16 +
>  lib/efi_loader/Makefile                       |   1 +
>  lib/efi_loader/efi_boottime.c                 |   2 +-
>  lib/efi_loader/efi_image_loader.c             | 443 +++++++-
>  lib/efi_loader/efi_setup.c                    |  38 +
>  lib/efi_loader/efi_signature.c                | 811 +++++++++++++++
>  lib/efi_loader/efi_variable.c                 | 950 ++++++++++++++++--
>  test/py/README.md                             |   8 +
>  test/py/tests/test_efi_secboot/conftest.py    | 151 +++
>  test/py/tests/test_efi_secboot/defs.py        |  21 +
>  .../py/tests/test_efi_secboot/test_authvar.py | 282 ++++++
>  test/py/tests/test_efi_secboot/test_signed.py |  99 ++
>  .../tests/test_efi_secboot/test_unsigned.py   | 103 ++
>  21 files changed, 3032 insertions(+), 128 deletions(-)
>  create mode 100644 lib/efi_loader/efi_signature.c
>  create mode 100644 test/py/tests/test_efi_secboot/conftest.py
>  create mode 100644 test/py/tests/test_efi_secboot/defs.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_authvar.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_signed.py
>  create mode 100644 test/py/tests/test_efi_secboot/test_unsigned.py
> 
> -- 
> 2.24.0
>
Heinrich Schuchardt Dec. 4, 2019, 7:31 a.m. UTC | #4
On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> Tom, Simon, Heinrich,
>
> I have submitted three major patch sets for UEFI secure boot:
> * x509/pkcs7 parser
> * RSA library extension
> * UEFI secure boot
>
> I have no technical issues to fix now and have seen only a few minor
> comments on them (if I confirm that you have no more comments,
> I can submit new version almost immediately).
> Considering those, can I expect that those patches be merged
> in v2020.01?
>
> If not, do you need to have more time for your reviewing?
> What else do you expect from my side to accelerate the upstream?

We are reaching the end of the release cycle. So do not expect any of
these patch series to be merged in v2020.01.
cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle

To my understanding the UEFI secure boot series depends on the other two
so it must be merged last.

Best regards

Heinrich
AKASHI Takahiro Dec. 4, 2019, 8:28 a.m. UTC | #5
On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> >Tom, Simon, Heinrich,
> >
> >I have submitted three major patch sets for UEFI secure boot:
> >* x509/pkcs7 parser
> >* RSA library extension
> >* UEFI secure boot
> >
> >I have no technical issues to fix now and have seen only a few minor
> >comments on them (if I confirm that you have no more comments,
> >I can submit new version almost immediately).
> >Considering those, can I expect that those patches be merged
> >in v2020.01?
> >
> >If not, do you need to have more time for your reviewing?
> >What else do you expect from my side to accelerate the upstream?
> 
> We are reaching the end of the release cycle. So do not expect any of
> these patch series to be merged in v2020.01.
> cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle

I have often seen several patches (not bug fix) merged
even after "merge window".
Anyway,

> To my understanding the UEFI secure boot series depends on the other two
> so it must be merged last.

So once the first two patch set are accepted by the maintainers,
do you agree to merging the third one (i.e. secure boot patch itself)
promptly?
        -> Heinrich

As I said, I have had no technical issues on the first two patches
and haven't heard any comments/objections from the maintainers so far.
Are you willing to accept them for the next release?
        -> Tom, Simon

Thanks,
-Takahiro Akashi

> 
> Heinrich
Tom Rini Dec. 4, 2019, 11:58 p.m. UTC | #6
On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote:
> On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> > On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> > >Tom, Simon, Heinrich,
> > >
> > >I have submitted three major patch sets for UEFI secure boot:
> > >* x509/pkcs7 parser
> > >* RSA library extension
> > >* UEFI secure boot
> > >
> > >I have no technical issues to fix now and have seen only a few minor
> > >comments on them (if I confirm that you have no more comments,
> > >I can submit new version almost immediately).
> > >Considering those, can I expect that those patches be merged
> > >in v2020.01?
> > >
> > >If not, do you need to have more time for your reviewing?
> > >What else do you expect from my side to accelerate the upstream?
> > 
> > We are reaching the end of the release cycle. So do not expect any of
> > these patch series to be merged in v2020.01.
> > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle
> 
> I have often seen several patches (not bug fix) merged
> even after "merge window".
> Anyway,

Please keep pushing back on me when you see "large" changes go in later
than probably should.  I try and hold to what I say, but I don't always
make it.

> > To my understanding the UEFI secure boot series depends on the other two
> > so it must be merged last.
> 
> So once the first two patch set are accepted by the maintainers,
> do you agree to merging the third one (i.e. secure boot patch itself)
> promptly?
>         -> Heinrich
> 
> As I said, I have had no technical issues on the first two patches
> and haven't heard any comments/objections from the maintainers so far.
> Are you willing to accept them for the next release?
>         -> Tom, Simon

My hope is to put some of this in to -next and see what comes out.  As I
send this I'm doing what I hope will be a last test of the MTD clean up
series, which has been what's eating all of my "try something" cycles
since the end of Oct.
AKASHI Takahiro Dec. 11, 2019, 12:41 a.m. UTC | #7
Simon,

On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote:
> On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> > On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> > >Tom, Simon, Heinrich,
> > >
> > >I have submitted three major patch sets for UEFI secure boot:
> > >* x509/pkcs7 parser
> > >* RSA library extension
> > >* UEFI secure boot
> > >
> > >I have no technical issues to fix now and have seen only a few minor
> > >comments on them (if I confirm that you have no more comments,
> > >I can submit new version almost immediately).
> > >Considering those, can I expect that those patches be merged
> > >in v2020.01?
> > >
> > >If not, do you need to have more time for your reviewing?
> > >What else do you expect from my side to accelerate the upstream?
> > 
> > We are reaching the end of the release cycle. So do not expect any of
> > these patch series to be merged in v2020.01.
> > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle
> 
> I have often seen several patches (not bug fix) merged
> even after "merge window".
> Anyway,
> 
> > To my understanding the UEFI secure boot series depends on the other two
> > so it must be merged last.
> 
> So once the first two patch set are accepted by the maintainers,
> do you agree to merging the third one (i.e. secure boot patch itself)
> promptly?
>         -> Heinrich
> 
> As I said, I have had no technical issues on the first two patches
> and haven't heard any comments/objections from the maintainers so far.
> Are you willing to accept them for the next release?
>         -> Tom, Simon

Can you confirm that you have queued my "RSA library extension" patch
in your -next(?) branch, please?

-Takahiro Akashi


> Thanks,
> -Takahiro Akashi
> 
> > 
> > Heinrich
Tom Rini Dec. 11, 2019, 1:54 a.m. UTC | #8
On Wed, Dec 11, 2019 at 09:41:56AM +0900, AKASHI Takahiro wrote:
> Simon,
> 
> On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote:
> > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> > > >Tom, Simon, Heinrich,
> > > >
> > > >I have submitted three major patch sets for UEFI secure boot:
> > > >* x509/pkcs7 parser
> > > >* RSA library extension
> > > >* UEFI secure boot
> > > >
> > > >I have no technical issues to fix now and have seen only a few minor
> > > >comments on them (if I confirm that you have no more comments,
> > > >I can submit new version almost immediately).
> > > >Considering those, can I expect that those patches be merged
> > > >in v2020.01?
> > > >
> > > >If not, do you need to have more time for your reviewing?
> > > >What else do you expect from my side to accelerate the upstream?
> > > 
> > > We are reaching the end of the release cycle. So do not expect any of
> > > these patch series to be merged in v2020.01.
> > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle
> > 
> > I have often seen several patches (not bug fix) merged
> > even after "merge window".
> > Anyway,
> > 
> > > To my understanding the UEFI secure boot series depends on the other two
> > > so it must be merged last.
> > 
> > So once the first two patch set are accepted by the maintainers,
> > do you agree to merging the third one (i.e. secure boot patch itself)
> > promptly?
> >         -> Heinrich
> > 
> > As I said, I have had no technical issues on the first two patches
> > and haven't heard any comments/objections from the maintainers so far.
> > Are you willing to accept them for the next release?
> >         -> Tom, Simon
> 
> Can you confirm that you have queued my "RSA library extension" patch
> in your -next(?) branch, please?

Please note that I raised a concern with the RSA patch series that needs
to be addressed.  There's unexplained / unexpected size growth on
platforms that aren't otherwise enabling new features.  Thanks!
AKASHI Takahiro Dec. 11, 2019, 2:10 a.m. UTC | #9
On Tue, Dec 10, 2019 at 08:54:12PM -0500, Tom Rini wrote:
> On Wed, Dec 11, 2019 at 09:41:56AM +0900, AKASHI Takahiro wrote:
> > Simon,
> > 
> > On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote:
> > > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> > > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> > > > >Tom, Simon, Heinrich,
> > > > >
> > > > >I have submitted three major patch sets for UEFI secure boot:
> > > > >* x509/pkcs7 parser
> > > > >* RSA library extension
> > > > >* UEFI secure boot
> > > > >
> > > > >I have no technical issues to fix now and have seen only a few minor
> > > > >comments on them (if I confirm that you have no more comments,
> > > > >I can submit new version almost immediately).
> > > > >Considering those, can I expect that those patches be merged
> > > > >in v2020.01?
> > > > >
> > > > >If not, do you need to have more time for your reviewing?
> > > > >What else do you expect from my side to accelerate the upstream?
> > > > 
> > > > We are reaching the end of the release cycle. So do not expect any of
> > > > these patch series to be merged in v2020.01.
> > > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle
> > > 
> > > I have often seen several patches (not bug fix) merged
> > > even after "merge window".
> > > Anyway,
> > > 
> > > > To my understanding the UEFI secure boot series depends on the other two
> > > > so it must be merged last.
> > > 
> > > So once the first two patch set are accepted by the maintainers,
> > > do you agree to merging the third one (i.e. secure boot patch itself)
> > > promptly?
> > >         -> Heinrich
> > > 
> > > As I said, I have had no technical issues on the first two patches
> > > and haven't heard any comments/objections from the maintainers so far.
> > > Are you willing to accept them for the next release?
> > >         -> Tom, Simon
> > 
> > Can you confirm that you have queued my "RSA library extension" patch
> > in your -next(?) branch, please?
> 
> Please note that I raised a concern with the RSA patch series that needs
> to be addressed.  There's unexplained / unexpected size growth on
> platforms that aren't otherwise enabling new features.  Thanks!

I misunderstood your statement there.
Questions:
1) How did you measure the size growth?
   Please specify the exact command(s).
2) Did you use T1042RDB_PI_NAND_SECURE_BOOT_defconfig without any change?

I want to reproduce your result on my side.

Thanks,
-Takahiro Akashi


> -- 
> Tom
Tom Rini Dec. 11, 2019, 8:28 p.m. UTC | #10
On Wed, Dec 11, 2019 at 11:10:42AM +0900, AKASHI Takahiro wrote:
> On Tue, Dec 10, 2019 at 08:54:12PM -0500, Tom Rini wrote:
> > On Wed, Dec 11, 2019 at 09:41:56AM +0900, AKASHI Takahiro wrote:
> > > Simon,
> > > 
> > > On Wed, Dec 04, 2019 at 05:28:59PM +0900, AKASHI Takahiro wrote:
> > > > On Wed, Dec 04, 2019 at 08:31:26AM +0100, Heinrich Schuchardt wrote:
> > > > > On 12/4/19 3:43 AM, AKASHI Takahiro wrote:
> > > > > >Tom, Simon, Heinrich,
> > > > > >
> > > > > >I have submitted three major patch sets for UEFI secure boot:
> > > > > >* x509/pkcs7 parser
> > > > > >* RSA library extension
> > > > > >* UEFI secure boot
> > > > > >
> > > > > >I have no technical issues to fix now and have seen only a few minor
> > > > > >comments on them (if I confirm that you have no more comments,
> > > > > >I can submit new version almost immediately).
> > > > > >Considering those, can I expect that those patches be merged
> > > > > >in v2020.01?
> > > > > >
> > > > > >If not, do you need to have more time for your reviewing?
> > > > > >What else do you expect from my side to accelerate the upstream?
> > > > > 
> > > > > We are reaching the end of the release cycle. So do not expect any of
> > > > > these patch series to be merged in v2020.01.
> > > > > cf. https://www.denx.de/wiki/U-Boot/ReleaseCycle
> > > > 
> > > > I have often seen several patches (not bug fix) merged
> > > > even after "merge window".
> > > > Anyway,
> > > > 
> > > > > To my understanding the UEFI secure boot series depends on the other two
> > > > > so it must be merged last.
> > > > 
> > > > So once the first two patch set are accepted by the maintainers,
> > > > do you agree to merging the third one (i.e. secure boot patch itself)
> > > > promptly?
> > > >         -> Heinrich
> > > > 
> > > > As I said, I have had no technical issues on the first two patches
> > > > and haven't heard any comments/objections from the maintainers so far.
> > > > Are you willing to accept them for the next release?
> > > >         -> Tom, Simon
> > > 
> > > Can you confirm that you have queued my "RSA library extension" patch
> > > in your -next(?) branch, please?
> > 
> > Please note that I raised a concern with the RSA patch series that needs
> > to be addressed.  There's unexplained / unexpected size growth on
> > platforms that aren't otherwise enabling new features.  Thanks!
> 
> I misunderstood your statement there.
> Questions:
> 1) How did you measure the size growth?
>    Please specify the exact command(s).
> 2) Did you use T1042RDB_PI_NAND_SECURE_BOOT_defconfig without any change?

So, I have the following script for doing size tests:
#!/bin/bash

# Initial and constant buildman args
ARGS="-devl"
ALL=0
KEEP=0

# Find our arguments
while test $# -ne 0; do
	if [ "$1" == "--all" ]; then
		ALL=1
		shift 1
	elif [ "$1" == "--branch" ]; then
		BRANCH=$2
		shift 2
	elif [ "$1" == "--keep" ]; then
		KEEP=1
		ARGS="$ARGS -k"
		shift 1
	else
		MACHINE=$1
		shift
	fi
done

if [ -z $MACHINE ]; then
	echo Usage: $0 MACHINE [--all] [--keep] [--branch BRANCH]
	exit 1
fi

# If not all, then only first/last
if [ $ALL -ne 1 ]; then
	ARGS="$ARGS --step 0"
fi

if [ ! -z $BRANCH ]; then
	ARGS="$ARGS -b $BRANCH"
else
	ARGS="$ARGS -b `git rev-parse --abbrev-ref HEAD`"
fi

mkdir -p /tmp/$MACHINE

export SOURCE_DATE_EPOCH=`date +%s`
./tools/buildman/buildman -o /tmp/$MACHINE $ARGS -SBC $MACHINE
./tools/buildman/buildman -o /tmp/$MACHINE $ARGS -SsB $MACHINE

[ $KEEP -eq 0 ] && rm -rf /tmp/$MACHINE

And yes, I applied just the series and built the world.  The
T1042RDB_PI_NAND_SECURE_BOOT_defconfig config along with a handful of
other PowerPC platforms (also of the _SECURE_BOOT variety) had the same
size growth.  I didn't bisect down to the specific commit in question at
the time.