On 11/08/13 19:04, Jordan Justen wrote: > On Thu, Nov 7, 2013 at 10:07 AM, Laszlo Ersek <[email protected]> wrote: >> I also wanted to test secure boot (see if the enrolled keys survive a >> cold reboot), but I noticed that this series doesn't disable the "load >> variables from the NvVars file" functionality. >> >> I added the attached patch on top of this series, and this way the >> enrolled keys seem to persist. I could fully secure-boot Fedora 19 on my >> SVM host with it, even after a full VM shutdown. Do you think the patch >> has merit? > > I want to consider keeping this (NvVars loading) functionality. > > The reason being is that it was pointed out that some people like to > distribute QEMU disk images pre-loaded with an OS. Therefore, this > might be the only way that those disk images could also set the boot > variables to point at the boot loader. > > I'm not sure this is the best idea though, so feel free to discuss > further. An alternative idea would be for those disk images to simply > supply \EFI\BOOT\BOOTXXXX.efi loaders though which we could try to > load in the absence of boot vars.
I'd like to drop the NvVars loading. I realize that allowing Boot#### and BootOrder settings "in downloads" is useful. I think the \EFI\BOOT\BOOTXXXX.efi way won't work though, because these disk images are usually presented as fixed disks (not removable media), and IIRC UEFI only auto-loads these paths on removable media. In my opinion one long term solution would be: - Distributors would provide disk images without the NvVars file inside. - Distributors would also provide (as a separate download, or maybe as another file in the tarball) the accompanying variable store. - The user would pass the variable store as a separate flash (currently unsupported by qemu), or they'd need to combine their OVMF binary with the new variable store into a single, new flash image (probably a task for the to-be-written flashing utility). - Of course, instead of the separate variable store, the distributor could provide a full OVMF.fd too (with prebuilt OVMF binary and pre-configured Boot* variables at once). The last approach would work Right Now (TM), ie. as soon as you push your series. It would also allow distributors to provide OVMF.fd builds with pre-enrolled keys, and secure boot enabled (which cannot work with NvVars-from-disk at all). Thanks! Laszlo ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
