2010-02-24 00:58:38 +01:00
|
|
|
## @file
|
2009-05-27 23:10:18 +02:00
|
|
|
# EFI/Framework Open Virtual Machine Firmware (OVMF) platform
|
|
|
|
#
|
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
|
|
|
|
|
|
|
################################################################################
|
|
|
|
#
|
|
|
|
# Defines Section - statements that will be processed to create a Makefile.
|
|
|
|
#
|
|
|
|
################################################################################
|
|
|
|
[Defines]
|
|
|
|
PLATFORM_NAME = Ovmf
|
|
|
|
PLATFORM_GUID = 5a9e7754-d81b-49ea-85ad-69eaa7b1539b
|
|
|
|
PLATFORM_VERSION = 0.1
|
2009-10-22 08:30:20 +02:00
|
|
|
DSC_SPECIFICATION = 0x00010005
|
2009-05-27 23:10:18 +02:00
|
|
|
OUTPUT_DIRECTORY = Build/OvmfIa32
|
|
|
|
SUPPORTED_ARCHITECTURES = IA32
|
2016-10-10 17:43:24 +02:00
|
|
|
BUILD_TARGETS = NOOPT|DEBUG|RELEASE
|
2009-05-27 23:10:18 +02:00
|
|
|
SKUID_IDENTIFIER = DEFAULT
|
2010-07-26 20:07:19 +02:00
|
|
|
FLASH_DEFINITION = OvmfPkg/OvmfPkgIa32.fdf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2012-03-09 18:38:21 +01:00
|
|
|
#
|
|
|
|
# Defines for default states. These can be changed on the command line.
|
|
|
|
# -D FLAG=VALUE
|
|
|
|
#
|
|
|
|
DEFINE SECURE_BOOT_ENABLE = FALSE
|
2015-11-30 19:41:10 +01:00
|
|
|
DEFINE SMM_REQUIRE = FALSE
|
2018-02-22 14:20:58 +01:00
|
|
|
DEFINE TPM2_ENABLE = FALSE
|
2019-01-25 22:30:29 +01:00
|
|
|
DEFINE TPM2_CONFIG_ENABLE = FALSE
|
2012-03-09 18:38:21 +01:00
|
|
|
|
2019-05-16 10:18:07 +02:00
|
|
|
#
|
|
|
|
# Network definition
|
|
|
|
#
|
|
|
|
DEFINE NETWORK_TLS_ENABLE = FALSE
|
|
|
|
DEFINE NETWORK_IP6_ENABLE = FALSE
|
|
|
|
DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE
|
|
|
|
DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = TRUE
|
|
|
|
|
|
|
|
!include NetworkPkg/NetworkDefines.dsc.inc
|
|
|
|
|
2017-05-03 17:54:49 +02:00
|
|
|
#
|
|
|
|
# Flash size selection. Setting FD_SIZE_IN_KB on the command line directly to
|
|
|
|
# one of the supported values, in place of any of the convenience macros, is
|
|
|
|
# permitted.
|
|
|
|
#
|
|
|
|
!ifdef $(FD_SIZE_1MB)
|
|
|
|
DEFINE FD_SIZE_IN_KB = 1024
|
|
|
|
!else
|
|
|
|
!ifdef $(FD_SIZE_2MB)
|
|
|
|
DEFINE FD_SIZE_IN_KB = 2048
|
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the
Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the
Microsoft Hardware Certification Kit expects to be able to populate the
variable store up to roughly 64 KB, with a series of 1 KB sized,
unauthenticated variables. OVMF's current live varstore area is too small
for this: 56 KB.
Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096),
which
- enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see
FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --,
- inside that, grows the varstore area / pflash chip to 528 KB, and within
it, the live area from 56 KB to 256 KB.
Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be
compatible with a variable store that originates from a variable store
template built *without* -D FD_SIZE_4MB. This is the reason for the large
increase, as every such change breaks compatibility between a new firmware
binary and old varstore files.
Enlarging the varstore does not impact the performance of normal
operations, as we keep the varstore block size 4KB. The performance of
reclaim is affected, but that is expected (since reclaim has to rework the
full live area). And, reclaim occurs proportionally less frequently.
While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in
it) is also enlarged significantly, so that we have plenty of room for
future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing
steadily, and that increase shows through compression too. Right now the
PEIFV and DXEFV volumes need no resizing.
Here's a summary:
Description Compression type Size [KB]
------------------------- ----------------- ----------------------
Non-volatile data storage open-coded binary 128 -> 528 ( +400)
data
Variable store 56 -> 256 ( +200)
Event log 4 -> 4 ( +0)
Working block 4 -> 4 ( +0)
Spare area 64 -> 264 ( +200)
FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648)
FV FFS file LZMA compressed
PEIFV uncompressed 896 -> 896 ( +0)
individual PEI uncompressed
modules
DXEFV uncompressed 10240 -> 10240 ( +0)
individual DXE uncompressed
modules
SECFV uncompressed 208 -> 208 ( +0)
SEC driver
reset vector code
For now, the 2MB flash image remains the default.
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-04-29 03:37:41 +02:00
|
|
|
!else
|
|
|
|
!ifdef $(FD_SIZE_4MB)
|
|
|
|
DEFINE FD_SIZE_IN_KB = 4096
|
2017-05-03 17:54:49 +02:00
|
|
|
!else
|
2017-05-03 19:37:06 +02:00
|
|
|
DEFINE FD_SIZE_IN_KB = 4096
|
2017-05-03 17:54:49 +02:00
|
|
|
!endif
|
|
|
|
!endif
|
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the
Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the
Microsoft Hardware Certification Kit expects to be able to populate the
variable store up to roughly 64 KB, with a series of 1 KB sized,
unauthenticated variables. OVMF's current live varstore area is too small
for this: 56 KB.
Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096),
which
- enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see
FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --,
- inside that, grows the varstore area / pflash chip to 528 KB, and within
it, the live area from 56 KB to 256 KB.
Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be
compatible with a variable store that originates from a variable store
template built *without* -D FD_SIZE_4MB. This is the reason for the large
increase, as every such change breaks compatibility between a new firmware
binary and old varstore files.
Enlarging the varstore does not impact the performance of normal
operations, as we keep the varstore block size 4KB. The performance of
reclaim is affected, but that is expected (since reclaim has to rework the
full live area). And, reclaim occurs proportionally less frequently.
While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in
it) is also enlarged significantly, so that we have plenty of room for
future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing
steadily, and that increase shows through compression too. Right now the
PEIFV and DXEFV volumes need no resizing.
Here's a summary:
Description Compression type Size [KB]
------------------------- ----------------- ----------------------
Non-volatile data storage open-coded binary 128 -> 528 ( +400)
data
Variable store 56 -> 256 ( +200)
Event log 4 -> 4 ( +0)
Working block 4 -> 4 ( +0)
Spare area 64 -> 264 ( +200)
FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648)
FV FFS file LZMA compressed
PEIFV uncompressed 896 -> 896 ( +0)
individual PEI uncompressed
modules
DXEFV uncompressed 10240 -> 10240 ( +0)
individual DXE uncompressed
modules
SECFV uncompressed 208 -> 208 ( +0)
SEC driver
reset vector code
For now, the 2MB flash image remains the default.
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-04-29 03:37:41 +02:00
|
|
|
!endif
|
2017-05-03 17:54:49 +02:00
|
|
|
|
2010-01-04 17:18:02 +01:00
|
|
|
[BuildOptions]
|
2010-10-13 09:07:42 +02:00
|
|
|
GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
|
|
|
|
INTEL:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
|
|
|
|
MSFT:RELEASE_*_*_CC_FLAGS = /D MDEPKG_NDEBUG
|
2018-01-10 16:24:32 +01:00
|
|
|
!if $(TOOL_CHAIN_TAG) != "XCODE5"
|
2010-12-31 08:55:51 +01:00
|
|
|
GCC:*_*_*_CC_FLAGS = -mno-mmx -mno-sse
|
2018-01-10 16:24:32 +01:00
|
|
|
!endif
|
2010-01-04 17:18:02 +01:00
|
|
|
|
2016-10-21 16:30:58 +02:00
|
|
|
#
|
|
|
|
# Disable deprecated APIs.
|
|
|
|
#
|
|
|
|
MSFT:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
|
|
|
|
INTEL:*_*_*_CC_FLAGS = /D DISABLE_NEW_DEPRECATED_INTERFACES
|
|
|
|
GCC:*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
|
|
|
|
|
2015-09-30 10:53:00 +02:00
|
|
|
[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
|
|
|
|
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
|
2017-05-03 02:25:10 +02:00
|
|
|
XCODE:*_*_*_DLINK_FLAGS =
|
2015-09-30 10:53:00 +02:00
|
|
|
|
2016-11-17 14:37:40 +01:00
|
|
|
# Force PE/COFF sections to be aligned at 4KB boundaries to support page level
|
|
|
|
# protection of DXE_SMM_DRIVER/SMM_CORE modules
|
|
|
|
[BuildOptions.common.EDKII.DXE_SMM_DRIVER, BuildOptions.common.EDKII.SMM_CORE]
|
|
|
|
GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
|
2017-05-03 02:25:10 +02:00
|
|
|
XCODE:*_*_*_DLINK_FLAGS =
|
2016-11-17 14:37:40 +01:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
#
|
|
|
|
# SKU Identification section - list of all SKU IDs supported by this Platform.
|
|
|
|
#
|
|
|
|
################################################################################
|
|
|
|
[SkuIds]
|
|
|
|
0|DEFAULT
|
|
|
|
|
|
|
|
################################################################################
|
|
|
|
#
|
|
|
|
# Library Class section - list of all Library Classes needed by this Platform.
|
|
|
|
#
|
|
|
|
################################################################################
|
2010-02-24 00:58:38 +01:00
|
|
|
[LibraryClasses]
|
2009-05-27 23:10:18 +02:00
|
|
|
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
|
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
|
2010-12-31 08:55:51 +01:00
|
|
|
BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
|
2017-12-30 03:59:21 +01:00
|
|
|
SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
|
|
|
|
BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
|
|
|
|
CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
|
|
|
|
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
|
|
|
|
PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
|
|
|
|
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
|
|
|
|
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
|
|
|
|
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
|
|
|
|
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
|
|
|
|
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
|
2016-05-25 13:08:15 +02:00
|
|
|
BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
|
|
|
|
DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
|
2012-07-31 19:54:30 +02:00
|
|
|
DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
|
|
|
|
PciCf8Lib|MdePkg/Library/BasePciCf8Lib/BasePciCf8Lib.inf
|
2016-03-04 01:33:38 +01:00
|
|
|
PciExpressLib|MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
PciLib|MdePkg/Library/BasePciLibCf8/BasePciLibCf8.inf
|
2016-01-26 01:29:24 +01:00
|
|
|
PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf
|
2018-05-04 10:06:08 +02:00
|
|
|
PciCapLib|OvmfPkg/Library/BasePciCapLib/BasePciCapLib.inf
|
|
|
|
PciCapPciSegmentLib|OvmfPkg/Library/BasePciCapPciSegmentLib/BasePciCapPciSegmentLib.inf
|
|
|
|
PciCapPciIoLib|OvmfPkg/Library/UefiPciCapPciIoLib/UefiPciCapPciIoLib.inf
|
2017-07-06 15:21:12 +02:00
|
|
|
IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsicSev.inf
|
2009-12-29 10:36:05 +01:00
|
|
|
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
SerialPortLib|PcAtChipsetPkg/Library/SerialIoLib/SerialIoLib.inf
|
|
|
|
MtrrLib|UefiCpuPkg/Library/MtrrLib/MtrrLib.inf
|
2009-06-30 17:57:29 +02:00
|
|
|
UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
|
|
|
|
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
|
|
|
|
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
|
|
|
|
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
|
|
|
|
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
|
2013-08-19 06:15:36 +02:00
|
|
|
DevicePathLib|MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf
|
2009-09-16 18:29:03 +02:00
|
|
|
NvVarsFileLib|OvmfPkg/Library/NvVarsFileLib/NvVarsFileLib.inf
|
2015-01-13 02:04:07 +01:00
|
|
|
FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
|
2009-11-25 05:26:09 +01:00
|
|
|
UefiCpuLib|UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
|
2009-11-26 02:33:07 +01:00
|
|
|
SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
|
2010-12-31 08:55:38 +01:00
|
|
|
UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
|
2011-01-30 20:49:54 +01:00
|
|
|
SerializeVariablesLib|OvmfPkg/Library/SerializeVariablesLib/SerializeVariablesLib.inf
|
2017-07-06 15:28:47 +02:00
|
|
|
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgDxeLib.inf
|
2012-10-12 20:53:58 +02:00
|
|
|
VirtioLib|OvmfPkg/Library/VirtioLib/VirtioLib.inf
|
2012-11-02 19:27:55 +01:00
|
|
|
LoadLinuxLib|OvmfPkg/Library/LoadLinuxLib/LoadLinuxLib.inf
|
2017-07-06 15:21:12 +02:00
|
|
|
MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/BaseMemEncryptSevLib.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
!if $(SMM_REQUIRE) == FALSE
|
2014-03-04 09:03:23 +01:00
|
|
|
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
!endif
|
2013-08-12 04:24:32 +02:00
|
|
|
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
|
2016-06-27 11:28:54 +02:00
|
|
|
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
|
2010-10-13 09:07:42 +02:00
|
|
|
|
2010-09-12 08:46:55 +02:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
|
|
|
|
DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf
|
|
|
|
!else
|
2010-08-03 09:41:54 +02:00
|
|
|
PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
|
|
|
|
DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
|
2010-09-12 08:46:55 +02:00
|
|
|
!endif
|
2010-10-13 09:07:42 +02:00
|
|
|
|
2011-01-13 06:46:52 +01:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf
|
2015-11-30 19:42:31 +01:00
|
|
|
LocalApicLib|UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
|
|
|
|
|
|
|
|
IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
|
2019-05-16 10:18:07 +02:00
|
|
|
!if $(NETWORK_TLS_ENABLE) == TRUE
|
2012-03-09 18:38:53 +01:00
|
|
|
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
|
2017-02-23 21:46:06 +01:00
|
|
|
!else
|
|
|
|
OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
|
|
|
|
!endif
|
2017-01-17 05:52:30 +01:00
|
|
|
|
|
|
|
!if $(SECURE_BOOT_ENABLE) == TRUE
|
|
|
|
PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf
|
2013-09-21 10:18:03 +02:00
|
|
|
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
|
2015-07-01 05:05:47 +02:00
|
|
|
AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
|
|
|
|
!else
|
|
|
|
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
|
|
|
|
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
!endif
|
2015-08-25 04:59:25 +02:00
|
|
|
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
|
2017-01-17 05:52:31 +01:00
|
|
|
|
2019-05-16 10:18:07 +02:00
|
|
|
#
|
|
|
|
# Network libraries
|
|
|
|
#
|
|
|
|
!include NetworkPkg/NetworkLibs.dsc.inc
|
2015-08-23 03:44:15 +02:00
|
|
|
|
2019-05-16 10:18:07 +02:00
|
|
|
!if $(NETWORK_TLS_ENABLE) == TRUE
|
2017-01-17 05:52:32 +01:00
|
|
|
TlsLib|CryptoPkg/Library/TlsLib/TlsLib.inf
|
|
|
|
!endif
|
|
|
|
|
2017-11-28 09:35:06 +01:00
|
|
|
ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
|
2019-04-25 13:15:13 +02:00
|
|
|
ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
|
2014-03-04 09:03:50 +01:00
|
|
|
S3BootScriptLib|MdeModulePkg/Library/PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf
|
|
|
|
SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
|
2014-09-22 23:11:02 +02:00
|
|
|
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
|
2015-03-03 09:13:09 +01:00
|
|
|
XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
|
2014-03-04 09:03:50 +01:00
|
|
|
|
2018-02-22 14:20:58 +01:00
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
|
2018-05-18 14:23:03 +02:00
|
|
|
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibQemu/DxeTcg2PhysicalPresenceLib.inf
|
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
|
|
|
Tcg2PpVendorLib|SecurityPkg/Library/Tcg2PpVendorLibNull/Tcg2PpVendorLibNull.inf
|
2018-05-18 14:23:01 +02:00
|
|
|
!else
|
|
|
|
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
|
2018-02-22 14:20:58 +01:00
|
|
|
!endif
|
|
|
|
|
2012-03-09 18:38:53 +01:00
|
|
|
[LibraryClasses.common]
|
|
|
|
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
|
2010-10-13 09:07:42 +02:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[LibraryClasses.common.SEC]
|
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf
|
2014-01-03 20:57:36 +01:00
|
|
|
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgSecLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
2017-11-16 21:30:59 +01:00
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformRomDebugLibIoPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!endif
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
|
2010-05-05 04:06:21 +02:00
|
|
|
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
|
2010-09-12 08:46:55 +02:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
|
|
|
|
!endif
|
2010-08-03 09:41:54 +02:00
|
|
|
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
|
|
|
|
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
|
|
|
|
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
|
2013-11-22 07:31:18 +01:00
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
|
2010-10-13 09:07:42 +02:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[LibraryClasses.common.PEI_CORE]
|
|
|
|
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
|
|
|
|
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
|
|
|
|
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
|
|
|
|
PeiCoreEntryPoint|MdePkg/Library/PeiCoreEntryPoint/PeiCoreEntryPoint.inf
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
|
2009-12-29 10:36:05 +01:00
|
|
|
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
|
|
|
|
|
|
|
|
[LibraryClasses.common.PEIM]
|
|
|
|
HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
|
|
|
|
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
|
|
|
|
PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
|
|
|
|
PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf
|
2009-12-29 10:36:05 +01:00
|
|
|
OemHookStatusCodeLib|MdeModulePkg/Library/OemHookStatusCodeLibNull/OemHookStatusCodeLibNull.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
|
2018-07-24 04:23:28 +02:00
|
|
|
ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf
|
2010-09-12 08:46:55 +02:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.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
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
|
2016-07-21 09:10:40 +02:00
|
|
|
MpInitLib|UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
|
2017-02-22 03:11:07 +01:00
|
|
|
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/PeiQemuFwCfgS3LibFwCfg.inf
|
2017-03-12 23:59:04 +01:00
|
|
|
PcdLib|MdePkg/Library/PeiPcdLib/PeiPcdLib.inf
|
2017-07-06 15:28:47 +02:00
|
|
|
QemuFwCfgLib|OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgPeiLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2018-02-22 14:20:58 +01:00
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
2018-02-22 15:26:34 +01:00
|
|
|
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
|
2018-02-22 14:20:58 +01:00
|
|
|
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
|
|
|
|
!endif
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[LibraryClasses.common.DXE_CORE]
|
|
|
|
HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
|
|
|
|
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
|
|
|
|
MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
|
2010-09-12 08:46:55 +02:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
|
|
|
|
!endif
|
2013-11-22 07:31:18 +01:00
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
|
OvmfPkg: make PcdPropertiesTableEnable dynamic
Since PcdPropertiesTableEnable is used by the DXE Core (in the
InstallPropertiesTable() function, which runs at End-of-Dxe), we must also
change the PcdLib class resolution for that module, from the default
BasePcdLibNull to DxePcdLib.
Traditionally we've considered the DXE Core to be incapable of accessing
dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core,
and the PCD Protocol is not available to it *yet*. There are exceptions
however: if the DXE Core can ensure, by whatever means, that the PCD
Protocol *is* available, then DxePcdLib will just work (the latter even
lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks
up the PCD Protocol dynamically, on the first library call that actually
needs it (for accessing a dynamic PCD); the lookup doesn't occur in a
library constructor.
And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe,
the PCD Protocol is definitely available then.
In addition, we change the default value of PcdPropertiesTableEnable from
the inherited TRUE to FALSE. It makes no difference at this point (our
runtime DXE drivers are not built with the required 4KB section alignment
anyway), but it's better to be clear about this. The properties table
feature requires OS compatibility, and it breaks Windows 7 minimally.
Therefore the default should be FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18470 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-15 10:35:08 +02:00
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
[LibraryClasses.common.DXE_RUNTIME_DRIVER]
|
2014-11-14 01:38:53 +01:00
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
|
|
|
|
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
|
2016-03-04 01:33:38 +01:00
|
|
|
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
|
2017-02-22 03:11:07 +01:00
|
|
|
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
[LibraryClasses.common.UEFI_DRIVER]
|
2014-11-14 01:38:53 +01:00
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
|
|
|
|
DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
|
2016-03-04 01:33:38 +01:00
|
|
|
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
[LibraryClasses.common.DXE_DRIVER]
|
2014-11-14 01:38:53 +01:00
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
|
2009-12-29 10:10:05 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2016-04-18 03:47:55 +02:00
|
|
|
PlatformBootManagerLib|OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
|
2017-11-22 21:37:07 +01:00
|
|
|
PlatformBmPrintScLib|OvmfPkg/Library/PlatformBmPrintScLib/PlatformBmPrintScLib.inf
|
2016-05-17 19:30:24 +02:00
|
|
|
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
|
2013-11-22 07:31:18 +01:00
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
|
|
|
|
!else
|
2014-03-04 09:03:23 +01:00
|
|
|
LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
!endif
|
2014-03-04 09:04:20 +01:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
|
|
|
|
!endif
|
2016-03-04 01:33:38 +01:00
|
|
|
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
|
2016-07-21 09:10:40 +02:00
|
|
|
MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
|
2017-02-22 03:11:07 +01:00
|
|
|
QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
|
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
|
|
|
|
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2009-06-30 17:57:29 +02:00
|
|
|
[LibraryClasses.common.UEFI_APPLICATION]
|
2014-11-14 01:38:53 +01:00
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
|
2009-06-30 17:57:29 +02:00
|
|
|
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
|
|
|
|
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
2009-06-30 17:57:29 +02:00
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
2012-07-26 18:36:39 +02:00
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2016-03-04 01:33:38 +01:00
|
|
|
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
|
2009-06-30 17:57:29 +02:00
|
|
|
|
2014-11-14 01:38:53 +01:00
|
|
|
[LibraryClasses.common.DXE_SMM_DRIVER]
|
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
|
2015-11-30 19:42:19 +01:00
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
|
|
|
|
SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
|
2019-01-09 16:03:03 +01:00
|
|
|
MmServicesTableLib|MdePkg/Library/MmServicesTableLib/MmServicesTableLib.inf
|
2015-11-30 19:41:56 +01:00
|
|
|
SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
|
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2015-11-30 19:42:23 +01:00
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
|
2015-11-30 19:42:27 +01:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
|
|
|
|
!endif
|
2015-11-30 19:49:03 +01:00
|
|
|
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf
|
2016-03-04 01:33:38 +01:00
|
|
|
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
|
2014-11-14 01:38:53 +01:00
|
|
|
|
|
|
|
[LibraryClasses.common.SMM_CORE]
|
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
|
2015-11-30 19:41:52 +01:00
|
|
|
SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
|
|
|
|
MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
|
|
|
|
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
|
|
|
|
HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
|
|
|
|
SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
|
|
|
|
SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
|
|
|
|
!ifdef $(DEBUG_ON_SERIAL_PORT)
|
|
|
|
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
|
|
|
|
!else
|
|
|
|
DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
|
|
|
|
!endif
|
2016-03-04 01:33:38 +01:00
|
|
|
PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
|
2014-11-14 01:38:53 +01:00
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
#
|
|
|
|
# Pcd Section - list of all EDK II PCD Entries defined by this Platform.
|
|
|
|
#
|
|
|
|
################################################################################
|
2010-02-24 00:58:38 +01:00
|
|
|
[PcdsFeatureFlag]
|
2016-03-11 00:07:16 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE
|
2010-01-04 17:18:03 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|TRUE
|
2010-03-15 02:40:59 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportUefiDecompress|FALSE
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|FALSE
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
|
2016-04-19 09:17:03 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
|
2015-11-30 19:41:10 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
|
2015-11-30 19:42:35 +01:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmEnableBspElection|FALSE
|
2015-11-30 19:41:10 +01:00
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2010-02-24 00:58:38 +01:00
|
|
|
[PcdsFixedAtBuild]
|
2009-12-25 07:36:10 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
|
2011-08-25 05:19:57 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
|
2009-05-27 23:10:18 +02:00
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x10
|
2017-04-29 04:41:08 +02:00
|
|
|
!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
|
2013-06-14 23:37:44 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
|
2016-03-25 02:38:41 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x2800
|
2019-05-16 10:18:07 +02:00
|
|
|
!if $(NETWORK_TLS_ENABLE) == FALSE
|
2018-03-28 16:59:43 +02:00
|
|
|
# match PcdFlashNvStorageVariableSize purely for convenience
|
2017-05-05 03:31:32 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000
|
2017-04-29 04:41:08 +02:00
|
|
|
!endif
|
2018-03-28 03:04:06 +02:00
|
|
|
!endif
|
2017-04-29 04:41:08 +02:00
|
|
|
!if $(FD_SIZE_IN_KB) == 4096
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400
|
2019-05-16 10:18:07 +02:00
|
|
|
!if $(NETWORK_TLS_ENABLE) == FALSE
|
2018-03-28 16:59:43 +02:00
|
|
|
# match PcdFlashNvStorageVariableSize purely for convenience
|
2017-05-05 03:31:32 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x40000
|
2017-04-29 04:41:08 +02:00
|
|
|
!endif
|
2018-03-28 03:04:06 +02:00
|
|
|
!endif
|
2019-05-16 10:18:07 +02:00
|
|
|
!if $(NETWORK_TLS_ENABLE) == TRUE
|
2018-03-28 03:04:06 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0x80000
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVolatileVariableSize|0x40000
|
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVpdBaseAddress|0x0
|
|
|
|
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
|
2016-03-01 10:39:49 +01:00
|
|
|
|
|
|
|
# DEBUG_INIT 0x00000001 // Initialization
|
|
|
|
# DEBUG_WARN 0x00000002 // Warnings
|
|
|
|
# DEBUG_LOAD 0x00000004 // Load events
|
|
|
|
# DEBUG_FS 0x00000008 // EFI File system
|
|
|
|
# DEBUG_POOL 0x00000010 // Alloc & Free (pool)
|
|
|
|
# DEBUG_PAGE 0x00000020 // Alloc & Free (page)
|
|
|
|
# DEBUG_INFO 0x00000040 // Informational debug messages
|
|
|
|
# DEBUG_DISPATCH 0x00000080 // PEI/DXE/SMM Dispatchers
|
|
|
|
# DEBUG_VARIABLE 0x00000100 // Variable
|
|
|
|
# DEBUG_BM 0x00000400 // Boot Manager
|
|
|
|
# DEBUG_BLKIO 0x00001000 // BlkIo Driver
|
|
|
|
# DEBUG_NET 0x00004000 // SNP Driver
|
|
|
|
# DEBUG_UNDI 0x00010000 // UNDI Driver
|
|
|
|
# DEBUG_LOADFILE 0x00020000 // LoadFile
|
|
|
|
# DEBUG_EVENT 0x00080000 // Event messages
|
|
|
|
# DEBUG_GCD 0x00100000 // Global Coherency Database changes
|
|
|
|
# DEBUG_CACHE 0x00200000 // Memory range cachability changes
|
|
|
|
# DEBUG_VERBOSE 0x00400000 // Detailed debug messages that may
|
|
|
|
# // significantly impact boot performance
|
|
|
|
# DEBUG_ERROR 0x80000000 // Error
|
2009-05-27 23:10:18 +02:00
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8000004F
|
2016-03-01 10:39:49 +01:00
|
|
|
|
2010-09-12 08:46:55 +02:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x17
|
|
|
|
!else
|
2009-05-27 23:10:18 +02:00
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F
|
2010-09-12 08:46:55 +02:00
|
|
|
!endif
|
|
|
|
|
2016-03-03 20:46:22 +01:00
|
|
|
# This PCD is used to set the base address of the PCI express hierarchy. It
|
|
|
|
# is only consulted when OVMF runs on Q35. In that case it is programmed into
|
|
|
|
# the PCIEXBAR register.
|
2019-05-29 11:51:26 +02:00
|
|
|
#
|
|
|
|
# On Q35 machine types that QEMU intends to support in the long term, QEMU
|
OvmfPkg: raise the PCIEXBAR base to 2816 MB on Q35
(This is a replacement for commit 75136b29541b, "OvmfPkg/PlatformPei:
reorder the 32-bit PCI window vs. the PCIEXBAR on q35", 2019-05-16).
Commit 7b8fe63561b4 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG
/ ECAM) on Q35", 2016-03-10) claimed that,
On Q35 machine types that QEMU intends to support in the long term, QEMU
never lets the RAM below 4 GB exceed 2 GB.
Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).
In turn, such a RAM size (justifiedly) triggers
ASSERT (TopOfLowRam <= PciExBarBase);
in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)
In order to fix this, place the PCIEXBAR at 2816MB (0xB000_0000), and
start the 32-bit PCI window at 3 GB (0xC000_0000). This shrinks the 32-bit
PCI window to
0xFC00_0000 - 0xC000_0000 = 0x3C00_0000 = 960 MB.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-05-29 11:59:02 +02:00
|
|
|
# never lets the RAM below 4 GB exceed 2816 MB.
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xB0000000
|
2016-03-03 20:46:22 +01:00
|
|
|
|
2011-08-25 05:19:57 +02:00
|
|
|
!ifdef $(SOURCE_DEBUG_ENABLE)
|
2010-09-12 08:46:55 +02:00
|
|
|
gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2
|
2011-08-25 05:19:57 +02:00
|
|
|
!endif
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2019-05-16 10:18:07 +02:00
|
|
|
#
|
|
|
|
# Network Pcds
|
|
|
|
#
|
|
|
|
!include NetworkPkg/NetworkPcds.dsc.inc
|
2017-01-19 04:53:08 +01:00
|
|
|
|
2011-06-26 20:58:41 +02:00
|
|
|
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
|
|
|
|
|
2015-11-30 19:46:46 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
2016-06-01 19:59:52 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
|
2015-11-30 19:46:46 +01:00
|
|
|
!endif
|
|
|
|
|
2012-09-12 09:19:39 +02:00
|
|
|
# IRQs 5, 9, 10, 11 are level-triggered
|
2019-04-02 09:40:23 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20
|
2012-09-12 09:19:39 +02:00
|
|
|
|
2016-04-18 03:47:55 +02:00
|
|
|
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
#
|
|
|
|
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
|
|
|
|
#
|
|
|
|
################################################################################
|
|
|
|
|
2010-02-24 00:58:38 +01:00
|
|
|
[PcdsDynamicDefault]
|
2017-03-12 22:01:40 +01:00
|
|
|
# only set when
|
|
|
|
# ($(SMM_REQUIRE) == FALSE)
|
2009-09-07 22:18:17 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
|
2017-03-12 22:01:40 +01:00
|
|
|
|
2011-01-16 04:32:47 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
|
2009-09-26 09:15:51 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
|
2013-12-08 02:36:25 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
|
2014-03-22 08:12:36 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
|
2016-04-07 12:19:23 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable|FALSE
|
2014-11-14 01:37:39 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0
|
2016-05-09 22:39:44 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0
|
2016-02-26 16:29:19 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0
|
2009-09-26 09:15:51 +02:00
|
|
|
|
2015-05-06 05:27:42 +02:00
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|0
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2014-11-06 15:21:21 +01:00
|
|
|
# Set video resolution for text setup.
|
2015-05-06 05:27:42 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480
|
2014-11-06 15:21:21 +01:00
|
|
|
|
OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to
3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the
version number of the SMBIOS entry point table (and other things) that
"MdeModulePkg/Universal/SmbiosDxe" installs.
Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7);
those are limited to 2.x (both in the guest kernel firmware driver, and in
the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID --
defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and
guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize
it.
The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware
to install. The payload includes the entry point table ("anchor" table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe"
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that
version.
On machine types older than v2.1.0, the feature is not available, but
then, should anything in OVMF install SMBIOS tables, version 2.8 is simply
safer / more widely supported than 3.0 -- hence the default 2.8 value for
the dynamic PCD.
We set the PCD in PlatformPei (when not on the S3 resume path), because
that's an easy and certain way to set the PCD before a DXE driver reads
it. This follows the example of PcdEmuVariableNvStoreReserved (which is
read by EmuVariableFvbRuntimeDxe).
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22 19:11:05 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0208
|
2015-08-06 12:14:12 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
|
2015-08-06 12:13:55 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
|
OvmfPkg: PlatformPei: set SMBIOS entry point version dynamically
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to
3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the
version number of the SMBIOS entry point table (and other things) that
"MdeModulePkg/Universal/SmbiosDxe" installs.
Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7);
those are limited to 2.x (both in the guest kernel firmware driver, and in
the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID --
defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and
guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize
it.
The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware
to install. The payload includes the entry point table ("anchor" table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe"
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that
version.
On machine types older than v2.1.0, the feature is not available, but
then, should anything in OVMF install SMBIOS tables, version 2.8 is simply
safer / more widely supported than 3.0 -- hence the default 2.8 value for
the dynamic PCD.
We set the PCD in PlatformPei (when not on the S3 resume path), because
that's an easy and certain way to set the PCD before a DXE driver reads
it. This follows the example of PcdEmuVariableNvStoreReserved (which is
read by EmuVariableFvbRuntimeDxe).
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-22 19:11:05 +02:00
|
|
|
|
2015-09-15 10:35:03 +02:00
|
|
|
# Noexec settings for DXE.
|
2015-09-15 10:35:19 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE
|
OvmfPkg: make PcdPropertiesTableEnable dynamic
Since PcdPropertiesTableEnable is used by the DXE Core (in the
InstallPropertiesTable() function, which runs at End-of-Dxe), we must also
change the PcdLib class resolution for that module, from the default
BasePcdLibNull to DxePcdLib.
Traditionally we've considered the DXE Core to be incapable of accessing
dynamic PCDs -- the PCD PPI is not available any longer to the DXE Core,
and the PCD Protocol is not available to it *yet*. There are exceptions
however: if the DXE Core can ensure, by whatever means, that the PCD
Protocol *is* available, then DxePcdLib will just work (the latter even
lists DXE_CORE as an allowed client module type). Namely, DxePcdLib looks
up the PCD Protocol dynamically, on the first library call that actually
needs it (for accessing a dynamic PCD); the lookup doesn't occur in a
library constructor.
And because the DXE Core fetches PcdPropertiesTableEnable at End-of-Dxe,
the PCD Protocol is definitely available then.
In addition, we change the default value of PcdPropertiesTableEnable from
the inherited TRUE to FALSE. It makes no difference at this point (our
runtime DXE drivers are not built with the required 4KB section alignment
anyway), but it's better to be clear about this. The properties table
feature requires OS compatibility, and it breaks Windows 7 minimally.
Therefore the default should be FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18470 6f19259b-4bc3-4df7-8a09-765794883524
2015-09-15 10:35:08 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable|FALSE
|
2015-09-15 10:35:03 +02:00
|
|
|
|
2016-11-24 15:18:44 +01:00
|
|
|
# UefiCpuPkg PCDs related to initial AP bringup and general AP management.
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds|50000
|
|
|
|
|
OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled
Secure Encrypted Virtualization (SEV) guest VMs have the concept of
private and shared memory. Private memory is encrypted with the
guest-specific key, while shared memory may be encrypted with hypervisor
key. Certain types of memory (namely instruction pages and guest page
tables) are always treated as private memory by the hardware.
For data memory, SEV guest VMs can choose which pages they would like
to be private. The choice is done using the standard CPU page tables
using the C-bit. When building the initial page table we mark all the
memory as private.
The patch sets the memory encryption PCD. The PCD is consumed by the
following edk2 modules, which manipulate page tables:
- PEI phase modules: CapsulePei, DxeIplPeim, S3Resume2Pei.
CapsulePei is not used by OVMF. DxeIplPeim consumes the PCD at the
end of the PEI phase, when it builds the initial page tables for the
DXE core / DXE phase. S3Resume2Pei does not consume the PCD in its
entry point function, only when DxeIplPeim branches to the S3 resume
path at the end of the PEI phase, and calls S3Resume2Pei's
EFI_PEI_S3_RESUME2_PPI.S3RestoreConfig2() member function.
Therefore it is safe to set the PCD for these modules in PlatformPei.
- DXE phase modules: BootScriptExecutorDxe, CpuDxe, PiSmmCpuDxeSmm.
They are all dispatched after the PEI phase, so setting the PCD for
them in PlatformPei is safe. (BootScriptExecutorDxe is launched "for
real" in the PEI phase during S3 resume, but it caches the PCD into a
static variable when its entry point is originally invoked in DXE.)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-06 15:25:48 +02:00
|
|
|
# Set memory encryption mask
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask|0x0
|
|
|
|
|
2016-11-17 22:21:35 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
2017-07-04 13:52:34 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8
|
2016-11-17 22:21:35 +01:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode|0x01
|
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
|
|
|
|
!endif
|
|
|
|
|
2017-10-05 22:16:42 +02:00
|
|
|
gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
|
|
|
|
|
2018-02-22 14:20:58 +01:00
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
|
|
|
|
!endif
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
#
|
|
|
|
# Components Section - list of all EDK II Modules needed by this Platform.
|
|
|
|
#
|
|
|
|
################################################################################
|
2010-02-24 00:58:38 +01:00
|
|
|
[Components]
|
2014-08-19 01:04:00 +02:00
|
|
|
OvmfPkg/ResetVector/ResetVector.inf
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
|
|
|
# SEC Phase modules
|
|
|
|
#
|
2010-01-04 17:17:59 +01:00
|
|
|
OvmfPkg/Sec/SecMain.inf {
|
|
|
|
<LibraryClasses>
|
2016-12-01 15:45:12 +01:00
|
|
|
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
|
2010-01-04 17:17:59 +01:00
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# PEI Phase modules
|
|
|
|
#
|
|
|
|
MdeModulePkg/Core/Pei/PeiMain.inf
|
|
|
|
MdeModulePkg/Universal/PCD/Pei/Pcd.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
|
|
|
|
}
|
2017-03-12 23:52:28 +01:00
|
|
|
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
|
|
|
|
}
|
|
|
|
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
|
|
|
|
}
|
2017-03-12 23:59:04 +01:00
|
|
|
MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
|
2009-09-07 22:18:17 +02:00
|
|
|
|
2017-03-12 23:59:04 +01:00
|
|
|
OvmfPkg/PlatformPei/PlatformPei.inf
|
2014-03-04 09:03:06 +01:00
|
|
|
UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf {
|
|
|
|
<LibraryClasses>
|
2015-11-30 19:42:15 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf
|
|
|
|
!endif
|
2014-03-04 09:03:06 +01:00
|
|
|
}
|
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
|
2017-03-12 23:59:04 +01:00
|
|
|
OvmfPkg/SmmAccess/SmmAccessPei.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
|
|
|
!endif
|
2017-03-12 23:59:04 +01:00
|
|
|
UefiCpuPkg/CpuMpPei/CpuMpPei.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2018-02-22 14:20:58 +01:00
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
|
2018-02-22 15:26:34 +01:00
|
|
|
SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.inf
|
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
|
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
|
2018-08-15 05:10:27 +02:00
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
|
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
|
2018-02-22 15:26:34 +01:00
|
|
|
}
|
2019-01-25 22:30:29 +01:00
|
|
|
!if $(TPM2_CONFIG_ENABLE) == TRUE
|
|
|
|
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
|
|
|
|
!endif
|
2018-02-22 14:20:58 +01:00
|
|
|
!endif
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
|
|
|
# DXE Phase modules
|
|
|
|
#
|
|
|
|
MdeModulePkg/Core/Dxe/DxeMain.inf {
|
|
|
|
<LibraryClasses>
|
2016-12-01 15:45:12 +01:00
|
|
|
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
|
2013-08-19 06:15:36 +02:00
|
|
|
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
|
|
|
|
MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
|
|
|
|
}
|
|
|
|
|
|
|
|
MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
|
|
|
|
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
|
|
|
|
<LibraryClasses>
|
2018-03-05 17:14:18 +01:00
|
|
|
!if $(SECURE_BOOT_ENABLE) == TRUE
|
2012-03-09 18:38:53 +01:00
|
|
|
NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
|
OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe
The library registers a security management handler, to measure images
that are not measure in PEI phase. For example with the qemu PXE rom:
Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi
And the following binary_bios_measurements log entry seems to be
added:
PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4
The following order of operations ensures that 3rd party UEFI modules,
such as PCI option ROMs and other modules possibly loaded from outside
of firmware volumes, are measured into the TPM:
(1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2
protocol sometime in the DXE phase (assuming a TPM2 chip is present,
reported via PcdTpmInstanceGuid).
(2) The DXE core finds that no more drivers are left to dispatch from
DXEFV, and we enter the BDS phase.
(3) OVMF's PlatformBootManagerLib connects all PCI root bridges
non-recursively, producing PciIo instances and discovering PCI
oproms.
(4) The dispatching of images that don't originate from FVs is deferred
at this point, by
"MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c".
(5) OVMF's PlatformBootManagerLib signals EndOfDxe.
(6) OVMF's PlatformBootManagerLib calls
EfiBootManagerDispatchDeferredImages() -- the images deferred in
step (4) are now dispatched.
(7) Image dispatch invokes the Security / Security2 Arch protocols
(produced by SecurityStubDxe). In this patch, we hook
DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch
will try to locate the TCG2 protocol, and measure the image into the
TPM2 chip with the protocol. Because of step (1), the TCG2 protocol
will always be found and used (assuming a TPM2 chip is present).
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 19:10:03 +01:00
|
|
|
!endif
|
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
NULL|SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
!endif
|
2018-03-05 17:14:18 +01:00
|
|
|
}
|
2012-03-09 18:38:53 +01:00
|
|
|
|
2009-12-25 07:36:10 +01:00
|
|
|
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
|
2019-04-02 09:40:23 +02:00
|
|
|
OvmfPkg/8259InterruptControllerDxe/8259.inf
|
2009-12-08 06:31:19 +01:00
|
|
|
UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
UefiCpuPkg/CpuDxe/CpuDxe.inf
|
2019-04-02 09:56:26 +02:00
|
|
|
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
|
|
|
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
|
|
|
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
|
2016-01-26 01:18:36 +01:00
|
|
|
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
|
2017-07-06 15:29:24 +02:00
|
|
|
NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf
|
2016-01-26 01:18:36 +01:00
|
|
|
}
|
2013-12-08 02:36:25 +01:00
|
|
|
MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
}
|
2016-08-10 07:31:02 +02:00
|
|
|
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
|
OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14 01:38:17 +01:00
|
|
|
MdeModulePkg/Universal/Metronome/Metronome.inf
|
|
|
|
PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
|
2016-06-28 21:09:53 +02:00
|
|
|
MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
!ifdef $(CSM_ENABLE)
|
|
|
|
NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
|
|
|
|
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
|
|
|
|
!endif
|
|
|
|
}
|
2016-09-26 08:45:06 +02:00
|
|
|
MdeModulePkg/Logo/LogoDxe.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
MdeModulePkg/Application/UiApp/UiApp.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
|
|
|
|
NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
|
|
|
|
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
|
|
|
|
!ifdef $(CSM_ENABLE)
|
|
|
|
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
|
|
|
|
NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
|
|
|
|
!endif
|
|
|
|
}
|
2013-12-11 17:58:22 +01:00
|
|
|
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
|
2016-03-12 18:03:33 +01:00
|
|
|
OvmfPkg/Virtio10Dxe/Virtio10.inf
|
2012-10-08 09:32:59 +02:00
|
|
|
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
|
2012-10-18 19:07:48 +02:00
|
|
|
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
|
2016-02-24 09:27:30 +01:00
|
|
|
OvmfPkg/VirtioRngDxe/VirtioRng.inf
|
2015-02-28 21:33:11 +01:00
|
|
|
OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
|
2014-10-29 07:48:50 +01:00
|
|
|
OvmfPkg/XenBusDxe/XenBusDxe.inf
|
2014-10-29 07:51:42 +01:00
|
|
|
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
|
|
|
|
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
|
|
|
|
MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
|
|
|
|
MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
|
|
|
|
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
|
2014-03-22 08:12:36 +01:00
|
|
|
MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
}
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
|
2013-08-19 06:15:36 +02:00
|
|
|
MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
|
|
|
|
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
|
|
|
|
}
|
2009-06-30 17:57:29 +02:00
|
|
|
MdeModulePkg/Universal/PrintDxe/PrintDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
|
|
|
|
MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
|
2016-03-30 23:49:37 +02:00
|
|
|
MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
|
2016-04-06 07:58:40 +02:00
|
|
|
FatPkg/EnhancedFatDxe/Fat.inf
|
2017-09-08 14:41:48 +02:00
|
|
|
MdeModulePkg/Universal/Disk/UdfDxe/UdfDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.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
|
|
|
OvmfPkg/SataControllerDxe/SataControllerDxe.inf
|
|
|
|
MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
|
|
|
|
MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
|
2016-02-02 16:30:25 +01:00
|
|
|
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
|
|
|
|
MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
|
2013-08-12 04:24:32 +02:00
|
|
|
MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
|
2011-01-21 17:50:47 +01:00
|
|
|
MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTestDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2016-10-11 07:42:24 +02:00
|
|
|
OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
|
2018-06-13 09:29:34 +02:00
|
|
|
OvmfPkg/QemuRamfbDxe/QemuRamfbDxe.inf
|
2016-08-16 17:35:52 +02:00
|
|
|
OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# ISA Support
|
|
|
|
#
|
2019-03-18 03:43:27 +01:00
|
|
|
OvmfPkg/SioBusDxe/SioBusDxe.inf
|
2019-03-22 09:37:50 +01:00
|
|
|
MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
|
|
|
|
MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2011-08-14 00:54:37 +02:00
|
|
|
#
|
|
|
|
# SMBIOS Support
|
|
|
|
#
|
2015-08-06 12:13:42 +02:00
|
|
|
MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
NULL|OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf
|
|
|
|
}
|
2011-08-14 00:54:37 +02:00
|
|
|
OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
|
|
|
# ACPI Support
|
|
|
|
#
|
|
|
|
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
|
2012-05-31 01:15:00 +02:00
|
|
|
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
|
2009-05-27 23:10:18 +02:00
|
|
|
OvmfPkg/AcpiTables/AcpiTables.inf
|
2014-03-04 09:03:50 +01:00
|
|
|
MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
|
2014-03-04 09:04:13 +01:00
|
|
|
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
|
|
|
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
|
2010-07-26 20:07:19 +02:00
|
|
|
|
|
|
|
#
|
|
|
|
# Network Support
|
|
|
|
#
|
2019-05-16 10:18:07 +02:00
|
|
|
!include NetworkPkg/NetworkComponents.dsc.inc
|
|
|
|
|
|
|
|
!if $(NETWORK_TLS_ENABLE) == TRUE
|
2018-03-28 03:04:06 +02:00
|
|
|
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
NULL|OvmfPkg/Library/TlsAuthConfigLib/TlsAuthConfigLib.inf
|
|
|
|
}
|
2014-12-19 20:13:44 +01:00
|
|
|
!endif
|
2013-06-14 09:41:13 +02:00
|
|
|
OvmfPkg/VirtioNetDxe/VirtioNet.inf
|
2010-10-13 09:07:42 +02:00
|
|
|
|
2010-12-31 08:55:38 +01:00
|
|
|
#
|
|
|
|
# Usb Support
|
|
|
|
#
|
|
|
|
MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
|
|
|
|
MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
|
2015-03-16 20:57:34 +01:00
|
|
|
MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
|
2010-12-31 08:55:38 +01:00
|
|
|
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
|
|
|
|
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
|
|
|
|
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
|
|
|
|
|
2011-11-10 23:04:49 +01:00
|
|
|
!ifdef $(CSM_ENABLE)
|
2014-03-31 22:36:15 +02:00
|
|
|
IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
}
|
2011-11-10 23:04:49 +01:00
|
|
|
IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
|
|
|
|
OvmfPkg/Csm/Csm16/Csm16.inf
|
|
|
|
!endif
|
|
|
|
|
2018-11-22 14:41:41 +01:00
|
|
|
!if $(TOOL_CHAIN_TAG) != "XCODE5"
|
2017-11-28 09:35:06 +01:00
|
|
|
ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf {
|
|
|
|
<PcdsFixedAtBuild>
|
|
|
|
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
|
|
|
|
}
|
2018-11-22 14:41:41 +01:00
|
|
|
!endif
|
2011-06-26 20:58:41 +02:00
|
|
|
ShellPkg/Application/Shell/Shell.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
|
|
|
|
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
|
2016-03-08 10:50:44 +01:00
|
|
|
!if $(NETWORK_IP6_ENABLE) == TRUE
|
|
|
|
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
|
|
|
|
!endif
|
2011-06-26 20:58:41 +02:00
|
|
|
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
|
|
|
|
PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
|
2014-09-11 21:11:37 +02:00
|
|
|
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
|
2011-06-26 20:58:41 +02:00
|
|
|
|
|
|
|
<PcdsFixedAtBuild>
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0xFF
|
|
|
|
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
|
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
|
|
|
|
}
|
|
|
|
|
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
|
|
|
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
|
2019-04-25 13:15:13 +02:00
|
|
|
OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.inf
|
2012-03-09 18:38:53 +01:00
|
|
|
!endif
|
2014-03-22 08:12:55 +01:00
|
|
|
|
|
|
|
OvmfPkg/PlatformDxe/Platform.inf
|
2017-07-06 15:28:40 +02:00
|
|
|
OvmfPkg/IoMmuDxe/IoMmuDxe.inf
|
2015-11-30 19:41:43 +01:00
|
|
|
|
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
|
2015-11-30 19:41:48 +01:00
|
|
|
OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
|
2015-11-30 19:46:55 +01:00
|
|
|
UefiCpuPkg/CpuS3DataDxe/CpuS3DataDxe.inf
|
2015-11-30 19:41:52 +01:00
|
|
|
|
|
|
|
#
|
|
|
|
# SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
|
|
|
|
#
|
|
|
|
MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
|
|
|
|
|
|
|
|
#
|
|
|
|
# SMM_CORE
|
|
|
|
#
|
|
|
|
MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
|
2015-11-30 19:41:56 +01:00
|
|
|
|
|
|
|
#
|
|
|
|
# Privileged drivers (DXE_SMM_DRIVER modules)
|
|
|
|
#
|
|
|
|
UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
|
2015-11-30 19:42:15 +01:00
|
|
|
MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf
|
|
|
|
}
|
2015-11-30 19:48:46 +01:00
|
|
|
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
SmmCpuPlatformHookLib|UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLibNull.inf
|
|
|
|
SmmCpuFeaturesLib|OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
|
|
|
|
}
|
2015-11-30 19:48:59 +01:00
|
|
|
|
|
|
|
#
|
2015-11-30 19:49:03 +01:00
|
|
|
# Variable driver stack (SMM)
|
|
|
|
#
|
|
|
|
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf
|
|
|
|
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.inf
|
|
|
|
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
|
|
|
|
}
|
|
|
|
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf
|
|
|
|
|
|
|
|
!else
|
|
|
|
|
|
|
|
#
|
|
|
|
# Variable driver stack (non-SMM)
|
2015-11-30 19:48:59 +01:00
|
|
|
#
|
|
|
|
OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
|
|
|
|
OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
PlatformFvbLib|OvmfPkg/Library/EmuVariableFvbLib/EmuVariableFvbLib.inf
|
|
|
|
}
|
|
|
|
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
|
|
|
|
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
|
|
|
|
}
|
2015-11-30 19:49:03 +01:00
|
|
|
!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
|
|
|
|
|
|
|
!if $(TPM2_ENABLE) == TRUE
|
|
|
|
SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf {
|
|
|
|
<LibraryClasses>
|
|
|
|
Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf
|
|
|
|
NULL|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf
|
|
|
|
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
|
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
|
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
|
2018-08-15 05:10:27 +02:00
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
|
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
|
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
|