| Message ID | 20191218004512.24939-1-takahiro.akashi@linaro.org |
|---|---|
| Headers | show |
| Series | efi_loader: add secure boot support | expand |
On 12/18/19 1:44 AM, 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.) > > 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 experimental 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. > I am missing a patch providing the necessary documentation explaining how a user would: * create a certificate to be used in conjunction with this patch series * add the public key to U-Boot * persist the public key * sign a UEFI image * which settings are needed for verified boot Best regards Heinrich > > 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) > * 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 regression.) > * Travis CI tests have passed. > > 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].) > > > 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-December/393977.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 v4 (Dec 18, 2019) > * adjust EFI_SECURE_BOOT dependencies due to a change of RSA extension patch v5 > (patch#2) > * change "imply" to "select" against kconfig dependencies (patch#2) > * otherwise, no functional changes > > Changes in v3 (Dec 9, 2019) > * allow for arbitrary number of regions in efi_image_region_add() > (patch#3, #5 and #8) > * remove a redundant check in a while loop at efi_sigstore_free() (patch#4) > > 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 separate 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 dependency 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 | 19 + > lib/efi_loader/Makefile | 1 + > lib/efi_loader/efi_boottime.c | 2 +- > lib/efi_loader/efi_image_loader.c | 454 ++++++++- > lib/efi_loader/efi_setup.c | 38 + > lib/efi_loader/efi_signature.c | 810 +++++++++++++++ > lib/efi_loader/efi_variable.c | 951 ++++++++++++++++-- > 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, 3046 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 >
On 12/18/19 1:44 AM, 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.) > > 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 experimental 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. > Device trees can be used for denial of service or to destroy hardware. How will you address the validation of device trees? Best regards Heinrich
On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote: > On 12/18/19 1:44 AM, 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.) > > > > 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 experimental 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. > > > > Device trees can be used for denial of service or to destroy hardware. > > How will you address the validation of device trees? Although this is really simple to solve, factoring in the different vendor needs makes it quite complex. There's a couple of options we can consider and not all of them are sane. 1. U-Boot embeds the DTB. This is straightforward. On Arm devices TF-A verifies U-boot so you natively end up with a verified DTB. If U-Boot does not include the proper DTB (as is the case for several devices), one can always complite the correct DTB and compile with EXT_DTB. 2. Use https://github.com/jiazhang0/SELoader which verifies non-PE files 3. Add some custom code and use UEFI keyring to verify non PE files. This is a bad idea though since you'll 'polute' the UEFI keyring. 4. FIT for DTB (??) In any case UEFI job is to verify PE/COFF executables and that's what this patch provides. DTB verification is beyond UEFI secure boot patches imho. Regards /Ilias > > Best regards > > Heinrich
On 1/9/20 9:02 AM, Ilias Apalodimas wrote: > On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote: >> On 12/18/19 1:44 AM, 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.) >>> >>> 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 experimental 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. >>> >> >> Device trees can be used for denial of service or to destroy hardware. >> >> How will you address the validation of device trees? > > Although this is really simple to solve, factoring in the different vendor > needs makes it quite complex. > There's a couple of options we can consider and not all of them are sane. > > 1. U-Boot embeds the DTB. This is straightforward. On Arm devices TF-A > verifies U-boot so you natively end up with a verified DTB. If U-Boot does not > include the proper DTB (as is the case for several devices), one can always > complite the correct DTB and compile with EXT_DTB. > 2. Use https://github.com/jiazhang0/SELoader which verifies non-PE files > 3. Add some custom code and use UEFI keyring to verify non PE files. This is a > bad idea though since you'll 'polute' the UEFI keyring. > 4. FIT for DTB (??) > > In any case UEFI job is to verify PE/COFF executables and that's what this patch > provides. DTB verification is beyond UEFI secure boot patches imho. > > Regards > /Ilias The UEFI specification does not mention device trees at all. EDK2 is based on ACPI tables. We already have verified boot via signed UEFI FIT images which can contain an UEFI image and a device tree. So for verified boot of Linux you would simply package shim and the device tree into a FIT image. Shim would verify GRUB and GRUB would verify the kernel and the ramdisk. In this scenario we don't need the current patch series at all and it integrates well with distributions like Debian which provide shim for arm64, cf. https://packages.debian.org/de/bullseye/shim-signed . If we implement secure boot according the UEFI specification, one option would be to package the device tree as a UEFI driver image and let the stub install it as a configuration table. The unload callback could be used to remove the device tree. Best regards Heinrich >> >> Best regards >> >> Heinrich >
On Thu, Jan 09, 2020 at 08:09:27PM +0100, Heinrich Schuchardt wrote: > On 1/9/20 9:02 AM, Ilias Apalodimas wrote: > > On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote: > > > On 12/18/19 1:44 AM, 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.) > > > > > > > > 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 experimental 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. > > > > > > > > > > Device trees can be used for denial of service or to destroy hardware. > > > > > > How will you address the validation of device trees? > > > > Although this is really simple to solve, factoring in the different vendor > > needs makes it quite complex. > > There's a couple of options we can consider and not all of them are sane. > > > > 1. U-Boot embeds the DTB. This is straightforward. On Arm devices TF-A > > verifies U-boot so you natively end up with a verified DTB. If U-Boot does not > > include the proper DTB (as is the case for several devices), one can always > > complite the correct DTB and compile with EXT_DTB. > > 2. Use https://github.com/jiazhang0/SELoader which verifies non-PE files > > 3. Add some custom code and use UEFI keyring to verify non PE files. This is a > > bad idea though since you'll 'polute' the UEFI keyring. > > 4. FIT for DTB (??) > > > > In any case UEFI job is to verify PE/COFF executables and that's what this patch > > provides. DTB verification is beyond UEFI secure boot patches imho. > > > > Regards > > /Ilias > > The UEFI specification does not mention device trees at all. EDK2 is > based on ACPI tables. On one of the platforms i kknow of (socionext synquacer), it also provides DTB as part of the firmware, which is identical to proposeal (1) I mentioned. > > We already have verified boot via signed UEFI FIT images which can > contain an UEFI image and a device tree. So for verified boot of Linux > you would simply package shim and the device tree into a FIT image. Shim > would verify GRUB and GRUB would verify the kernel and the ramdisk. In > this scenario we don't need the current patch series at all and it > integrates well with distributions like Debian which provide shim for > arm64, cf. https://packages.debian.org/de/bullseye/shim-signed . Of course everything is verified, but that's not UEFI secure boot. It's similar but the verification does not go through DB/DBX and there are no secure variables, so the current patchset has value. > > If we implement secure boot according the UEFI specification, one option > would be to package the device tree as a UEFI driver image and let the > stub install it as a configuration table. The unload callback could be > used to remove the device tree. > Sure but this is not in scope for the current patchset is it? Similarly you can just include the DTB in U-Boot and naturally have it verified. I am not arguing that DTB verification is needed. We absolutely agree on that. All i am saying is that the extra functionality can be added in the future, since we already have a valid way of providing it with the current patchset. Regards /Ilias > > > > > > > Best regards > > > > > > Heinrich > > >
On Thu, Jan 09, 2020 at 10:03:33PM +0200, Ilias Apalodimas wrote: > On Thu, Jan 09, 2020 at 08:09:27PM +0100, Heinrich Schuchardt wrote: > > On 1/9/20 9:02 AM, Ilias Apalodimas wrote: > > > On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote: > > > > On 12/18/19 1:44 AM, 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.) > > > > > > > > > > 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 experimental 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. > > > > > > > > > > > > > Device trees can be used for denial of service or to destroy hardware. > > > > > > > > How will you address the validation of device trees? > > > > > > Although this is really simple to solve, factoring in the different vendor > > > needs makes it quite complex. > > > There's a couple of options we can consider and not all of them are sane. > > > > > > 1. U-Boot embeds the DTB. This is straightforward. On Arm devices TF-A > > > verifies U-boot so you natively end up with a verified DTB. If U-Boot does not > > > include the proper DTB (as is the case for several devices), one can always > > > complite the correct DTB and compile with EXT_DTB. > > > 2. Use https://github.com/jiazhang0/SELoader which verifies non-PE files > > > 3. Add some custom code and use UEFI keyring to verify non PE files. This is a > > > bad idea though since you'll 'polute' the UEFI keyring. > > > 4. FIT for DTB (??) > > > > > > In any case UEFI job is to verify PE/COFF executables and that's what this patch > > > provides. DTB verification is beyond UEFI secure boot patches imho. > > > > > > Regards > > > /Ilias > > > > The UEFI specification does not mention device trees at all. EDK2 is > > based on ACPI tables. > > On one of the platforms i kknow of (socionext synquacer), it also provides DTB > as part of the firmware, which is identical to proposeal (1) I mentioned. > > > > > We already have verified boot via signed UEFI FIT images which can > > contain an UEFI image and a device tree. So for verified boot of Linux > > you would simply package shim and the device tree into a FIT image. Shim > > would verify GRUB and GRUB would verify the kernel and the ramdisk. In > > this scenario we don't need the current patch series at all and it > > integrates well with distributions like Debian which provide shim for > > arm64, cf. https://packages.debian.org/de/bullseye/shim-signed . > > Of course everything is verified, but that's not UEFI secure boot. It's similar > but the verification does not go through DB/DBX and there are no secure > variables, so the current patchset has value. I believe that db/dbx schemes give us, distributors as well as users, more flexible manner of managing secure boot process. > > > > If we implement secure boot according the UEFI specification, one option > > would be to package the device tree as a UEFI driver image and let the > > stub install it as a configuration table. The unload callback could be > > used to remove the device tree. > > > > Sure but this is not in scope for the current patchset is it? Exactly. > Similarly you can just include the DTB in U-Boot and naturally have it verified. > > I am not arguing that DTB verification is needed. We absolutely agree on that. > All i am saying is that the extra functionality can be added in the future, > since we already have a valid way of providing it with the current patchset. BTW, Ilias, where should such a discussion about dtb verification be held, Boot-arch ML, Linaro Connect, ELC or whatever else conference? Otherwise just leave the decision in distributors' hands? Thanks, -Takahiro Akashi > Regards > /Ilias > > > > > > > > > > Best regards > > > > > > > > Heinrich > > > > >
[...] > > > If we implement secure boot according the UEFI specification, one option > > > would be to package the device tree as a UEFI driver image and let the > > > stub install it as a configuration table. The unload callback could be > > > used to remove the device tree. > > > > > > > Sure but this is not in scope for the current patchset is it? > > Exactly. > > > Similarly you can just include the DTB in U-Boot and naturally have it verified. > > > > I am not arguing that DTB verification is needed. We absolutely agree on that. > > All i am saying is that the extra functionality can be added in the future, > > since we already have a valid way of providing it with the current patchset. > > BTW, Ilias, > where should such a discussion about dtb verification be held, > Boot-arch ML, Linaro Connect, ELC or whatever else conference? > Otherwise just leave the decision in distributors' hands? We did send some e-mails on boot-arch ML in the past [1]. The subject is quite controversial since there are a lot of opinions on this. I think Linaro is working on a device tree evolution project at the moment with one of the subjects being device tree verification. We can certainly discuss more during Linaro Connect. [1] https://lists.linaro.org/pipermail/boot-architecture/2019-June/001053.html Thanks /Ilias > > Thanks, > -Takahiro Akashi > > > Regards > > /Ilias > > > > > > > > > > > > > Best regards > > > > > > > > > > Heinrich > > > > > > >
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.) 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 experimental 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) * 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 regression.) * Travis CI tests have passed. 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].) 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-December/393977.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 v4 (Dec 18, 2019) * adjust EFI_SECURE_BOOT dependencies due to a change of RSA extension patch v5 (patch#2) * change "imply" to "select" against kconfig dependencies (patch#2) * otherwise, no functional changes Changes in v3 (Dec 9, 2019) * allow for arbitrary number of regions in efi_image_region_add() (patch#3, #5 and #8) * remove a redundant check in a while loop at efi_sigstore_free() (patch#4) 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 separate 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 dependency 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 | 19 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_boottime.c | 2 +- lib/efi_loader/efi_image_loader.c | 454 ++++++++- lib/efi_loader/efi_setup.c | 38 + lib/efi_loader/efi_signature.c | 810 +++++++++++++++ lib/efi_loader/efi_variable.c | 951 ++++++++++++++++-- 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, 3046 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