The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the
Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the
Microsoft Hardware Certification Kit expects to be able to populate the
variable store up to roughly 64 KB, with a series of 1 KB sized,
unauthenticated variables. OVMF's current live varstore area is too small
for this: 56 KB.
Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096),
which
- enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see
FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --,
- inside that, grows the varstore area / pflash chip to 528 KB, and within
it, the live area from 56 KB to 256 KB.
Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be
compatible with a variable store that originates from a variable store
template built *without* -D FD_SIZE_4MB. This is the reason for the large
increase, as every such change breaks compatibility between a new firmware
binary and old varstore files.
Enlarging the varstore does not impact the performance of normal
operations, as we keep the varstore block size 4KB. The performance of
reclaim is affected, but that is expected (since reclaim has to rework the
full live area). And, reclaim occurs proportionally less frequently.
While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in
it) is also enlarged significantly, so that we have plenty of room for
future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing
steadily, and that increase shows through compression too. Right now the
PEIFV and DXEFV volumes need no resizing.
Here's a summary:
Description Compression type Size [KB]
------------------------- ----------------- ----------------------
Non-volatile data storage open-coded binary 128 -> 528 ( +400)
data
Variable store 56 -> 256 ( +200)
Event log 4 -> 4 ( +0)
Working block 4 -> 4 ( +0)
Spare area 64 -> 264 ( +200)
FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648)
FV FFS file LZMA compressed
PEIFV uncompressed 896 -> 896 ( +0)
individual PEI uncompressed
modules
DXEFV uncompressed 10240 -> 10240 ( +0)
individual DXE uncompressed
modules
SECFV uncompressed 208 -> 208 ( +0)
SEC driver
reset vector code
For now, the 2MB flash image remains the default.
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Before the merger of the authenticated and non-authenticated variable
drivers (commit fa0737a839), we had to match the varstore header GUID in
"OvmfPkg/VarStore.fdf.inc" to SECURE_BOOT_ENABLE, because the opposite
GUID would cause either driver to fail an assertion. The header structures
for individual variables residing in the varstore were different
(VARIABLE_HEADER vs. AUTHENTICATED_VARIABLE_HEADER), and each driver could
only handle its own, so this GUID enforcement was necessary.
Since the unification of the variable driver however, it treats (a)
variable store format, and (b) AuthVariableLib instance as independent
characteristics; it can always manipulate variable stores with both header
types. All variations boot now; the difference is whether authenticated
variables, and special variables computed from them (like SecureBoot) are
supported at runtime:
variable store non-auth auth and SB
header GUID AuthVariableLib variables variables
-- --------------------- ------------------- -> --------- -----------
1 Variable SecurityPkg/... supported unsupported
2 Variable AuthVariableLibNull supported unsupported
3 AuthenticatedVariable SecurityPkg/... supported supported
4 AuthenticatedVariable AuthVariableLibNull supported unsupported
At the moment, SECURE_BOOT_ENABLE selects between cases #2 (FALSE) and #3
(TRUE). That is, it controls both the varstore header GUID in
"OvmfPkg/VarStore.fdf.inc", and the AuthVariableLib resolution in the DSC
files.
Exploiting the unified driver's flexibility, we can simplify
"OvmfPkg/VarStore.fdf.inc" by picking the AuthenticatedVariable GUID as a
constant, and letting SECURE_BOOT_ENABLE control only the AuthVariableLib
resolution. This amounts to SECURE_BOOT_ENABLE choosing between cases #3
(TRUE) and #4 (FALSE), with identical results as before.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/7319/focus=7344
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware
code in separate files.
The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB.
With the split files, it must be ensured on the QEMU command line that
OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end
exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0).
In this patch we must take care to assign each PCD only once.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15670 6f19259b-4bc3-4df7-8a09-765794883524
This saves code duplication between the Ia32, Ia32X64, and X64 flavors,
and enables the next patch to include the varstore in new FD files by
reference.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15669 6f19259b-4bc3-4df7-8a09-765794883524
Michael D Kinney
Laszlo Ersek