2010-02-24 00:58:38 +01:00
|
|
|
## @file
|
2009-05-27 23:10:18 +02:00
|
|
|
# Open Virtual Machine Firmware: FDF
|
|
|
|
|
#
|
2019-03-15 03:34:38 +01:00
|
|
|
# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.<BR>
|
OvmfPkg: use StatusCode Router and Handler from MdeModulePkg
In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_SERVICES.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.
These allow PEIMs and DXE (and later) modules to report status codes.
Currently OvmfPkg uses modules from under
"IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above
abstractions (PPI and PROTOCOL) directly, and write the status codes, as
they are reported, to the serial port or to a memory buffer. This is
called "handling" the status codes.
In the Platform Init v1.4a spec,
- Volume 3 "7.2.2 Report Status Code Handler PPI" defines
EFI_PEI_RSC_HANDLER_PPI,
- Volume 3 "7.2.1 Report Status Code Handler Protocol" defines
EFI_RSC_HANDLER_PROTOCOL.
These allow several PEIMs and runtime DXE drivers to register callbacks
for status code handling.
MdeModulePkg offers a PEIM under
"MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both
EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE
driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe"
that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL.
MdeModulePkg also offers status code handler modules under
MdeModulePkg/Universal/StatusCodeHandler/ that depend on
EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively.
The StatusCodeHandler modules register themselves with
ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI /
EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code
through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches
the phase-matching ReportStatusCodeRouter module first, which in turn
passes the status code to the pre-registered, phase-matching
StatusCodeHandler module.
The status code handling in the StatusCodeHandler modules is identical to
the one currently provided by the IntelFrameworkModulePkg modules. Replace
the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can
decrease our dependency on IntelFrameworkModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63
[jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02 19:25:10 +02:00
|
|
|
# (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR>
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2019-04-04 01:06:33 +02:00
|
|
|
# SPDX-License-Identifier: BSD-2-Clause-Patent
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2010-02-24 00:58:38 +01:00
|
|
|
##
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
################################################################################
|
2013-11-12 19:34:02 +01:00
|
|
|
|
|
|
|
|
[Defines]
|
2014-07-22 23:57:01 +02:00
|
|
|
!include OvmfPkg.fdf.inc
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Build the variable store and the firmware code as one unified flash device
|
|
|
|
|
# image.
|
|
|
|
|
#
|
2013-11-12 19:34:20 +01:00
|
|
|
[FD.OVMF]
|
2014-07-22 23:57:01 +02:00
|
|
|
BaseAddress = $(FW_BASE_ADDRESS)
|
|
|
|
|
Size = $(FW_SIZE)
|
2013-11-12 19:34:20 +01:00
|
|
|
ErasePolarity = 1
|
2014-07-22 23:57:01 +02:00
|
|
|
BlockSize = $(BLOCK_SIZE)
|
|
|
|
|
NumBlocks = $(FW_BLOCKS)
|
2013-11-12 19:34:20 +01:00
|
|
|
|
2014-07-22 23:56:53 +02:00
|
|
|
!include VarStore.fdf.inc
|
2013-11-12 19:34:20 +01:00
|
|
|
|
2014-07-22 23:57:01 +02:00
|
|
|
$(VARS_SIZE)|$(FVMAIN_SIZE)
|
2010-06-26 00:23:22 +02:00
|
|
|
FV = FVMAIN_COMPACT
|
|
|
|
|
|
2014-07-22 23:57:01 +02:00
|
|
|
$(SECFV_OFFSET)|$(SECFV_SIZE)
|
2010-01-04 17:17:59 +01:00
|
|
|
FV = SECFV
|
2012-10-04 17:41:15 +02:00
|
|
|
|
2014-07-22 23:57:01 +02:00
|
|
|
#
|
|
|
|
|
# Build the variable store and the firmware code as separate flash device
|
|
|
|
|
# images.
|
|
|
|
|
#
|
|
|
|
|
[FD.OVMF_VARS]
|
|
|
|
|
BaseAddress = $(FW_BASE_ADDRESS)
|
|
|
|
|
Size = $(VARS_SIZE)
|
|
|
|
|
ErasePolarity = 1
|
|
|
|
|
BlockSize = $(BLOCK_SIZE)
|
|
|
|
|
NumBlocks = $(VARS_BLOCKS)
|
|
|
|
|
|
|
|
|
|
!include VarStore.fdf.inc
|
|
|
|
|
|
|
|
|
|
[FD.OVMF_CODE]
|
|
|
|
|
BaseAddress = $(CODE_BASE_ADDRESS)
|
|
|
|
|
Size = $(CODE_SIZE)
|
|
|
|
|
ErasePolarity = 1
|
|
|
|
|
BlockSize = $(BLOCK_SIZE)
|
|
|
|
|
NumBlocks = $(CODE_BLOCKS)
|
|
|
|
|
|
|
|
|
|
0x00000000|$(FVMAIN_SIZE)
|
2012-10-04 17:41:15 +02:00
|
|
|
FV = FVMAIN_COMPACT
|
|
|
|
|
|
2014-07-22 23:57:01 +02:00
|
|
|
$(FVMAIN_SIZE)|$(SECFV_SIZE)
|
2012-10-04 17:41:15 +02:00
|
|
|
FV = SECFV
|
2010-01-04 17:17:59 +01:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
2010-01-04 17:17:59 +01:00
|
|
|
|
|
|
|
|
[FD.MEMFD]
|
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
|
|
|
BaseAddress = $(MEMFD_BASE_ADDRESS)
|
2018-05-28 18:20:39 +02:00
|
|
|
Size = 0xC00000
|
2009-05-27 23:10:18 +02:00
|
|
|
ErasePolarity = 1
|
|
|
|
|
BlockSize = 0x10000
|
2018-05-28 18:20:39 +02:00
|
|
|
NumBlocks = 0xC0
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2014-01-21 20:38:34 +01:00
|
|
|
0x000000|0x006000
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
|
|
|
|
|
|
2014-03-04 09:03:23 +01:00
|
|
|
0x006000|0x001000
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
|
|
|
|
|
|
OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
BaseExtractGuidedSectionLib.inf
The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.
BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.
LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is
gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF
When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
GetExtractGuidedSectionHandlerInfo()
PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS
Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:
SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
SecStartupPhase2()
FindAndReportEntryPoints()
FindPeiCoreImageBase()
DecompressMemFvs()
ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]
Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.
This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).
This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:
crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
vs.
crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.
Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.
Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between
PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
and
PcdOvmfSecPeiTempRamBase == 8256 KB.
- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).
- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
supported and we're not currently resuming.
The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):
sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32
PcdMaximumGuidedExtractHandler * (
sizeof(GUID) + // 16
sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8
sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8
)
OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.
Regarding the lifecycle of the new area:
(a) when and how it is initialized after first boot of the VM
The library linked into SecMain finds that the area lacks the signature.
It initializes the signature, plus the rest of the structure. This is
independent of S3 support.
Consumption of the area is also limited to SEC (but consumption does
depend on full-config-boot).
(b) how it is protected from memory allocations during DXE
It is not, in the general case; and we don't need to. Nothing else links
against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.
(c) how it is protected from the OS
When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().
When S3 is not supported, the range is not protected.
(d) how it is accessed on the S3 resume path
Examined by the library linked into SecMain. Registrations update the
table in-place (based on GUID matches).
(e) how it is accessed on the warm reset path
If S3 is enabled, then the OS won't damage the table (due to (c)), hence
see (d).
If S3 is unsupported, then the OS may or may not overwrite the
signature. (It likely will.) This is identical to the pre-patch status.
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@15433 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-05 23:26:09 +02:00
|
|
|
0x007000|0x001000
|
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
|
|
|
|
|
|
OvmfPkg: restore temporary SEC/PEI RAM size to 64KB
(1) In the PEI phase, the PCD database is maintained in a GUID HOB. In
OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI),
so that all other PEIMs can use dynamic PCDs. Consequently,
- the PCD GUID HOB is initially allocated from the temporary SEC/PEI
heap,
- whenever we introduce a dynamic PCD to a PEIM built into OVMF such
that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and
its temporary heap footprint) grow.
I've noticed that, if we add just one more dynamic PCD to the PEI
phase, then in the X64 build,
- we get very close to the half of the temporary heap (i.e., 8192
bytes),
- obscure PEI phase hangs or DXE core initialization failures
(ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and
FD_SIZE_4MB builds of X64 OVMF.
(2) I've found that commit
2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update algorithm to calculate
optimal settings", 2017-09-27)
introduced a large (16KB) stack allocation:
> The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
> MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation.
> ...
> +#define SCRATCH_BUFFER_SIZE (4 * SIZE_4KB)
> ...
> @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings (
> ...
> + UINT8 Scratch[SCRATCH_BUFFER_SIZE];
(3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit
7cb6b0e06809 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to
0x810000", 2014-01-21)
Of that, the upper 16KB half is stack (growing down), and the lower
16KB half is heap.
Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in
QemuInitializeRam(), cause the Scratch array to overflow the entire
stack (heading towards lower addresses), and corrupt the heap below
the stack. It turns out that the total stack demand is about 24KB, so
the overflow is able to corrupt the upper 8KB of the heap. If that
part of the heap is actually used (for example because we grow the PCD
GUID HOB sufficiently), mayhem ensues.
(4) Right after commit 7cb6b0e06809 (see above), there would be no room
left above the 32KB temp SEC/PEI RAM. However, given more recent
commits
45d870815156 ("OvmfPkg/PlatformPei: rebase and resize the permanent
PEI memory for S3", 2016-07-13)
6b04cca4d697 ("OvmfPkg: remove PcdS3AcpiReservedMemoryBase,
PcdS3AcpiReservedMemorySize", 2016-07-12)
we can now restore the temp SEC/PEI RAM size to the original
(pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI
stack, which accommodates the ~24KB demand mentioned in (3).
(Prior patches in this series will let us monitor the stack usage in
the future.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747
Ref: http://mid.mail-archive.com/a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com
Ref: http://mid.mail-archive.com/03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-10-24 17:21:25 +02:00
|
|
|
0x010000|0x010000
|
2014-01-21 20:38:43 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
|
|
|
|
|
|
2014-01-21 20:39:13 +01:00
|
|
|
0x020000|0x0E0000
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
|
|
|
|
|
FV = PEIFV
|
|
|
|
|
|
2018-05-28 18:20:39 +02:00
|
|
|
0x100000|0xB00000
|
2014-01-21 20:39:13 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
|
|
|
|
|
FV = DXEFV
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
################################################################################
|
2010-01-04 17:17:59 +01:00
|
|
|
|
|
|
|
|
[FV.SECFV]
|
OvmfPkg: add a Name GUID to each Firmware Volume
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).
Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):
- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
directly, see below).
- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
address. This object is not followed by any
EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
specifies the Name GUID for the firmware volume.
The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
in the Build directory as a separate file (20 bytes in size):
Build/Ovmf*/*_GCC*/FV/*.ext
- The new data consume 48 bytes in the following volumes: SECFV,
FVMAIN_COMPACT, DXEFV. They comprise:
- 16 padding bytes,
- EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
fields, and Type=EFI_FV_FILETYPE_FFS_PAD),
- EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),
- 4 padding bytes.
(The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
immediately past EFI_FIRMWARE_VOLUME_HEADER.)
The sizes of the firmware volumes don't change, only their internal
usages grow by 48 bytes. I verified that the statements and calculations
in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.
- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
internal padding at the moment to accomodate the above structures
without a growth in usage.
In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@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>
2016-07-12 16:48:47 +02:00
|
|
|
FvNameGuid = 763BED0D-DE9F-48F5-81F1-3E90E1B1A015
|
2010-01-04 17:17:59 +01:00
|
|
|
BlockSize = 0x1000
|
|
|
|
|
FvAlignment = 16
|
|
|
|
|
ERASE_POLARITY = 1
|
|
|
|
|
MEMORY_MAPPED = TRUE
|
|
|
|
|
STICKY_WRITE = TRUE
|
|
|
|
|
LOCK_CAP = TRUE
|
|
|
|
|
LOCK_STATUS = TRUE
|
|
|
|
|
WRITE_DISABLED_CAP = TRUE
|
|
|
|
|
WRITE_ENABLED_CAP = TRUE
|
|
|
|
|
WRITE_STATUS = TRUE
|
|
|
|
|
WRITE_LOCK_CAP = TRUE
|
|
|
|
|
WRITE_LOCK_STATUS = TRUE
|
|
|
|
|
READ_DISABLED_CAP = TRUE
|
|
|
|
|
READ_ENABLED_CAP = TRUE
|
|
|
|
|
READ_STATUS = TRUE
|
|
|
|
|
READ_LOCK_CAP = TRUE
|
|
|
|
|
READ_LOCK_STATUS = TRUE
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2010-01-04 17:17:59 +01:00
|
|
|
# SEC Phase modules
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2010-01-04 17:17:59 +01:00
|
|
|
# The code in this FV handles the initial firmware startup, and
|
2014-01-21 20:39:13 +01:00
|
|
|
# decompresses the PEI and DXE FVs which handles the rest of the boot sequence.
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2010-01-04 17:17:59 +01:00
|
|
|
INF OvmfPkg/Sec/SecMain.inf
|
|
|
|
|
|
2014-08-19 01:04:00 +02:00
|
|
|
INF RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
|
2010-01-04 17:17:59 +01:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
2014-01-21 20:39:13 +01:00
|
|
|
[FV.PEIFV]
|
OvmfPkg: add a Name GUID to each Firmware Volume
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).
Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):
- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
directly, see below).
- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
address. This object is not followed by any
EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
specifies the Name GUID for the firmware volume.
The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
in the Build directory as a separate file (20 bytes in size):
Build/Ovmf*/*_GCC*/FV/*.ext
- The new data consume 48 bytes in the following volumes: SECFV,
FVMAIN_COMPACT, DXEFV. They comprise:
- 16 padding bytes,
- EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
fields, and Type=EFI_FV_FILETYPE_FFS_PAD),
- EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),
- 4 padding bytes.
(The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
immediately past EFI_FIRMWARE_VOLUME_HEADER.)
The sizes of the firmware volumes don't change, only their internal
usages grow by 48 bytes. I verified that the statements and calculations
in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.
- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
internal padding at the moment to accomodate the above structures
without a growth in usage.
In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@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>
2016-07-12 16:48:47 +02:00
|
|
|
FvNameGuid = 6938079B-B503-4E3D-9D24-B28337A25806
|
2010-01-04 17:17:59 +01:00
|
|
|
BlockSize = 0x10000
|
|
|
|
|
FvAlignment = 16
|
2009-05-27 23:10:18 +02:00
|
|
|
ERASE_POLARITY = 1
|
|
|
|
|
MEMORY_MAPPED = TRUE
|
|
|
|
|
STICKY_WRITE = TRUE
|
|
|
|
|
LOCK_CAP = TRUE
|
|
|
|
|
LOCK_STATUS = TRUE
|
|
|
|
|
WRITE_DISABLED_CAP = TRUE
|
|
|
|
|
WRITE_ENABLED_CAP = TRUE
|
|
|
|
|
WRITE_STATUS = TRUE
|
|
|
|
|
WRITE_LOCK_CAP = TRUE
|
|
|
|
|
WRITE_LOCK_STATUS = TRUE
|
|
|
|
|
READ_DISABLED_CAP = TRUE
|
|
|
|
|
READ_ENABLED_CAP = TRUE
|
|
|
|
|
READ_STATUS = TRUE
|
|
|
|
|
READ_LOCK_CAP = TRUE
|
|
|
|
|
READ_LOCK_STATUS = TRUE
|
|
|
|
|
|
2010-01-04 17:17:59 +01:00
|
|
|
APRIORI PEI {
|
|
|
|
|
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# PEI Phase modules
|
|
|
|
|
#
|
|
|
|
|
INF MdeModulePkg/Core/Pei/PeiMain.inf
|
|
|
|
|
INF MdeModulePkg/Universal/PCD/Pei/Pcd.inf
|
OvmfPkg: use StatusCode Router and Handler from MdeModulePkg
In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_SERVICES.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.
These allow PEIMs and DXE (and later) modules to report status codes.
Currently OvmfPkg uses modules from under
"IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above
abstractions (PPI and PROTOCOL) directly, and write the status codes, as
they are reported, to the serial port or to a memory buffer. This is
called "handling" the status codes.
In the Platform Init v1.4a spec,
- Volume 3 "7.2.2 Report Status Code Handler PPI" defines
EFI_PEI_RSC_HANDLER_PPI,
- Volume 3 "7.2.1 Report Status Code Handler Protocol" defines
EFI_RSC_HANDLER_PROTOCOL.
These allow several PEIMs and runtime DXE drivers to register callbacks
for status code handling.
MdeModulePkg offers a PEIM under
"MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both
EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE
driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe"
that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL.
MdeModulePkg also offers status code handler modules under
MdeModulePkg/Universal/StatusCodeHandler/ that depend on
EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively.
The StatusCodeHandler modules register themselves with
ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI /
EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code
through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches
the phase-matching ReportStatusCodeRouter module first, which in turn
passes the status code to the pre-registered, phase-matching
StatusCodeHandler module.
The status code handling in the StatusCodeHandler modules is identical to
the one currently provided by the IntelFrameworkModulePkg modules. Replace
the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can
decrease our dependency on IntelFrameworkModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63
[jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02 19:25:10 +02:00
|
|
|
INF MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
|
|
|
|
|
INF MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
|
2010-01-04 17:17:59 +01:00
|
|
|
INF OvmfPkg/PlatformPei/PlatformPei.inf
|
|
|
|
|
INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
|
2014-03-04 09:03:06 +01:00
|
|
|
INF UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
|
OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the
LockBoxLib instance with SMRAM access for the PEI phase.
Said library instance must, and can, access the LockBox data in SMRAM
directly if it is invoked before SMBASE relocation / SMI handler
installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the
platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI.
OVMF satisfies the description in SVN r18823 ("MdeModulePkg:
SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF,
only S3Resume2Pei links against SmmLockBoxPeiLib.
Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI
interface, enabling SmmLockBoxPeiLib to work; we can omit including
"UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf".
The load / installation order of S3Resume2Pei and SmmAccessPei is
indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its
installation (which happens during PEI), but S3Resume2Pei accesses the HOB
only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act
of PEI.
MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in
SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to
prevent VS20xx from warning about the (otherwise fully intentional)
truncation in the UINT8 casts. (Warnings reported by Michael Kinney.)
Cc: Michael Kinney <michael.d.kinney@intel.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: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:38 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
|
INF OvmfPkg/SmmAccess/SmmAccessPei.inf
|
|
|
|
|
!endif
|
OvmfPkg: include UefiCpuPkg/CpuMpPei
In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
those already used by CpuDxe:
- PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
control whether CpuMpPei performs microcode update. If the region size
is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
region size to zero by default, which is appropriate for OVMF.
- PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
(with PAUSE). The latter PCD is only relevant if the former PCD is 2
(MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
we choose HLT. That's the default set by UefiCpuPkg.dec.
Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib
technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703
- git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import
PeiCpuExceptionHandlerLib module"), part of the series linked above.
Jeff recommended to resolve CpuExceptionHandlerLib to
PeiCpuExceptionHandlerLib for all PEIMs:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477
Since at the moment we have no resolution in place that would cover this
for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]),
it's easy to do.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-06 18:09:16 +02:00
|
|
|
INF UefiCpuPkg/CpuMpPei/CpuMpPei.inf
|
2010-01-04 17:17:59 +01:00
|
|
|
|
2018-02-22 14:20:58 +01:00
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
|
INF OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
|
2018-02-22 15:26:34 +01:00
|
|
|
INF SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf
|
2018-02-22 14:20:58 +01:00
|
|
|
!endif
|
|
|
|
|
|
2010-02-25 22:53:06 +01:00
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
[FV.DXEFV]
|
OvmfPkg: disable build-time relocation for DXEFV modules
When the GenFv utility from BaseTools composes a firmware volume, it
checks whether modules in the firmware volume are subject to build-time
relocation. The primary indication for relocation is whether the firmware
volume has a nonzero base address, according to the [FD] section(s) in the
FDF file that refer to the firmware volume.
The idea behind build-time relocation is that XIP (execute in place)
modules will not be relocated at boot-time:
- Pre-DXE phase modules generally execute in place.
(OVMF is no exception, despite the fact that we have writeable memory
even in SEC: PEI_CORE and PEIMs run in-place from PEIFV, after SEC
decompresses PEIFV and DXEFV from FVMAIN_COMPACT (flash) to RAM.
PEI_CORE and the PEIMs are relocated at boot-time only after PlatformPei
installs the permanent PEI RAM, and the RAM migration occurs.)
- Modules dispatched by the DXE Core are generally relocated at boot-time.
However, this is not necessarily so. Quoting Liming from
<https://lists.01.org/pipermail/edk2-devel/2017-July/012053.html>:
> PI spec has no limitation that XIP is for PEIM only. DXE driver may be
> built as XIP for other purpose. For example, if DXE driver image address
> is not zero, DxeCore will try allocating the preferred address and load
> it. In another case, once DXE driver is relocated at build time, DxeCore
> will dispatch it and start it directly without loading, it may save boot
> performance.
Therefore GenFv relocates even DXE and UEFI driver modules if the
containing firmware volume has a nonzero base address.
In OVMF, this is the case for both PEIV and DXEFV:
> [FD.MEMFD]
> BaseAddress = $(MEMFD_BASE_ADDRESS)
> Size = 0xB00000
> ErasePolarity = 1
> BlockSize = 0x10000
> NumBlocks = 0xB0
> ...
> 0x020000|0x0E0000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
> FV = PEIFV
>
> 0x100000|0xA00000
> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
> FV = DXEFV
While the build-time relocation certainly makes sense for PEIFV (see
above), the reasons for which we specify DXEFV under [FD.MEMFD] are
weaker:
- we set the PcdOvmfDxeMemFvBase and PcdOvmfDxeMemFvSize PCDs here,
- and we ascertain that DXEFV, when decompressed by SEC from
FVMAIN_COMPACT, will fit into the area allotted here, at build time.
In other words, the build-time relocation of the modules in DXEFV is a
waste of resources. But, it gets worse:
Build-time relocation of an executable is only possible if the on-disk and
in-memory layouts are identical, i.e., if the sections of the PE/COFF
image adhere to the same alignment on disk and in memory. Put differently,
the FileAlignment and SectionAlignment headers must be equal.
For boot-time modules that we build as part of edk2, both alignment values
are 0x20 bytes. For runtime modules that we build as part of edk2, both
alignment values are 0x1000 bytes. This is why the DXEFV relocation,
albeit wasteful, is also successful every time.
Unfortunately, if we try to include a PE/COFF binary in DXEFV that
originates from outside of edk2, the DXEFV relocation can fail due to the
binary having unmatched FileAlignment and SectionAlignment headers. This
is precisely the case with the E3522X2.EFI network driver for the e1000
NIC, from Intel's BootUtil / PREBOOT.EXE distribution.
The solution is to use the FvForceRebase=FALSE override under [FV.DXEFV].
This tells GenFv not to perform build-time relocation on the firmware
volume, despite the FV having a nonzero base address.
In DXEFV we also have SMM drivers. Those are relocated at boot-time (into
SMRAM) unconditionally; SMRAM is always discovered at boot-time.
Kudos to Ard and Liming for the PE/COFF sections & relocations
explanation, and for the FvForceRebase=FALSE tip.
I regression-tested this change in the following configurations (all with
normal boot and S3 suspend/resume):
IA32, q35, SMM, Linux
IA32X64, q35, SMM, Linux
IA32X64, q35, SMM, Windows-8.1
X64, i440fx, no-SMM, Linux
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=615
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-06-28 20:20:17 +02:00
|
|
|
FvForceRebase = FALSE
|
OvmfPkg: add a Name GUID to each Firmware Volume
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).
Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):
- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
directly, see below).
- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
address. This object is not followed by any
EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
specifies the Name GUID for the firmware volume.
The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
in the Build directory as a separate file (20 bytes in size):
Build/Ovmf*/*_GCC*/FV/*.ext
- The new data consume 48 bytes in the following volumes: SECFV,
FVMAIN_COMPACT, DXEFV. They comprise:
- 16 padding bytes,
- EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
fields, and Type=EFI_FV_FILETYPE_FFS_PAD),
- EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),
- 4 padding bytes.
(The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
immediately past EFI_FIRMWARE_VOLUME_HEADER.)
The sizes of the firmware volumes don't change, only their internal
usages grow by 48 bytes. I verified that the statements and calculations
in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.
- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
internal padding at the moment to accomodate the above structures
without a growth in usage.
In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@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>
2016-07-12 16:48:47 +02:00
|
|
|
FvNameGuid = 7CB8BDC9-F8EB-4F34-AAEA-3EE4AF6516A1
|
2010-02-25 22:53:06 +01:00
|
|
|
BlockSize = 0x10000
|
|
|
|
|
FvAlignment = 16
|
|
|
|
|
ERASE_POLARITY = 1
|
|
|
|
|
MEMORY_MAPPED = TRUE
|
|
|
|
|
STICKY_WRITE = TRUE
|
|
|
|
|
LOCK_CAP = TRUE
|
|
|
|
|
LOCK_STATUS = TRUE
|
|
|
|
|
WRITE_DISABLED_CAP = TRUE
|
|
|
|
|
WRITE_ENABLED_CAP = TRUE
|
|
|
|
|
WRITE_STATUS = TRUE
|
|
|
|
|
WRITE_LOCK_CAP = TRUE
|
|
|
|
|
WRITE_LOCK_STATUS = TRUE
|
|
|
|
|
READ_DISABLED_CAP = TRUE
|
|
|
|
|
READ_ENABLED_CAP = TRUE
|
|
|
|
|
READ_STATUS = TRUE
|
|
|
|
|
READ_LOCK_CAP = TRUE
|
|
|
|
|
READ_LOCK_STATUS = TRUE
|
|
|
|
|
|
|
|
|
|
APRIORI DXE {
|
2013-08-19 06:15:36 +02:00
|
|
|
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
|
2010-02-25 22:53:06 +01:00
|
|
|
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
|
2017-07-06 15:26:45 +02:00
|
|
|
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
|
2015-11-30 19:49:03 +01:00
|
|
|
!if $(SMM_REQUIRE) == FALSE
|
2013-11-12 19:35:01 +01:00
|
|
|
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
|
2015-11-30 19:49:03 +01:00
|
|
|
!endif
|
2010-02-25 22:53:06 +01:00
|
|
|
}
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
|
|
|
|
# DXE Phase modules
|
|
|
|
|
#
|
|
|
|
|
INF MdeModulePkg/Core/Dxe/DxeMain.inf
|
|
|
|
|
|
OvmfPkg: use StatusCode Router and Handler from MdeModulePkg
In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_SERVICES.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.
These allow PEIMs and DXE (and later) modules to report status codes.
Currently OvmfPkg uses modules from under
"IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above
abstractions (PPI and PROTOCOL) directly, and write the status codes, as
they are reported, to the serial port or to a memory buffer. This is
called "handling" the status codes.
In the Platform Init v1.4a spec,
- Volume 3 "7.2.2 Report Status Code Handler PPI" defines
EFI_PEI_RSC_HANDLER_PPI,
- Volume 3 "7.2.1 Report Status Code Handler Protocol" defines
EFI_RSC_HANDLER_PROTOCOL.
These allow several PEIMs and runtime DXE drivers to register callbacks
for status code handling.
MdeModulePkg offers a PEIM under
"MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both
EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE
driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe"
that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL.
MdeModulePkg also offers status code handler modules under
MdeModulePkg/Universal/StatusCodeHandler/ that depend on
EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively.
The StatusCodeHandler modules register themselves with
ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI /
EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code
through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches
the phase-matching ReportStatusCodeRouter module first, which in turn
passes the status code to the pre-registered, phase-matching
StatusCodeHandler module.
The status code handling in the StatusCodeHandler modules is identical to
the one currently provided by the IntelFrameworkModulePkg modules. Replace
the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can
decrease our dependency on IntelFrameworkModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63
[jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02 19:25:10 +02:00
|
|
|
INF MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
|
|
|
|
|
|
|
|
|
|
INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
|
2010-01-04 17:17:59 +01:00
|
|
|
INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
|
2019-04-02 10:01:27 +02:00
|
|
|
INF OvmfPkg/8259InterruptControllerDxe/8259.inf
|
2009-12-09 03:18:21 +01:00
|
|
|
INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF UefiCpuPkg/CpuDxe/CpuDxe.inf
|
2019-04-02 10:01:27 +02:00
|
|
|
INF OvmfPkg/8254TimerDxe/8254Timer.inf
|
OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM
According to edk2 commit
"MdeModulePkg/PciBus: do not improperly degrade resource"
and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.
In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.
(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)
In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.
The driver added in this patch could be simplified based on the following
facts:
- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
the driver will exit immediately. Therefore the driver could be omitted
from the Ia32 build.
- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
was defined (because in that case the degradation would be justified).
On the other hand, if CSM_ENABLE was undefined, then the driver could be
included, and it could provide the hint unconditionally (without looking
for the Legacy BIOS protocol).
These short-cuts are not taken because they would increase the differences
between the OVMF DSC/FDF files. If we can manage without extreme
complexity, we should use dynamic logic (vs. build time configuration),
plus keep conditional compilation to a minimum.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-18 20:13:41 +02:00
|
|
|
INF OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
|
OvmfPkg: add PciHotPlugInitDxe
After IncompatiblePciDeviceSupportDxe, this is another small driver /
protocol implementation that tweaks the behavior of the PCI bus driver in
edk2.
The protocol is specified in the Platform Init Spec v1.4a, Volume 5,
Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This
implementation steers the PCI bus driver to reserve the following
resources ("padding") for each PCI bus, in addition to the BARs of the
devices on that PCI bus:
- 2MB of 64-bit non-prefetchable MMIO aperture,
- 512B of IO port space.
The goal is to reserve room for devices hot-plugged at runtime even if the
bridge receiving the device is empty at boot time.
The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is
actually only 1/8th of the PCI spec mandated reservation, but the
specified size of 4096 has proved wasteful (given the limited size of our
IO port space -- see commit bba734ab4c7c). Especially on Q35, where every
PCIe root port and downstream port qualifies as a separate bridge (capable
of accepting a single device).
Test results for this patch:
- regardless of our request for 64-bit MMIO reservation, it is downgraded
to 32-bit,
- although we request 512B alignment for the IO port space reservation,
the next upstream bridge rounds it up to 4096B.
Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
2016-06-30 20:16:06 +02:00
|
|
|
INF OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
|
2016-01-26 01:18:36 +01:00
|
|
|
INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
|
2009-10-20 05:44:25 +02:00
|
|
|
INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
|
2016-08-10 07:31:02 +02:00
|
|
|
INF MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/Metronome/Metronome.inf
|
2009-07-07 06:52:44 +02:00
|
|
|
INF PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2013-12-11 17:58:22 +01:00
|
|
|
INF OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
|
2016-03-12 18:03:33 +01:00
|
|
|
INF OvmfPkg/Virtio10Dxe/Virtio10.inf
|
2012-10-08 09:32:59 +02:00
|
|
|
INF OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
|
2012-10-18 19:07:48 +02:00
|
|
|
INF OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
|
2016-02-24 09:27:30 +01:00
|
|
|
INF OvmfPkg/VirtioRngDxe/VirtioRng.inf
|
2015-02-28 21:33:11 +01:00
|
|
|
INF OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
|
2014-10-29 07:48:50 +01:00
|
|
|
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
|
2014-10-29 07:51:42 +01:00
|
|
|
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
|
|
|
|
|
!if $(SECURE_BOOT_ENABLE) == TRUE
|
OvmfPkg: disable stale fork of SecureBootConfigDxe
OvmfPkg forked SecureBootConfigDxe from SecurityPkg in SVN r13635 (git
commit 8c71ec8f). Since then, the original (in
"SecurityPkg/VariableAuthenticated/SecureBootConfigDxe") has diverged
significantly.
The initial diff between the original and the fork, when the fork was made
(ie. at SVN r13635), reads as follows:
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr 2014-08-09 02:40:35.824851626 +0200
> @@ -51,7 +51,7 @@
> questionid = KEY_SECURE_BOOT_ENABLE,
> prompt = STRING_TOKEN(STR_SECURE_BOOT_PROMPT),
> help = STRING_TOKEN(STR_SECURE_BOOT_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
>
> @@ -158,7 +158,7 @@
> questionid = KEY_SECURE_BOOT_DELETE_PK,
> prompt = STRING_TOKEN(STR_DELETE_PK),
> help = STRING_TOKEN(STR_DELETE_PK_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
> endform;
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.577067027 +0200
> @@ -1,5 +1,8 @@
> ## @file
> -# Component name for SecureBoot configuration module.
> +# Component name for SecureBoot configuration module for OVMF.
> +#
> +# Need custom SecureBootConfigDxe for OVMF that does not force
> +# resets after PK changes since OVMF doesn't have persistent variables
> #
> # Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.599067153 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.578067033 +0200
> @@ -2559,7 +2559,7 @@
> NULL
> );
> } else {
> - *ActionRequest = EFI_BROWSER_ACTION_REQUEST_RESET;
> + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_SUBMIT;
> }
> break;
The commit message is not overly verbose:
OvmfPkg: Add custom SecureBootConfigDxe that doesn't reset
We don't force a platform reset for OVMF when PK is changed in custom
mode setup.
But the INF file hunk is telling:
Need custom SecureBootConfigDxe for OVMF that does not force resets
after PK changes since OVMF doesn't have persistent variables
We do have persistent variables now. Let's disable the (now obsolete)
OvmfPkg fork, and revert to the (well maintained) SecurityPkg-provided
config driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gary Lin <glin@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16191 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-02 10:08:05 +02:00
|
|
|
INF SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
!endif
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
|
|
|
|
|
INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
|
2016-06-28 21:09:53 +02:00
|
|
|
INF MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
|
|
|
|
|
INF MdeModulePkg/Application/UiApp/UiApp.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
|
2009-06-30 17:57:29 +02:00
|
|
|
INF MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
|
2016-03-30 23:49:37 +02:00
|
|
|
INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
|
OvmfPkg: enable SATA controller
In this patch, we replace the traditional IDE driver stack that comes from
PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers
from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible
with the previous one, but provides more protocols, on more kinds of
virtual hardware.
Remove:
- PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
(removing EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
Remove the dependent:
- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
(removing EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3])
As replacement, add:
- OvmfPkg/SataControllerDxe/SataControllerDxe.inf
(supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
(providing EFI_ATA_PASS_THRU_PROTOCOL,
EFI_EXT_SCSI_PASS_THRU_PROTOCOL)
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
(supplying EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3],
providing EFI_BLOCK_IO2PROTOCOL,
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL)
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: rewrote commit message]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-22 13:18:45 +02:00
|
|
|
INF OvmfPkg/SataControllerDxe/SataControllerDxe.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
|
2016-02-02 16:30:25 +01:00
|
|
|
INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
|
2013-08-12 04:24:32 +02:00
|
|
|
INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
|
2011-01-21 17:50:47 +01:00
|
|
|
INF MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2019-05-24 03:10:42 +02:00
|
|
|
INF OvmfPkg/SioBusDxe/SioBusDxe.inf
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == FALSE
|
2019-05-24 03:10:42 +02:00
|
|
|
INF MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
|
2011-10-26 09:08:32 +02:00
|
|
|
!endif
|
2019-05-24 03:10:42 +02:00
|
|
|
INF MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2011-08-14 00:54:37 +02:00
|
|
|
INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
|
|
|
|
|
INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
|
2012-05-31 01:15:00 +02:00
|
|
|
INF OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
INF RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
|
2014-03-04 09:03:50 +01:00
|
|
|
INF MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
|
2014-03-04 09:04:13 +01:00
|
|
|
INF MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
|
OvmfPkg: Install BGRT ACPI table
While debugging OS for ACPI BGRT support (especially on VMs),
it is very useful to have the EFI firmware (OVMF in most cases
which use Tianocore) to export the ACPI BGRT table.
This patch tries to add this support in OvmfPkg.
Tested this patch in the following environments:
1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host:
- Ensured that the BGRT logo is properly prepared and
can be viewed with user-space tools (like 'Gwenview' on KDE,
for example):
$ file /sys/firmware/acpi/bgrt/image
/sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x
58 x 24
2. On a Windows-10 VM Guest running on a Fedora-24 Host:
- Ensured that the BGRT ACPI table is properly prepared and can be
read with freeware tool like FirmwareTablesView:
==================================================
Signature : BGRT
Firmware Provider : ACPI
Length : 56
Revision : 1
Checksum : 129
OEM ID : INTEL
OEM Table ID : EDK2
OEM Revision : 0x00000002
Creator ID : 0x20202020
Creator Revision : 0x01000013
Description :
==================================================
Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table,
Windows 8 and Windows 10 first clear the screen, then display a blue,
slanted Windows picture above the rotating white boot animation. With the
BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue
Windows image is not displayed, and the rotating white boot animation is
shown between the firmware's original TianoCore boot splash and (optional)
"Start boot option" progress bar.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-01-06 10:47:15 +01:00
|
|
|
INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2016-04-06 07:58:40 +02:00
|
|
|
INF FatPkg/EnhancedFatDxe/Fat.inf
|
2017-09-08 14:41:48 +02:00
|
|
|
INF MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
|
2011-06-26 20:58:41 +02:00
|
|
|
|
2018-11-22 14:41:41 +01:00
|
|
|
!if $(TOOL_CHAIN_TAG) != "XCODE5"
|
2017-11-28 09:35:06 +01:00
|
|
|
INF ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
|
2018-11-22 14:41:41 +01:00
|
|
|
!endif
|
2011-06-26 20:58:41 +02:00
|
|
|
INF ShellPkg/Application/Shell/Shell.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2016-09-26 08:45:06 +02:00
|
|
|
INF MdeModulePkg/Logo/LogoDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2010-07-26 20:07:19 +02:00
|
|
|
#
|
|
|
|
|
# Network modules
|
|
|
|
|
#
|
2013-05-15 20:20:39 +02:00
|
|
|
!if $(E1000_ENABLE)
|
2011-04-12 17:08:51 +02:00
|
|
|
FILE DRIVER = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
|
2017-06-27 18:16:14 +02:00
|
|
|
SECTION PE32 = Intel3.5/EFIX64/E3522X2.EFI
|
2010-07-26 20:07:19 +02:00
|
|
|
}
|
2013-05-15 20:20:39 +02:00
|
|
|
!endif
|
2019-05-16 10:18:07 +02:00
|
|
|
!include NetworkPkg/Network.fdf.inc
|
2013-06-14 09:41:13 +02:00
|
|
|
INF OvmfPkg/VirtioNetDxe/VirtioNet.inf
|
2010-07-26 20:07:19 +02:00
|
|
|
|
2010-12-31 08:55:38 +01:00
|
|
|
#
|
|
|
|
|
# Usb Support
|
|
|
|
|
#
|
|
|
|
|
INF MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
|
2015-03-16 20:57:34 +01:00
|
|
|
INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
|
2010-12-31 08:55:38 +01:00
|
|
|
INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
|
|
|
|
|
INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
|
|
|
|
|
|
2011-11-10 23:04:49 +01:00
|
|
|
!ifdef $(CSM_ENABLE)
|
2019-05-15 09:15:53 +02:00
|
|
|
INF OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf
|
|
|
|
|
INF OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
|
2011-11-10 23:04:49 +01:00
|
|
|
INF RuleOverride=CSM OvmfPkg/Csm/Csm16/Csm16.inf
|
2019-06-26 13:37:41 +02:00
|
|
|
!else
|
|
|
|
|
INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
|
2011-11-10 23:04:49 +01:00
|
|
|
!endif
|
|
|
|
|
|
2018-06-13 09:29:34 +02:00
|
|
|
INF OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
|
2016-08-16 17:35:52 +02:00
|
|
|
INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
|
2014-03-22 08:12:55 +01:00
|
|
|
INF OvmfPkg/PlatformDxe/Platform.inf
|
2017-07-06 15:26:45 +02:00
|
|
|
INF OvmfPkg/AmdSevDxe/AmdSevDxe.inf
|
2017-07-06 15:28:40 +02:00
|
|
|
INF OvmfPkg/IoMmuDxe/IoMmuDxe.inf
|
2012-07-11 00:43:19 +02:00
|
|
|
|
2015-11-30 19:41:43 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
|
INF OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
|
2015-11-30 19:41:48 +01:00
|
|
|
INF OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
|
2015-11-30 19:46:55 +01:00
|
|
|
INF UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
|
2015-11-30 19:41:52 +01:00
|
|
|
INF MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
|
|
|
|
|
INF MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
|
2015-11-30 19:41:56 +01:00
|
|
|
INF UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
INF MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf
|
2015-11-30 19:48:46 +01:00
|
|
|
INF UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
|
2015-11-30 19:41:43 +01:00
|
|
|
|
2015-11-30 19:48:59 +01:00
|
|
|
#
|
2015-11-30 19:49:03 +01:00
|
|
|
# Variable driver stack (SMM)
|
|
|
|
|
#
|
|
|
|
|
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
|
|
|
|
|
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
|
|
|
|
|
|
|
|
|
|
!else
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Variable driver stack (non-SMM)
|
2015-11-30 19:48:59 +01:00
|
|
|
#
|
|
|
|
|
INF OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
|
|
|
|
|
INF OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
|
|
|
|
|
INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
|
|
|
|
|
INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
|
2015-11-30 19:49:03 +01:00
|
|
|
!endif
|
2015-11-30 19:48:59 +01:00
|
|
|
|
2020-01-08 15:38:42 +01:00
|
|
|
#
|
|
|
|
|
# TPM2 support
|
|
|
|
|
#
|
OvmfPkg: include Tcg2Dxe module
This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS.
The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2,
which is required for crypto-agile log. In fact, only upcoming 4.16
adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2:
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: SMBIOS=0x3fa1f000 ACPI=0x3fbb6000 ACPI 2.0=0x3fbb6014 MEMATTR=0x3e7d4318 TPMEventLog=0x3db21018
$ python chipsec_util.py tpm parse_log binary_bios_measurements
[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements']
PCR: 0 type: EV_S_CRTM_VERSION size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29
+ version:
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc
+ base: 0x820000 length: 0xe0000
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
+ base: 0x900000 length: 0xa00000
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4 type: EV_EFI_ACTION size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
$ tpm2_pcrlist
sha1 :
0 : 35bd1786b6909daad610d7598b1d620352d33b8a
1 : ec0511e860206e0af13c31da2f9e943fb6ca353d
2 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
3 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
4 : 45a323382bd933f08e7f0e256bc8249e4095b1ec
5 : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
6 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
7 : 518bd167271fbb64589c61e43d8c0165861431d8
8 : 0000000000000000000000000000000000000000
9 : 0000000000000000000000000000000000000000
10 : 0000000000000000000000000000000000000000
11 : 0000000000000000000000000000000000000000
12 : 0000000000000000000000000000000000000000
13 : 0000000000000000000000000000000000000000
14 : 0000000000000000000000000000000000000000
15 : 0000000000000000000000000000000000000000
16 : 0000000000000000000000000000000000000000
17 : ffffffffffffffffffffffffffffffffffffffff
18 : ffffffffffffffffffffffffffffffffffffffff
19 : ffffffffffffffffffffffffffffffffffffffff
20 : ffffffffffffffffffffffffffffffffffffffff
21 : ffffffffffffffffffffffffffffffffffffffff
22 : ffffffffffffffffffffffffffffffffffffffff
23 : 0000000000000000000000000000000000000000
sha256 :
0 : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
1 : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
2 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
3 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
4 : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
5 : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
6 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
7 : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068
8 : 0000000000000000000000000000000000000000000000000000000000000000
9 : 0000000000000000000000000000000000000000000000000000000000000000
10 : 0000000000000000000000000000000000000000000000000000000000000000
11 : 0000000000000000000000000000000000000000000000000000000000000000
12 : 0000000000000000000000000000000000000000000000000000000000000000
13 : 0000000000000000000000000000000000000000000000000000000000000000
14 : 0000000000000000000000000000000000000000000000000000000000000000
15 : 0000000000000000000000000000000000000000000000000000000000000000
16 : 0000000000000000000000000000000000000000000000000000000000000000
17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 : 0000000000000000000000000000000000000000000000000000000000000000
sha384 :
The PhysicalPresenceLib is required, it sets some variables, but the
firmware doesn't act on it yet.
Laszlo Ersek explained on the list why Tpm2DeviceLib has to be
resolved differently for DXE_DRIVER modules in general and for
"Tcg2Dxe.inf" specifically:
* We have a library class called Tpm2DeviceLib -- this is basically the
set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
Its leading comment says "This library abstract how to access TPM2
hardware device".
There are two *sets* of APIs in "Tpm2DeviceLib.h":
(a) functions that deal with the TPM2 device:
- Tpm2RequestUseTpm(),
- Tpm2SubmitCommand()
This set of APIs is supposed to be used by clients that *consume*
the TPM2 device abstraction.
(b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be
used by *providers* of various TPM2 device abstractions.
* Then, we have two implementations (instances) of the Tpm2DeviceLib class:
(1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
(2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
(1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the
APIs listed under (a), and it does not implement (b) -- see
EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for
drivers that *consume* the TPM2 device abstraction. And, the (a) group
of APIs is implemented by forwarding the requests to the TCG2 protocol.
The idea here is that all the drivers that consume the TPM2 abstraction
do not have to be statically linked with a large TPM2 device library
instance; instead they are only linked (statically) with this "thin"
library instance, and all the actual work is delegated to whichever
driver that provides the singleton TCG2 protocol.
(2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant
for the driver that offers (produces) the TCG2 protocol. This lib
instance implements both (a) and (b) API groups.
* Here's how things fit together:
(i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf"
library instance (which has no lib class) is linked into "Tcg2Dxe.inf"
via NULL class resolution. This simply means that before the
"Tcg2Dxe.inf" entry point function is entered, the constructor function
of "Tpm2InstanceLibDTpm.inf" will be called.
(ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and
registers its own actual TPM2 command implementation with the
"Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe
driver). This provides the back-end for the API set (a).
TCG2 protocol provider (Tcg2Dxe.inf driver) launches
|
v
NULL class: Tpm2InstanceLibDTpm instance construction
|
v
Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
backend registration for API set (a)
(iii) The Tcg2Dxe driver exposes the TCG2 protocol.
(iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls
land in Tcg2Dxe, via the protocol.
(v) Tcg2Dxe serves the protocol request by forwarding it to API set (a)
from lib instance (2).
(vi) Those functions call the "backend" functions registered by
Tpm2DeviceLibDTpm in step (ii).
TPM 2 consumer driver
|
v
Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance
|
v
TCG2 protocol interface
|
v
TCG2 protocol provider: Tcg2Dxe.inf driver
|
v
Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
|
v
NULL class: Tpm2InstanceLibDTpm instance
(via earlier registration)
|
v
TPM2 chip (actual hardware)
* So that is the "router" pattern in edk2. Namely,
- Consumers of an abstraction use a thin library instance.
- The thin library instance calls a firmware-global (singleton) service,
i.e. a PPI (in the PEI phase) or protocol (in the DXE phase).
- The PEIM providing the PPI, or the DXE driver providing the protocol,
don't themselves implement the actual service either. Instead they
offer a "registration" service too, and they only connect the incoming
"consumer" calls to the earlier registered back-end(s).
- The "registration service", for back-ends to use, may take various
forms.
It can be exposed globally to the rest of the firmware, as
another member function of the PPI / protocol structure. Then backends
can be provided by separate PEIMs / DXE drivers.
Or else, the registration service can be exposed as just another
library API. In this case, the backends are provided as NULL class
library instances, and a platform DSC file links them into the PEIM /
DXE driver via NULL class resolutions. The backend lib instances call
the registration service in their own respective constructor
functions.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-02-22 17:53:16 +01:00
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
|
INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
|
2019-01-25 22:30:29 +01:00
|
|
|
!if $(TPM2_CONFIG_ENABLE) == TRUE
|
|
|
|
|
INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
|
|
|
|
|
!endif
|
OvmfPkg: include Tcg2Dxe module
This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS.
The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2,
which is required for crypto-agile log. In fact, only upcoming 4.16
adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2:
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: SMBIOS=0x3fa1f000 ACPI=0x3fbb6000 ACPI 2.0=0x3fbb6014 MEMATTR=0x3e7d4318 TPMEventLog=0x3db21018
$ python chipsec_util.py tpm parse_log binary_bios_measurements
[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements']
PCR: 0 type: EV_S_CRTM_VERSION size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29
+ version:
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc
+ base: 0x820000 length: 0xe0000
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
+ base: 0x900000 length: 0xa00000
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4 type: EV_EFI_ACTION size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
$ tpm2_pcrlist
sha1 :
0 : 35bd1786b6909daad610d7598b1d620352d33b8a
1 : ec0511e860206e0af13c31da2f9e943fb6ca353d
2 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
3 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
4 : 45a323382bd933f08e7f0e256bc8249e4095b1ec
5 : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
6 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
7 : 518bd167271fbb64589c61e43d8c0165861431d8
8 : 0000000000000000000000000000000000000000
9 : 0000000000000000000000000000000000000000
10 : 0000000000000000000000000000000000000000
11 : 0000000000000000000000000000000000000000
12 : 0000000000000000000000000000000000000000
13 : 0000000000000000000000000000000000000000
14 : 0000000000000000000000000000000000000000
15 : 0000000000000000000000000000000000000000
16 : 0000000000000000000000000000000000000000
17 : ffffffffffffffffffffffffffffffffffffffff
18 : ffffffffffffffffffffffffffffffffffffffff
19 : ffffffffffffffffffffffffffffffffffffffff
20 : ffffffffffffffffffffffffffffffffffffffff
21 : ffffffffffffffffffffffffffffffffffffffff
22 : ffffffffffffffffffffffffffffffffffffffff
23 : 0000000000000000000000000000000000000000
sha256 :
0 : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
1 : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
2 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
3 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
4 : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
5 : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
6 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
7 : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068
8 : 0000000000000000000000000000000000000000000000000000000000000000
9 : 0000000000000000000000000000000000000000000000000000000000000000
10 : 0000000000000000000000000000000000000000000000000000000000000000
11 : 0000000000000000000000000000000000000000000000000000000000000000
12 : 0000000000000000000000000000000000000000000000000000000000000000
13 : 0000000000000000000000000000000000000000000000000000000000000000
14 : 0000000000000000000000000000000000000000000000000000000000000000
15 : 0000000000000000000000000000000000000000000000000000000000000000
16 : 0000000000000000000000000000000000000000000000000000000000000000
17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 : 0000000000000000000000000000000000000000000000000000000000000000
sha384 :
The PhysicalPresenceLib is required, it sets some variables, but the
firmware doesn't act on it yet.
Laszlo Ersek explained on the list why Tpm2DeviceLib has to be
resolved differently for DXE_DRIVER modules in general and for
"Tcg2Dxe.inf" specifically:
* We have a library class called Tpm2DeviceLib -- this is basically the
set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
Its leading comment says "This library abstract how to access TPM2
hardware device".
There are two *sets* of APIs in "Tpm2DeviceLib.h":
(a) functions that deal with the TPM2 device:
- Tpm2RequestUseTpm(),
- Tpm2SubmitCommand()
This set of APIs is supposed to be used by clients that *consume*
the TPM2 device abstraction.
(b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be
used by *providers* of various TPM2 device abstractions.
* Then, we have two implementations (instances) of the Tpm2DeviceLib class:
(1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
(2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
(1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the
APIs listed under (a), and it does not implement (b) -- see
EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for
drivers that *consume* the TPM2 device abstraction. And, the (a) group
of APIs is implemented by forwarding the requests to the TCG2 protocol.
The idea here is that all the drivers that consume the TPM2 abstraction
do not have to be statically linked with a large TPM2 device library
instance; instead they are only linked (statically) with this "thin"
library instance, and all the actual work is delegated to whichever
driver that provides the singleton TCG2 protocol.
(2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant
for the driver that offers (produces) the TCG2 protocol. This lib
instance implements both (a) and (b) API groups.
* Here's how things fit together:
(i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf"
library instance (which has no lib class) is linked into "Tcg2Dxe.inf"
via NULL class resolution. This simply means that before the
"Tcg2Dxe.inf" entry point function is entered, the constructor function
of "Tpm2InstanceLibDTpm.inf" will be called.
(ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and
registers its own actual TPM2 command implementation with the
"Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe
driver). This provides the back-end for the API set (a).
TCG2 protocol provider (Tcg2Dxe.inf driver) launches
|
v
NULL class: Tpm2InstanceLibDTpm instance construction
|
v
Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
backend registration for API set (a)
(iii) The Tcg2Dxe driver exposes the TCG2 protocol.
(iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls
land in Tcg2Dxe, via the protocol.
(v) Tcg2Dxe serves the protocol request by forwarding it to API set (a)
from lib instance (2).
(vi) Those functions call the "backend" functions registered by
Tpm2DeviceLibDTpm in step (ii).
TPM 2 consumer driver
|
v
Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance
|
v
TCG2 protocol interface
|
v
TCG2 protocol provider: Tcg2Dxe.inf driver
|
v
Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
|
v
NULL class: Tpm2InstanceLibDTpm instance
(via earlier registration)
|
v
TPM2 chip (actual hardware)
* So that is the "router" pattern in edk2. Namely,
- Consumers of an abstraction use a thin library instance.
- The thin library instance calls a firmware-global (singleton) service,
i.e. a PPI (in the PEI phase) or protocol (in the DXE phase).
- The PEIM providing the PPI, or the DXE driver providing the protocol,
don't themselves implement the actual service either. Instead they
offer a "registration" service too, and they only connect the incoming
"consumer" calls to the earlier registered back-end(s).
- The "registration service", for back-ends to use, may take various
forms.
It can be exposed globally to the rest of the firmware, as
another member function of the PPI / protocol structure. Then backends
can be provided by separate PEIMs / DXE drivers.
Or else, the registration service can be exposed as just another
library API. In this case, the backends are provided as NULL class
library instances, and a platform DSC file links them into the PEIM /
DXE driver via NULL class resolutions. The backend lib instances call
the registration service in their own respective constructor
functions.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-02-22 17:53:16 +01:00
|
|
|
!endif
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
|
|
2010-06-26 00:23:22 +02:00
|
|
|
[FV.FVMAIN_COMPACT]
|
OvmfPkg: add a Name GUID to each Firmware Volume
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).
Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):
- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
directly, see below).
- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
address. This object is not followed by any
EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
specifies the Name GUID for the firmware volume.
The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
in the Build directory as a separate file (20 bytes in size):
Build/Ovmf*/*_GCC*/FV/*.ext
- The new data consume 48 bytes in the following volumes: SECFV,
FVMAIN_COMPACT, DXEFV. They comprise:
- 16 padding bytes,
- EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
fields, and Type=EFI_FV_FILETYPE_FFS_PAD),
- EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),
- 4 padding bytes.
(The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
immediately past EFI_FIRMWARE_VOLUME_HEADER.)
The sizes of the firmware volumes don't change, only their internal
usages grow by 48 bytes. I verified that the statements and calculations
in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.
- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
internal padding at the moment to accomodate the above structures
without a growth in usage.
In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@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>
2016-07-12 16:48:47 +02:00
|
|
|
FvNameGuid = 48DB5E17-707C-472D-91CD-1613E7EF51B0
|
2009-05-27 23:10:18 +02:00
|
|
|
FvAlignment = 16
|
|
|
|
|
ERASE_POLARITY = 1
|
|
|
|
|
MEMORY_MAPPED = TRUE
|
|
|
|
|
STICKY_WRITE = TRUE
|
|
|
|
|
LOCK_CAP = TRUE
|
|
|
|
|
LOCK_STATUS = TRUE
|
|
|
|
|
WRITE_DISABLED_CAP = TRUE
|
|
|
|
|
WRITE_ENABLED_CAP = TRUE
|
|
|
|
|
WRITE_STATUS = TRUE
|
|
|
|
|
WRITE_LOCK_CAP = TRUE
|
|
|
|
|
WRITE_LOCK_STATUS = TRUE
|
|
|
|
|
READ_DISABLED_CAP = TRUE
|
|
|
|
|
READ_ENABLED_CAP = TRUE
|
|
|
|
|
READ_STATUS = TRUE
|
|
|
|
|
READ_LOCK_CAP = TRUE
|
|
|
|
|
READ_LOCK_STATUS = TRUE
|
|
|
|
|
|
2010-06-26 00:23:22 +02:00
|
|
|
FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
|
|
|
|
|
SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = TRUE {
|
2014-01-21 20:39:13 +01:00
|
|
|
#
|
|
|
|
|
# These firmware volumes will have files placed in them uncompressed,
|
|
|
|
|
# and then both firmware volumes will be compressed in a single
|
|
|
|
|
# compression operation in order to achieve better overall compression.
|
|
|
|
|
#
|
|
|
|
|
SECTION FV_IMAGE = PEIFV
|
|
|
|
|
SECTION FV_IMAGE = DXEFV
|
2009-05-27 23:10:18 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
!include DecomprScratchEnd.fdf.inc
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
|
|
|
|
|
|
[Rule.Common.SEC]
|
|
|
|
|
FILE SEC = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING ="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-26 00:23:22 +02:00
|
|
|
[Rule.Common.PEI_CORE]
|
|
|
|
|
FILE PEI_CORE = $(NAMED_GUID) {
|
2015-07-09 10:55:23 +02:00
|
|
|
PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2010-06-26 00:23:22 +02:00
|
|
|
UI STRING ="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING ="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
2009-10-07 18:01:09 +02:00
|
|
|
}
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[Rule.Common.PEIM]
|
|
|
|
|
FILE PEIM = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
PEI_DEPEX PEI_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
|
2015-07-09 10:55:23 +02:00
|
|
|
PE32 PE32 Align=Auto $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
[Rule.Common.DXE_CORE]
|
|
|
|
|
FILE DXE_CORE = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-26 00:23:22 +02:00
|
|
|
[Rule.Common.DXE_DRIVER]
|
2009-05-27 23:10:18 +02:00
|
|
|
FILE DRIVER = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
|
|
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
2016-04-19 09:17:03 +02:00
|
|
|
RAW ACPI Optional |.acpi
|
|
|
|
|
RAW ASL Optional |.aml
|
2009-05-27 23:10:18 +02:00
|
|
|
}
|
|
|
|
|
|
2010-06-26 00:23:22 +02:00
|
|
|
[Rule.Common.DXE_RUNTIME_DRIVER]
|
2009-05-27 23:10:18 +02:00
|
|
|
FILE DRIVER = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
|
|
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
2010-07-26 20:07:19 +02:00
|
|
|
|
2010-06-26 00:23:22 +02:00
|
|
|
[Rule.Common.UEFI_DRIVER]
|
2009-05-27 23:10:18 +02:00
|
|
|
FILE DRIVER = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
DXE_DEPEX DXE_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
|
|
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-29 06:55:13 +02:00
|
|
|
[Rule.Common.UEFI_DRIVER.BINARY]
|
2010-06-29 20:34:32 +02:00
|
|
|
FILE DRIVER = $(NAMED_GUID) {
|
2010-06-29 06:55:13 +02:00
|
|
|
DXE_DEPEX DXE_DEPEX Optional |.depex
|
|
|
|
|
PE32 PE32 |.efi
|
|
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
2012-08-15 02:03:59 +02:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[Rule.Common.UEFI_APPLICATION]
|
|
|
|
|
FILE APPLICATION = $(NAMED_GUID) {
|
2010-03-01 07:47:58 +01:00
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
2009-05-27 23:10:18 +02:00
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-29 06:55:13 +02:00
|
|
|
[Rule.Common.UEFI_APPLICATION.BINARY]
|
|
|
|
|
FILE APPLICATION = $(NAMED_GUID) {
|
|
|
|
|
PE32 PE32 |.efi
|
|
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
2012-08-15 02:03:59 +02:00
|
|
|
|
2009-08-11 07:30:52 +02:00
|
|
|
[Rule.Common.USER_DEFINED.ACPITABLE]
|
2009-05-27 23:10:18 +02:00
|
|
|
FILE FREEFORM = $(NAMED_GUID) {
|
|
|
|
|
RAW ACPI |.acpi
|
|
|
|
|
RAW ASL |.aml
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-10 23:04:49 +01:00
|
|
|
[Rule.Common.USER_DEFINED.CSM]
|
|
|
|
|
FILE FREEFORM = $(NAMED_GUID) {
|
|
|
|
|
RAW BIN |.bin
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[Rule.Common.SEC.RESET_VECTOR]
|
|
|
|
|
FILE RAW = $(NAMED_GUID) {
|
2014-08-19 01:04:00 +02:00
|
|
|
RAW BIN Align = 16 |.bin
|
2009-05-27 23:10:18 +02:00
|
|
|
}
|
2015-11-30 19:41:52 +01:00
|
|
|
|
|
|
|
|
[Rule.Common.SMM_CORE]
|
|
|
|
|
FILE SMM_CORE = $(NAMED_GUID) {
|
|
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
|
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
2015-11-30 19:41:56 +01:00
|
|
|
|
|
|
|
|
[Rule.Common.DXE_SMM_DRIVER]
|
|
|
|
|
FILE SMM = $(NAMED_GUID) {
|
|
|
|
|
SMM_DEPEX SMM_DEPEX Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
|
|
|
|
|
PE32 PE32 $(INF_OUTPUT)/$(MODULE_NAME).efi
|
|
|
|
|
UI STRING="$(MODULE_NAME)" Optional
|
|
|
|
|
VERSION STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
|
|
|
|
|
}
|
