public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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




  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