On Fri, Nov 8, 2013 at 11:23 AM, Andrew Fish <[email protected]> wrote: > > On Nov 8, 2013, at 11:10 AM, Jordan Justen <[email protected]> wrote: > >> On Fri, Nov 8, 2013 at 10:30 AM, Laszlo Ersek <[email protected]> wrote: >>> 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 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. >> >> Looks like in the UEFI 2.3 spec, these paths are specifically allowed >> as fall-back boot paths. >> See "3.4.1.2 Non-removable Media Boot Behavior” > > But the question I will ask is why do we need to do something custom?
If the UEFI spec mentions it as an option, then it doesn't seem all that custom. > Is your case any different than walking up to machine with a driver that has > been pre-imaged? How would that get solved on a real system? Is it automating > the solution your are after? In that case falling back to the removable media > case seems like a reasonable solution, if no other solution exists. There is no removable media. This is like walking up to a machine, and installing a hard disk with a pre-imaged OS, and wanting it to just boot. -Jordan ------------------------------------------------------------------------------ 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
