On 3/26/24 22:47, Vagrant Cascadian wrote:
On 2024-02-16, Heinrich Schuchardt wrote:
debian/patches/qemu/efi-secure-boot.patch is not a good approach to
enabling secure boot with U-Boot. Variables entered via the command line
containing the security database will be stored on file but will not be
loaded into U-Boot on the next boot.
If you want a version of U-Boot that supports secure boot properly, use
CONFIG_EFI_VARIABLES_PRESEED=y and provide a file with the security
database which will be built into U-Boot. tools/efivar.py can be used to
build that file.
Separate U-Boot binaries for secure and non-secure would have to be
provided.
Are you saying that individuals needing this support should build their
own custom u-boot binaries to eanble secure boot ... or that we should
provide separate packages in Debian with secure boot enabled?
I would not see the benefit of providing U-Boot in a way that looks like
secure boot but does not provide security.
Secure boot requires chain of trust. It starts at the root of trust. On
embedded devices this root of trust is typically based on a public key
burnt by the ODM into the SoC. U-Boot needs to be signed with a private
key. The prior boot stage will check the signature.
If Debian wanted to supply signed U-Boot binaries, Debian would have
send the binaries with the built in EFI security data base to the ODM
for signing similar to what is done for signed shim.
The only use case for an unsigned U-Boot with secure-boot enabled would
be for launching virtual machines. But there we can already use the edk2
package.
Best regards
Heinrich
Existing EDK II packages provide secure boot. Hence I suggest to simply
drop patch debian/patches/qemu/efi-secure-boot.patch.
Any thoughts on this, Luca, as the provider of the original merge
request:
https://salsa.debian.org/debian/u-boot/-/merge_requests/24
Thanks!
live well,
vagrant
