audk/OvmfPkg/VarStore.fdf.inc

116 lines
3.8 KiB
PHP
Raw Normal View History

## @file
# FDF include file with Layout Regions that define an empty variable store.
#
# Copyright (C) 2014, Red Hat, Inc.
# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
##
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) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
0x00000000|0x0000e000
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
!if $(FD_SIZE_IN_KB) == 4096
0x00000000|0x00040000
!endif
#NV_VARIABLE_STORE
DATA = {
## This is the EFI_FIRMWARE_VOLUME_HEADER
# ZeroVector []
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
# FileSystemGuid: gEfiSystemNvDataFvGuid =
# { 0xFFF12B8D, 0x7696, 0x4C8B,
# { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
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) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
# FvLength: 0x20000
0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
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
!if $(FD_SIZE_IN_KB) == 4096
# FvLength: 0x84000
0x00, 0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00,
!endif
# Signature "_FVH" # Attributes
0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
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
# HeaderLength
0x48, 0x00,
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
# CheckSum
0x19, 0xF9,
!endif
!if $(FD_SIZE_IN_KB) == 4096
# CheckSum
0xAF, 0xB8,
!endif
# ExtHeaderOffset #Reserved #Revision
0x00, 0x00, 0x00, 0x02,
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
# Blockmap[0]: 0x20 Blocks * 0x1000 Bytes / Block
0x20, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
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
!if $(FD_SIZE_IN_KB) == 4096
# Blockmap[0]: 0x84 Blocks * 0x1000 Bytes / Block
0x84, 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
OvmfPkg: simplify VARIABLE_STORE_HEADER generation Before the merger of the authenticated and non-authenticated variable drivers (commit fa0737a839d0), 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>
2016-02-05 20:35:30 +01:00
# It is compatible with SECURE_BOOT_ENABLE == FALSE as well.
# Signature: gEfiAuthenticatedVariableGuid =
# { 0xaaf32c78, 0x947b, 0x439a,
# { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
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) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
# 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,
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
!if $(FD_SIZE_IN_KB) == 4096
# Size: 0x40000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
# 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3ffb8
# This can speed up the Variable Dispatch a bit.
0xB8, 0xFF, 0x03, 0x00,
!endif
# FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}
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) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
0x0000e000|0x00001000
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
!if $(FD_SIZE_IN_KB) == 4096
0x00040000|0x00001000
!endif
#NV_EVENT_LOG
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) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
0x0000f000|0x00001000
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
!if $(FD_SIZE_IN_KB) == 4096
0x00041000|0x00001000
!endif
#NV_FTW_WORKING
DATA = {
# EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid =
# { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
# Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
# WriteQueueSize: UINT64
0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
}
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) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
0x00010000|0x00010000
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
!if $(FD_SIZE_IN_KB) == 4096
0x00042000|0x00042000
!endif
#NV_FTW_SPARE