On Wed, 27 Mar 2024 at 07:57, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > 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.
Fortunately there's no such thing. Unless you run the required commands on boot, there's no difference and it very much does not "look like secure boot". > 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. When I need to use edk2, I use edk2. If I am using uboot, it's because I want to use uboot. I am not sure why you want to break my use case for something that doesn't affect you in any way?
