| Message ID | 20191126005120.31156-1-takahiro.akashi@linaro.org |
|---|---|
| Headers | show |
| Series | efi_loader: add secure boot support | expand |
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 >
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>
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 >
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
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
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.
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
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!
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
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.
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