2014-07-22 23:57:01 +02:00
|
|
|
## @file
|
|
|
|
# FDF include file that defines the main macros and sets the dependent PCDs.
|
|
|
|
#
|
|
|
|
# Copyright (C) 2014, Red Hat, Inc.
|
|
|
|
# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
|
|
|
|
#
|
|
|
|
# This program and the accompanying materials are licensed and made available
|
|
|
|
# under the terms and conditions of the BSD License which accompanies this
|
|
|
|
# distribution. The full text of the license may be found at
|
|
|
|
# http://opensource.org/licenses/bsd-license.php
|
|
|
|
#
|
|
|
|
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
|
|
|
|
# IMPLIED.
|
|
|
|
#
|
|
|
|
##
|
|
|
|
|
|
|
|
DEFINE BLOCK_SIZE = 0x1000
|
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
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>
2017-04-29 03:37:41 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# A firmware binary built with FD_SIZE_IN_KB=1024, and a firmware binary built
|
|
|
|
# with FD_SIZE_IN_KB=2048, use the same variable store layout.
|
|
|
|
#
|
|
|
|
# Setting FD_SIZE_IN_KB to 4096 results in a different (much larger) variable
|
|
|
|
# store structure that is incompatible with both of the above-mentioned
|
|
|
|
# firmware binaries.
|
|
|
|
#
|
|
|
|
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
|
2014-07-22 23:57:01 +02:00
|
|
|
DEFINE VARS_SIZE = 0x20000
|
|
|
|
DEFINE VARS_BLOCKS = 0x20
|
2017-04-29 03:35:23 +02:00
|
|
|
DEFINE VARS_LIVE_SIZE = 0xE000
|
|
|
|
DEFINE VARS_SPARE_SIZE = 0x10000
|
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
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>
2017-04-29 03:37:41 +02:00
|
|
|
!endif
|
2014-07-22 23:57:01 +02:00
|
|
|
|
2017-05-03 17:54:49 +02:00
|
|
|
!if $(FD_SIZE_IN_KB) == 1024
|
2014-07-22 23:57:01 +02:00
|
|
|
DEFINE FW_BASE_ADDRESS = 0xFFF00000
|
|
|
|
DEFINE FW_SIZE = 0x00100000
|
|
|
|
DEFINE FW_BLOCKS = 0x100
|
|
|
|
DEFINE CODE_BASE_ADDRESS = 0xFFF20000
|
|
|
|
DEFINE CODE_SIZE = 0x000E0000
|
|
|
|
DEFINE CODE_BLOCKS = 0xE0
|
|
|
|
DEFINE FVMAIN_SIZE = 0x000CC000
|
|
|
|
DEFINE SECFV_OFFSET = 0x000EC000
|
|
|
|
DEFINE SECFV_SIZE = 0x14000
|
2017-05-03 17:54:49 +02:00
|
|
|
!endif
|
2014-07-22 23:57:01 +02:00
|
|
|
|
2017-05-03 17:54:49 +02:00
|
|
|
!if $(FD_SIZE_IN_KB) == 2048
|
2014-07-22 23:57:01 +02:00
|
|
|
DEFINE FW_BASE_ADDRESS = 0xFFE00000
|
|
|
|
DEFINE FW_SIZE = 0x00200000
|
|
|
|
DEFINE FW_BLOCKS = 0x200
|
|
|
|
DEFINE CODE_BASE_ADDRESS = 0xFFE20000
|
|
|
|
DEFINE CODE_SIZE = 0x001E0000
|
|
|
|
DEFINE CODE_BLOCKS = 0x1E0
|
|
|
|
DEFINE FVMAIN_SIZE = 0x001AC000
|
|
|
|
DEFINE SECFV_OFFSET = 0x001CC000
|
|
|
|
DEFINE SECFV_SIZE = 0x34000
|
|
|
|
!endif
|
|
|
|
|
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
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>
2017-04-29 03:37:41 +02:00
|
|
|
!if $(FD_SIZE_IN_KB) == 4096
|
|
|
|
DEFINE VARS_SIZE = 0x84000
|
|
|
|
DEFINE VARS_BLOCKS = 0x84
|
|
|
|
DEFINE VARS_LIVE_SIZE = 0x40000
|
|
|
|
DEFINE VARS_SPARE_SIZE = 0x42000
|
|
|
|
|
|
|
|
DEFINE FW_BASE_ADDRESS = 0xFFC00000
|
|
|
|
DEFINE FW_SIZE = 0x00400000
|
|
|
|
DEFINE FW_BLOCKS = 0x400
|
|
|
|
DEFINE CODE_BASE_ADDRESS = 0xFFC84000
|
|
|
|
DEFINE CODE_SIZE = 0x0037C000
|
|
|
|
DEFINE CODE_BLOCKS = 0x37C
|
|
|
|
DEFINE FVMAIN_SIZE = 0x00348000
|
|
|
|
DEFINE SECFV_OFFSET = 0x003CC000
|
|
|
|
DEFINE SECFV_SIZE = 0x34000
|
|
|
|
!endif
|
|
|
|
|
2014-07-22 23:57:01 +02:00
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS)
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize = $(FW_SIZE)
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE)
|
|
|
|
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase = $(FW_BASE_ADDRESS)
|
2017-04-29 03:35:23 +02:00
|
|
|
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize = $(VARS_LIVE_SIZE)
|
2014-07-22 23:57:01 +02:00
|
|
|
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize = $(BLOCK_SIZE)
|
|
|
|
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize
|
|
|
|
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize = $(BLOCK_SIZE)
|
|
|
|
|
|
|
|
SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
|
2017-04-29 03:35:23 +02:00
|
|
|
SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize = $(VARS_SPARE_SIZE)
|
OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).
DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.
Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.
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@19036 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:20 +01:00
|
|
|
|
|
|
|
DEFINE MEMFD_BASE_ADDRESS = 0x800000
|