From: Laszlo Ersek <lersek@redhat.com>
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>,
Jordan Justen <jordan.l.justen@intel.com>
Subject: [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK
Date: Sat, 29 Apr 2017 22:14:59 +0200 [thread overview]
Message-ID: <20170429201500.18496-3-lersek@redhat.com> (raw)
In-Reply-To: <20170429201500.18496-1-lersek@redhat.com>
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, 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 512 KB, and within
it, the live area from 56 KB to 248 KB.
(For the latter, Hyper-V considers 128 KB generous:
Re: [edk2] Secure Boot & NV storage size
http://mid.mail-archive.com/24f63595e68c476eb98cf87e7abfa1bc@BL2PR03MB242.namprd03.prod.outlook.com
so we should be larger than that, for future proofing.)
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 should 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 should occur 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 -> 512 ( +384)
data
Variable store 56 -> 248 ( +192)
Event log 4 -> 4 ( +0)
Working block 4 -> 4 ( +0)
Spare area 64 -> 256 ( +192)
FVMAIN_COMPACT uncompressed 1712 -> 3376 (+1664)
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
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>
---
OvmfPkg/OvmfPkg.fdf.inc | 29 ++++++++++++
OvmfPkg/VarStore.fdf.inc | 46 +++++++++++++++++++-
2 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/OvmfPkg.fdf.inc b/OvmfPkg/OvmfPkg.fdf.inc
index fce6c7b8ce64..a1eb2d380167 100644
--- a/OvmfPkg/OvmfPkg.fdf.inc
+++ b/OvmfPkg/OvmfPkg.fdf.inc
@@ -20,8 +20,35 @@
#
# Defining FD_SIZE_1MB on the build command line can override this.
#
+# A firmware binary built for the default 2MB flash size, and a firmware binary
+# built with FD_SIZE_1MB defined, use the same variable store layout.
+#
+# Defining FD_SIZE_4MB results in a different (much larger) variable store
+# structure that is incompatible with both the default and the FD_SIZE_1MB
+# firmware binaries.
+#
DEFINE BLOCK_SIZE = 0x1000
+
+!ifdef $(FD_SIZE_4MB)
+
+DEFINE VARS_SIZE = 0x80000
+DEFINE VARS_BLOCKS = 0x80
+DEFINE VARS_LIVE_SIZE = 0x3E000
+DEFINE VARS_SPARE_SIZE = 0x40000
+
+DEFINE FW_BASE_ADDRESS = 0xFFC00000
+DEFINE FW_SIZE = 0x00400000
+DEFINE FW_BLOCKS = 0x400
+DEFINE CODE_BASE_ADDRESS = 0xFFC80000
+DEFINE CODE_SIZE = 0x00380000
+DEFINE CODE_BLOCKS = 0x380
+DEFINE FVMAIN_SIZE = 0x0034C000
+DEFINE SECFV_OFFSET = 0x003CC000
+DEFINE SECFV_SIZE = 0x34000
+
+!else
+
DEFINE VARS_SIZE = 0x20000
DEFINE VARS_BLOCKS = 0x20
DEFINE VARS_LIVE_SIZE = 0xE000
@@ -53,6 +80,8 @@
!endif
+!endif
+
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize = $(FW_SIZE)
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE)
diff --git a/OvmfPkg/VarStore.fdf.inc b/OvmfPkg/VarStore.fdf.inc
index ce901c0109b1..7325b698157d 100644
--- a/OvmfPkg/VarStore.fdf.inc
+++ b/OvmfPkg/VarStore.fdf.inc
@@ -15,7 +15,11 @@
#
##
+!ifdef $(FD_SIZE_4MB)
+0x00000000|0x0003e000
+!else
0x00000000|0x0000e000
+!endif
#NV_VARIABLE_STORE
DATA = {
## This is the EFI_FIRMWARE_VOLUME_HEADER
@@ -27,14 +31,33 @@
# { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
+!ifdef $(FD_SIZE_4MB)
+ # FvLength: 0x80000
+ 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00,
+!else
# FvLength: 0x20000
0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
+!endif
# Signature "_FVH" # Attributes
0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
- # HeaderLength # CheckSum # ExtHeaderOffset #Reserved #Revision
- 0x48, 0x00, 0x19, 0xF9, 0x00, 0x00, 0x00, 0x02,
+ # HeaderLength
+ 0x48, 0x00,
+!ifdef $(FD_SIZE_4MB)
+ # CheckSum
+ 0xB3, 0xF8,
+!else
+ # CheckSum
+ 0x19, 0xF9,
+!endif
+ # ExtHeaderOffset #Reserved #Revision
+ 0x00, 0x00, 0x00, 0x02,
+!ifdef $(FD_SIZE_4MB)
+ # Blockmap[0]: 0x80 Blocks * 0x1000 Bytes / Block
+ 0x80, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
+!else
# Blockmap[0]: 0x20 Blocks * 0x1000 Bytes / Block
0x20, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
+!endif
# Blockmap[1]: End
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
## This is the VARIABLE_STORE_HEADER
@@ -44,18 +67,33 @@
# { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
+!ifdef $(FD_SIZE_4MB)
+ # Size: 0x3e000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
+ # 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3dfb8
+ # This can speed up the Variable Dispatch a bit.
+ 0xB8, 0xDF, 0x03, 0x00,
+!else
# Size: 0xe000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
# 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0xdfb8
# This can speed up the Variable Dispatch a bit.
0xB8, 0xDF, 0x00, 0x00,
+!endif
# FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}
+!ifdef $(FD_SIZE_4MB)
+0x0003e000|0x00001000
+!else
0x0000e000|0x00001000
+!endif
#NV_EVENT_LOG
+!ifdef $(FD_SIZE_4MB)
+0x0003f000|0x00001000
+!else
0x0000f000|0x00001000
+!endif
#NV_FTW_WORKING
DATA = {
# EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
@@ -68,5 +106,9 @@
0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}
+!ifdef $(FD_SIZE_4MB)
+0x00040000|0x00040000
+!else
0x00010000|0x00010000
+!endif
#NV_FTW_SPARE
--
2.9.3
next prev parent reply other threads:[~2017-04-29 20:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-29 20:14 [PATCH 0/3] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, and for future proofing Laszlo Ersek
2017-04-29 20:14 ` [PATCH 1/3] OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros Laszlo Ersek
2017-04-29 20:14 ` Laszlo Ersek [this message]
2017-04-30 0:48 ` [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK Jordan Justen
2017-04-30 14:42 ` Laszlo Ersek
2017-04-30 21:16 ` Jordan Justen
2017-05-01 10:51 ` Laszlo Ersek
2017-05-01 17:15 ` Jordan Justen
2017-05-01 17:23 ` Jordan Justen
2017-05-01 18:40 ` Laszlo Ersek
2017-05-01 19:20 ` Jordan Justen
2017-05-01 23:07 ` Laszlo Ersek
2017-05-01 23:38 ` Jordan Justen
2017-05-02 14:39 ` Laszlo Ersek
2017-05-02 18:22 ` Jordan Justen
2017-05-02 19:31 ` Laszlo Ersek
2017-05-02 21:45 ` Jordan Justen
2017-05-03 13:46 ` Laszlo Ersek
2017-05-01 0:06 ` Laszlo Ersek
2017-04-29 20:15 ` [PATCH 3/3] OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170429201500.18496-3-lersek@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox