On Wed, May 15, 2013 at 6:22 AM, Laszlo Ersek <ler...@redhat.com> wrote: > On 05/15/13 11:03, Gary Ching-Pang Lin wrote: >> A variable store length check was introduced since r14252. After >> applying the patch, OVMF died in >> >> SecurityPkg/VariableAuthenticated/RuntimeDxe/Variable.c >> >> ASSERT(MAX (PcdGet32 (PcdMaxVariableSize), PcdGet32 >> (PcdMaxHardwareErrorVariableSize)) < VariableStoreLength); >> >> The check is reasonable. However, in OvmfPkg/OvmfPkgX64.dsc: >> >> !if $(SECURE_BOOT_ENABLE) == TRUE >> gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x10000 >> !else >> gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x400 >> !endif > > ## The maximum size of single common variable, that is non-HwErr type > # varible. > > >> gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize|0x8000 > > ## The maximum size of single hardware error record variable. > # In IA32/X64 platforms, this value should be larger than 1KB. > # In IA64 platforms, this value should be larger than 128KB. > > >> gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xc000 > > ## The size of volatile buffer. This buffer is used to store VOLATILE > # attribute variable. > > >> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0xc000 > > ## Size of the NV variable range. Note that this value should less than > # or equal to PcdFlashNvStorageFtwSpareSize > # The root cause is that variable driver will use FTW protocol to > # reclaim variable region. > # If the length of variable region is larger than FTW spare size, it > # means the whole variable region can not be reflushed through the > # manner of fault tolerant write. > > >> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x2000 > > ## Size of the FTW working block range. > > >> gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x10000 > > ## Size of the FTW spare block range. Note that this value should larger > # than PcdFlashNvStorageVariableSize > # The root cause is that variable driver will use FTW protocol to > # reclaim variable region. > # If the length of variable region is larger than FTW spare size, it > # means the whole variable region can not be reflushed through the > # manner of fault tolerant write. > > >> 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 > 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>.
Is the patch I just posted (OvmfPkg: Reduce PcdMaxVariableSize with secure boot to avoid assert) an acceptable alternative to your patch? -Jordan > > ( > > 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>. > > ) > > Thanks, > Laszlo > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
