On Wed, May 15, 2013 at 03:22:53PM +0200, Laszlo Ersek wrote: > On 05/15/13 11:03, Gary Ching-Pang Lin wrote: > > When Secure Boot is enabled, PcdFlashNvStorageVariableSize is much > > smaller than PcdMaxVariableSize, not to mention VariableStoreLength > > which is derived from PcdFlashNvStorageVariableSize, so the check > > always fails. > > > > Any suggestion about the variable size? > > PcdMaxVariableSize was separated *and* raised for secure boot in svn > r13093. Apparently secure boot needs 64 times as much. I guess this > immediately violated some logic constraint (being greater than > PcdFlashNvStorageVariableSize -- "The max variable or hardware error > variable size should be < variable store size"), only that constraint > wasn't enforced until r14252. > > ... I wonder if this has been all along in the background of boot option > variables not working at all in the secure boot build of OVMF. > > Apparently we're subject to at least the following inequalities: > > PcdMaxVariableSize + HeaderLength < > PcdFlashNvStorageVariableSize <= PcdFlashNvStorageFtwSpareSize > PcdMaxHardwareErrorVariableSize + HeaderLength < > PcdFlashNvStorageVariableSize <= PcdFlashNvStorageFtwSpareSize > > Assuming PcdMaxVariableSize was set to 0x10000 in r13093, 64 times the > non-secure boot value, for a good reason, we should leave it intact and > raise the other variables instead. > > Based on "OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.c" I'm under the > impression that HeaderLength is EMU_FV_HEADER_LENGTH here, which should > equal sizeof(EFI_FIRMWARE_VOLUME_HEADER) + > sizeof(EFI_FV_BLOCK_MAP_ENTRY). > > Assuming packed structures (... which could be a stretch for > EFI_FIRMWARE_VOLUME_HEADER...), > > sizeof(EFI_FV_BLOCK_MAP_ENTRY) == 8 > sizeof(EFI_FIRMWARE_VOLUME_HEADER) == 64 > EMU_FV_HEADER_LENGTH == 72 > > > ... Does the attached patch work for you? It enables me to run the Yes, the patch works for me. > SECURE_BOOT_ENABLE build. I could even test secure booting Windows 8 (a > preview build): > <http://www.linux-kvm.org/page/OVMF#Confirmation_of_secure_boot_in_Windows_8_Consumer_Preview_Build_8250>. > > ( > > Unfortunately the enrolled keys don't seem to survive a VM reboot, so > there's no change in that -- this problem likely isn't related to NvVar > storage sizes. > > Also I failed to secure boot Fedora 19 > <http://www.linux-kvm.org/page/OVMF#Confirmation_of_secure_boot_in_Fedora_18>, > which I guess might still relate to this thread (also started by you): > <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2329>. I think so. The git head OVMF (after applying your patch) works well with the lastest SLE 11 SP3 boot loader.
Gary Lin ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
