Hi Leif/Ard,
Currently, what security properties does secure boot in edk2 on arm guarantee? How should one enable secure boot on the ARM Juno platform?
I've tried copying sections related to "SECURE_BOOT_ENABLE" from OpenPlatformPkg/Platforms/ARM/VExpress/* into corresponding files in OpenPlatformPkg/Platforms/ARM/Juno/ and setting SECURE_BOOT_ENABLE = True. After rebuilding edk2 and arm-tf for Juno, I did a sanity test to check if the kernel image is verified during boot. I didn't sign the kernel image or provide any certificate, etc. so I expect the boot process to fail at kernel verification. However, the boot process continue until the Linux shell prompt. What did I miss here?
I also came across this doc which includes some instructions on secure boot: https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security Could you elaborate on how the DATA block (which include VARIABLE_STORE_HEADER) is created?
Best Regards,
Tommy IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Tommy,
On Wed, Jun 07, 2017 at 06:39:25PM +0000, Tommy Huynh wrote:
Hi Leif/Ard,
Currently, what security properties does secure boot in edk2 on arm guarantee?
There is nothing ARM-specific about UEFI Secure Boot. Whatever is platform dependent is ... platform specific.
How should one enable secure boot on the ARM Juno platform?
Normally, all you would be expected to need is to build with -D SECURE_BOOT_ENABLE=TRUE
I've tried copying sections related to "SECURE_BOOT_ENABLE" from OpenPlatformPkg/Platforms/ARM/VExpress/* into corresponding files in OpenPlatformPkg/Platforms/ARM/Juno/ and setting SECURE_BOOT_ENABLE = True.
Oh, you shouldn't need to copy anything across. (If you do, we've messed up, and a bug report to edk2-devel@lists.01.org would be appreciated.)
It seems you've tripped over the case sensitivity ... It's supposed to be SECURE_BOOT_ENABLE=TRUE.
So, the only semi-tricky bit is you need to import OpenSSL in order to get the included cruptography support.
Your email prompted me to have a look at my helper scripts (https://git.linaro.org/uefi/uefi-tools.git) and it seems the integration has once again been revamped, so my scripts were no longer working. But I updated them and uefi-build.sh now tries to automatically import the latest version in the most convoluted way possible (I'd recommend against reading it).
Although, as Ard pointed out to me, you can these days also manually download the latest version from https://www.openssl.org/source/, extract it into CryptoPkg/Library/OpensslLib/ and rename the directory 'openssl' (without the version number), and that should "just work".
After rebuilding edk2 and arm-tf for Juno, I did a sanity test to check if the kernel image is verified during boot. I didn't sign the kernel image or provide any certificate, etc. so I expect the boot process to fail at kernel verification. However, the boot process continue until the Linux shell prompt. What did I miss here?
I also came across this doc which includes some instructions on secure boot: https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security Could you elaborate on how the DATA block (which include VARIABLE_STORE_HEADER) is created?
I'll leave this bit for Ard.
Regards,
Leif
On 8 June 2017 at 09:50, Leif Lindholm leif.lindholm@linaro.org wrote:
Hi Tommy,
On Wed, Jun 07, 2017 at 06:39:25PM +0000, Tommy Huynh wrote:
Hi Leif/Ard,
Currently, what security properties does secure boot in edk2 on arm guarantee?
There is nothing ARM-specific about UEFI Secure Boot. Whatever is platform dependent is ... platform specific.
The ARM implementations lack the UEFI mandated properties of the variable store of being tamper proof and rollback protected. This is due to the fact that the varstore itself and the layers on top of it that implement the authentication of secure variable updates need to reside in a secure execution context that is different from the OS's, which is currently not implemented yet. This is something standalone MM aims to provide.
In the current implementations, the OS can directly access (and thus tamper with) the contents of the NOR flash. Also, the authentication routines reside in firmware memory regions that are accessible to (and modifiable by) the OS.
How should one enable secure boot on the ARM Juno platform?
Normally, all you would be expected to need is to build with -D SECURE_BOOT_ENABLE=TRUE
I've tried copying sections related to "SECURE_BOOT_ENABLE" from OpenPlatformPkg/Platforms/ARM/VExpress/* into corresponding files in OpenPlatformPkg/Platforms/ARM/Juno/ and setting SECURE_BOOT_ENABLE = True.
Oh, you shouldn't need to copy anything across. (If you do, we've messed up, and a bug report to edk2-devel@lists.01.org would be appreciated.)
It seems you've tripped over the case sensitivity ... It's supposed to be SECURE_BOOT_ENABLE=TRUE.
So, the only semi-tricky bit is you need to import OpenSSL in order to get the included cruptography support.
Your email prompted me to have a look at my helper scripts (https://git.linaro.org/uefi/uefi-tools.git) and it seems the integration has once again been revamped, so my scripts were no longer working. But I updated them and uefi-build.sh now tries to automatically import the latest version in the most convoluted way possible (I'd recommend against reading it).
Although, as Ard pointed out to me, you can these days also manually download the latest version from https://www.openssl.org/source/, extract it into CryptoPkg/Library/OpensslLib/ and rename the directory 'openssl' (without the version number), and that should "just work".
After rebuilding edk2 and arm-tf for Juno, I did a sanity test to check if the kernel image is verified during boot. I didn't sign the kernel image or provide any certificate, etc. so I expect the boot process to fail at kernel verification. However, the boot process continue until the Linux shell prompt. What did I miss here?
I also came across this doc which includes some instructions on secure boot: https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-Security Could you elaborate on how the DATA block (which include VARIABLE_STORE_HEADER) is created?
I'll leave this bit for Ard.
That page looks somewhat stale: AFAIK there is no longer a need to use a different variable store header when using secure variables.
Perhaps it makes sense to familiarize yourself with EDK2's secure boot implementation using QEMU. The snapshots at https://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstr... are built with secure boot support, and ArmVirtPkg/VarStore.fdf.inc contains the layout of the varstore FV image.
Hi Ard/Leif,
Thank you for your responses. I built edk2 for QEMUv8 with the this supergit: https://github.com/OP-TEE/build. I tried enabling secure boot by passing "-D SECURE_BOOT_ENABLE=TRUE" and even tried modifying the default value for SECURE_BOOT_ENABLE in edk2/ArmVirtPkg/{ArmVirtQemuKernel.dsc, ArmVirtQemu.dsc}
However in the boot log, I saw messages like these: Variable PK does not exist. Variable SetupMode is 1 Variable SecureBoot is 0 Variable SecureBootEnable is 0 Variable CustomMode is 0 Variable VendorKeys is 1
What's the proper way to enable secure boot for qemu?
Best Regards, -- Tommy
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] Sent: Thursday, June 8, 2017 7:28 AM To: Leif Lindholm leif.lindholm@linaro.org Cc: Tommy Huynh Tommy.Huynh@arm.com; linaro-uefi@lists.linaro.org; Stuart Yoder Stuart.Yoder@arm.com Subject: Re: OpenPlatformPkg/Platforms/ARM/Juno: Enable Secure Boot
On 8 June 2017 at 09:50, Leif Lindholm leif.lindholm@linaro.org wrote:
Hi Tommy,
On Wed, Jun 07, 2017 at 06:39:25PM +0000, Tommy Huynh wrote:
Hi Leif/Ard,
Currently, what security properties does secure boot in edk2 on arm guarantee?
There is nothing ARM-specific about UEFI Secure Boot. Whatever is platform dependent is ... platform specific.
The ARM implementations lack the UEFI mandated properties of the variable store of being tamper proof and rollback protected. This is due to the fact that the varstore itself and the layers on top of it that implement the authentication of secure variable updates need to reside in a secure execution context that is different from the OS's, which is currently not implemented yet. This is something standalone MM aims to provide.
In the current implementations, the OS can directly access (and thus tamper with) the contents of the NOR flash. Also, the authentication routines reside in firmware memory regions that are accessible to (and modifiable by) the OS.
How should one enable secure boot on the ARM Juno platform?
Normally, all you would be expected to need is to build with -D SECURE_BOOT_ENABLE=TRUE
I've tried copying sections related to "SECURE_BOOT_ENABLE" from OpenPlatformPkg/Platforms/ARM/VExpress/* into corresponding files in OpenPlatformPkg/Platforms/ARM/Juno/ and setting SECURE_BOOT_ENABLE = True.
Oh, you shouldn't need to copy anything across. (If you do, we've messed up, and a bug report to edk2-devel@lists.01.org would be appreciated.)
It seems you've tripped over the case sensitivity ... It's supposed to be SECURE_BOOT_ENABLE=TRUE.
So, the only semi-tricky bit is you need to import OpenSSL in order to get the included cruptography support.
Your email prompted me to have a look at my helper scripts (https://git.linaro.org/uefi/uefi-tools.git) and it seems the integration has once again been revamped, so my scripts were no longer working. But I updated them and uefi-build.sh now tries to automatically import the latest version in the most convoluted way possible (I'd recommend against reading it).
Although, as Ard pointed out to me, you can these days also manually download the latest version from https://www.openssl.org/source/, extract it into CryptoPkg/Library/OpensslLib/ and rename the directory 'openssl' (without the version number), and that should "just work".
After rebuilding edk2 and arm-tf for Juno, I did a sanity test to check if the kernel image is verified during boot. I didn't sign the kernel image or provide any certificate, etc. so I expect the boot process to fail at kernel verification. However, the boot process continue until the Linux shell prompt. What did I miss here?
I also came across this doc which includes some instructions on secure boot: https://github.com/tianocore/tianocore.github.io/wiki/How-to-Enable-S ecurity Could you elaborate on how the DATA block (which include VARIABLE_STORE_HEADER) is created?
I'll leave this bit for Ard.
That page looks somewhat stale: AFAIK there is no longer a need to use a different variable store header when using secure variables.
Perhaps it makes sense to familiarize yourself with EDK2's secure boot implementation using QEMU. The snapshots at https://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstr... are built with secure boot support, and ArmVirtPkg/VarStore.fdf.inc contains the layout of the varstore FV image. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On 20 June 2017 at 17:52, Tommy Huynh Tommy.Huynh@arm.com wrote:
Hi Ard/Leif,
Thank you for your responses. I built edk2 for QEMUv8 with the this supergit: https://github.com/OP-TEE/build. I tried enabling secure boot by passing "-D SECURE_BOOT_ENABLE=TRUE" and even tried modifying the default value for SECURE_BOOT_ENABLE in edk2/ArmVirtPkg/{ArmVirtQemuKernel.dsc, ArmVirtQemu.dsc}
However in the boot log, I saw messages like these: Variable PK does not exist. Variable SetupMode is 1 Variable SecureBoot is 0 Variable SecureBootEnable is 0 Variable CustomMode is 0 Variable VendorKeys is 1
What's the proper way to enable secure boot for qemu?
You need to run QEMU with persistent flash, no any changes you make are not lost when you restart QEMU (use -pflash rather than -bios). Then, you need to enroll certificates in the UEFI setup screen. This is not specific to arm, so Google is your friend here (pk kek db secure boot uefi)
-
Ard Biesheuvel -
Leif Lindholm -
Tommy Huynh