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
|
|
|
|
|
#
|
2020-06-10 04:56:34 +02:00
|
|
|
# Copyright (c) 2006 - 2020, 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/Ovmf3264
|
|
|
|
|
SUPPORTED_ARCHITECTURES = IA32|X64
|
2016-10-10 17:43:24 +02:00
|
|
|
BUILD_TARGETS = NOOPT|DEBUG|RELEASE
|
2009-05-27 23:10:18 +02:00
|
|
|
SKUID_IDENTIFIER = DEFAULT
|
|
|
|
|
FLASH_DEFINITION = OvmfPkg/OvmfPkgIa32X64.fdf
|
|
|
|
|
|
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
|
2019-09-20 20:45:07 +02:00
|
|
|
DEFINE SOURCE_DEBUG_ENABLE = FALSE
|
2020-02-26 16:24:29 +01:00
|
|
|
DEFINE TPM_ENABLE = FALSE
|
|
|
|
|
DEFINE TPM_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
|
|
|
|
|
|
2020-03-28 21:00:44 +01:00
|
|
|
#
|
|
|
|
|
# Device drivers
|
|
|
|
|
#
|
|
|
|
|
DEFINE PVSCSI_ENABLE = TRUE
|
2020-05-04 23:05:56 +02:00
|
|
|
DEFINE MPT_SCSI_ENABLE = TRUE
|
2020-07-17 08:11:20 +02:00
|
|
|
DEFINE LSI_SCSI_ENABLE = FALSE
|
2020-03-28 21:00:44 +01:00
|
|
|
|
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
|
2019-11-14 09:04:01 +01:00
|
|
|
!if $(TOOL_CHAIN_TAG) != "XCODE5" && $(TOOL_CHAIN_TAG) != "CLANGPDB"
|
2010-12-31 08:55:51 +01:00
|
|
|
GCC:*_*_*_CC_FLAGS = -mno-mmx -mno-sse
|
2018-01-10 16:24:32 +01:00
|
|
|
!endif
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2012-10-03 23:00:26 +02:00
|
|
|
MSFT:*_*_X64_GENFW_FLAGS = --keepexceptiontable
|
|
|
|
|
GCC:*_*_X64_GENFW_FLAGS = --keepexceptiontable
|
|
|
|
|
INTEL:*_*_X64_GENFW_FLAGS = --keepexceptiontable
|
|
|
|
|
!endif
|
2015-09-30 10:53:00 +02: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
|
2020-03-29 15:21:58 +02:00
|
|
|
XCODE:*_*_*_DLINK_FLAGS = -seg1addr 0x1000 -segalign 0x1000
|
|
|
|
|
XCODE:*_*_*_MTOC_FLAGS = -align 0x1000
|
2019-11-14 09:04:01 +01:00
|
|
|
CLANGPDB:*_*_*_DLINK_FLAGS = /ALIGN:4096
|
2016-04-06 07:58:40 +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
|
2020-03-29 15:21:58 +02:00
|
|
|
XCODE:*_*_*_DLINK_FLAGS = -seg1addr 0x1000 -segalign 0x1000
|
|
|
|
|
XCODE:*_*_*_MTOC_FLAGS = -align 0x1000
|
2019-11-14 09:04:01 +01:00
|
|
|
CLANGPDB:*_*_*_DLINK_FLAGS = /ALIGN:4096
|
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
|
2020-04-17 17:37:50 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/BaseResetSystemLib.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-07-26 05:14:08 +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
|
2020-04-24 09:53:47 +02:00
|
|
|
QemuFwCfgSimpleParserLib|OvmfPkg/Library/QemuFwCfgSimpleParserLib/QemuFwCfgSimpleParserLib.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-09-12 08:46:55 +02:00
|
|
|
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2010-09-12 08:46:55 +02:00
|
|
|
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
|
|
|
|
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
|
2015-07-01 05:05:47 +02:00
|
|
|
AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
|
|
|
|
|
!else
|
|
|
|
|
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
|
2019-08-13 13:30:58 +02:00
|
|
|
XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
|
2014-03-04 09:03:50 +01:00
|
|
|
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
2020-02-26 16:24:30 +01:00
|
|
|
Tpm12CommandLib|SecurityPkg/Library/Tpm12CommandLib/Tpm12CommandLib.inf
|
2018-02-22 14:20:58 +01:00
|
|
|
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
|
OvmfPkg: use DxeTpmMeasurementLib if and only if TPM2_ENABLE
(a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for
SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance
became dependent on TpmMeasurementLib. For details, refer to commit
0d28d286bf4d ("OvmfPkg: resolve TpmMeasurementLib dependency
introduced in r14687", 2013-09-21).
(b) At the time, only one instance of TpmMeasurementLib existed, namely
DxeTpmMeasurementLib. This lib instance didn't do anything -- like it
was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE
protocol implementations.
(c) In commit 308521b13354 ("MdeModulePkg: Move TpmMeasurementLib
LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was
introduced.
(d) In commit 285542ebbb03 ("OvmfPkg: Link AuthVariableLib for following
merged variable driver deploy", 2015-07-01), a TpmMeasurementLib
resolution became necessary regardless of SECURE_BOOT_ENABLE. And so
TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but
only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the
larger series containing commit 285542ebbb03 -- missed an opportunity
for simplification: given (b), the DxeTpmMeasurementLib instance
should have been simply replaced with the TpmMeasurementLibNull
instance, regardless of SECURE_BOOT_ENABLE.
(e) In commit 1abfa4ce4835 ("Add TPM2 support defined in trusted computing
group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2
dependency in DxeTpmMeasurementLib.
(f) Starting with commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module",
2018-03-09), OVMF would include a Tcg2 protocol implementation,
thereby satisfying DxeTpmMeasurementLib's dependency. With
TPM2_ENABLE, it would actually make sense to consume
DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be
used without SECURE_BOOT_ENABLE.
Therefore, we have the following four scenarios:
- TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected.
- Neither enabled: works as expected.
- Only TPM2_ENABLE: this build is currently incorrect, because
Variable/RuntimeDxe consumes TpmMeasurementLib directly, but
TpmMeasureAndLogData() will never reach the TPM because we link
TpmMeasurementLibNull into the variable driver. This is a problem from
the larger series containing (f).
- Only SECURE_BOOT_ENABLE: this build works as expected, but it is
wasteful -- given that the protocol database will never contain Tcg2
without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is
a problem from (d).
Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of
*only* TPM2_ENABLE, we can fix / optimize the last two cases.
v2:
- Amend the title and description suggested by Laszlo
- Move TpmMeasurementLib to the existed TPM2_ENABLE block
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190704040731.5303-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-07-04 06:07:59 +02:00
|
|
|
TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.inf
|
2018-05-18 14:23:01 +02:00
|
|
|
!else
|
|
|
|
|
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
|
OvmfPkg: use DxeTpmMeasurementLib if and only if TPM2_ENABLE
(a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for
SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance
became dependent on TpmMeasurementLib. For details, refer to commit
0d28d286bf4d ("OvmfPkg: resolve TpmMeasurementLib dependency
introduced in r14687", 2013-09-21).
(b) At the time, only one instance of TpmMeasurementLib existed, namely
DxeTpmMeasurementLib. This lib instance didn't do anything -- like it
was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE
protocol implementations.
(c) In commit 308521b13354 ("MdeModulePkg: Move TpmMeasurementLib
LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was
introduced.
(d) In commit 285542ebbb03 ("OvmfPkg: Link AuthVariableLib for following
merged variable driver deploy", 2015-07-01), a TpmMeasurementLib
resolution became necessary regardless of SECURE_BOOT_ENABLE. And so
TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but
only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the
larger series containing commit 285542ebbb03 -- missed an opportunity
for simplification: given (b), the DxeTpmMeasurementLib instance
should have been simply replaced with the TpmMeasurementLibNull
instance, regardless of SECURE_BOOT_ENABLE.
(e) In commit 1abfa4ce4835 ("Add TPM2 support defined in trusted computing
group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2
dependency in DxeTpmMeasurementLib.
(f) Starting with commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module",
2018-03-09), OVMF would include a Tcg2 protocol implementation,
thereby satisfying DxeTpmMeasurementLib's dependency. With
TPM2_ENABLE, it would actually make sense to consume
DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be
used without SECURE_BOOT_ENABLE.
Therefore, we have the following four scenarios:
- TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected.
- Neither enabled: works as expected.
- Only TPM2_ENABLE: this build is currently incorrect, because
Variable/RuntimeDxe consumes TpmMeasurementLib directly, but
TpmMeasureAndLogData() will never reach the TPM because we link
TpmMeasurementLibNull into the variable driver. This is a problem from
the larger series containing (f).
- Only SECURE_BOOT_ENABLE: this build works as expected, but it is
wasteful -- given that the protocol database will never contain Tcg2
without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is
a problem from (d).
Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of
*only* TPM2_ENABLE, we can fix / optimize the last two cases.
v2:
- Amend the title and description suggested by Laszlo
- Move TpmMeasurementLib to the existed TPM2_ENABLE block
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190704040731.5303-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-07-04 06:07:59 +02:00
|
|
|
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.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-07-26 20:07:19 +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
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2010-09-12 08:46:55 +02:00
|
|
|
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
|
2020-05-07 15:06:49 +02:00
|
|
|
!if $(TOOL_CHAIN_TAG) == "XCODE5"
|
|
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
|
|
|
|
|
!else
|
2013-11-22 07:31:18 +01:00
|
|
|
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
|
2020-05-07 15:06:49 +02:00
|
|
|
!endif
|
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
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2010-09-12 08:46:55 +02:00
|
|
|
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
|
|
|
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
2018-02-22 15:26:34 +01:00
|
|
|
BaseCryptLib|CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
|
2020-02-26 16:24:30 +01:00
|
|
|
Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.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
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2010-09-12 08:46:55 +02:00
|
|
|
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
|
OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-17 17:37:51 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.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
|
OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-17 17:37:51 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.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
|
OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-17 17:37:51 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.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
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2014-03-04 09:04:20 +01:00
|
|
|
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
|
2020-02-29 10:31:34 +01:00
|
|
|
QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
2020-02-26 16:24:32 +01:00
|
|
|
Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.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
|
|
|
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
|
OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-17 17:37:51 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.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
|
OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-17 17:37:51 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.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
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2015-11-30 19:42:27 +01:00
|
|
|
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
|
OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instance
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
2020-04-17 17:37:51 +02:00
|
|
|
ResetSystemLib|OvmfPkg/Library/ResetSystemLib/DxeResetSystemLib.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-03-15 02:40:59 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSupportUefiDecompress|FALSE
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode|TRUE
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
|
2016-04-19 09:17:03 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
|
2020-01-29 19:53:18 +01:00
|
|
|
!ifdef $(CSM_ENABLE)
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable|TRUE
|
|
|
|
|
!endif
|
2015-11-30 19:41:10 +01:00
|
|
|
!if $(SMM_REQUIRE) == TRUE
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|TRUE
|
OvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmm
Set "PcdCpuHotPlugSupport" to TRUE, when OVMF is built with SMM_REQUIRE.
Consequences:
(1) In PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c],
resources are allocated and populated in advance for all possible
(i.e., potentially hot-added) processors, rather than only the
processors present at boot.
The possible count (called "mMaxNumberOfCpus") is set from
"PcdCpuMaxLogicalProcessorNumber"; we set the latter in
OvmfPkg/PlatformPei. (Refer to commit 83357313dd67,
"OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU
hotplug", 2020-01-29).
(2) The AddProcessor() and RemoveProcessor() member functions of
EFI_SMM_CPU_SERVICE_PROTOCOL, implemented in
"UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c", are no longer
short-circuited to EFI_UNSUPPORTED.
We'll rely on these functions in the CPU hotplug SMI handler, in a
subsequent patch.
(3) In PiCpuSmmEntry(), the address of the CPU_HOT_PLUG_DATA structure (in
SMRAM) is exposed via the dynamic-only "PcdCpuHotPlugDataAddress".
This structure is an information channel between the CPU hotplug SMI
handler, and EFI_SMM_CPU_SERVICE_PROTOCOL. Namely, at the first
"Index" where the following equality holds:
CPU_HOT_PLUG_DATA.ApicId[Index] == INVALID_APIC_ID
a hot-plugged CPU can be accepted, with the steps below:
(3.1) The hotplug SMI handler has to overwrite INVALID_APIC_ID with the
new CPU's APIC ID.
(3.2) The new CPU's SMBASE has to be relocated to:
CPU_HOT_PLUG_DATA.SmBase[Index]
(which was precomputed in step (1) above).
(3.3) The hotplug SMI handler is supposed to call
EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor().
Note: we need not spell out "PcdCpuHotPlugDataAddress" in the
[PcdsDynamicDefault] sections of the OVMF DSC files, just so the PCD
become dynamically settable. That's because "UefiCpuPkg.dec" declares this
PCD with [PcdsDynamic, PcdsDynamicEx] access methods *only*.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-02-26 23:11:45 +01:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuHotPlugSupport|TRUE
|
2019-10-14 19:14:24 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache|FALSE
|
2015-11-30 19:41:10 +01:00
|
|
|
!endif
|
2010-03-15 02:40:59 +01:00
|
|
|
|
2010-02-24 00:58:38 +01:00
|
|
|
[PcdsFixedAtBuild]
|
2009-12-25 07:36:10 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
|
OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Secure SMM Communication
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf
--^--
bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call
for action", recommend enabling the (adaptive) Memory Type Information
feature.
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
--^--
figure#6 describes the Memory Type Information feature in detail; namely
as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE
Core, and BDS.
Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling
the Secure SMM Communication recommendation.
In the longer term, OVMF should install the WSMT ACPI table, and this
patch contributes to that.
Notes:
- the step in figure#6 where the UEFI variable is copied into the HOB is
covered by the DXE IPL PEIM, in the DxeLoadCore() function,
- "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC
default TRUE value, because both whitepapers indicate that BDS needs to
reset the system if the Memory Type Information changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-6-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:39 +01:00
|
|
|
!if $(SMM_REQUIRE) == FALSE
|
2011-08-25 05:19:57 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
|
OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Secure SMM Communication
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Security-White-Papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdf
--^--
bullet#3 in section "Assumption and Recommendation", and bullet#4 in "Call
for action", recommend enabling the (adaptive) Memory Type Information
feature.
* In the Intel whitepaper:
--v--
A Tour Beyond BIOS -- Memory Map and Practices in UEFI BIOS
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-white-papers
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
--^--
figure#6 describes the Memory Type Information feature in detail; namely
as a feedback loop between the Platform PEIM, the DXE IPL PEIM, the DXE
Core, and BDS.
Implement the missing PlatformPei functionality in OvmfPkg, for fulfilling
the Secure SMM Communication recommendation.
In the longer term, OVMF should install the WSMT ACPI table, and this
patch contributes to that.
Notes:
- the step in figure#6 where the UEFI variable is copied into the HOB is
covered by the DXE IPL PEIM, in the DxeLoadCore() function,
- "PcdResetOnMemoryTypeInformationChange" must be reverted to the DEC
default TRUE value, because both whitepapers indicate that BDS needs to
reset the system if the Memory Type Information changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-6-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:39 +01:00
|
|
|
!endif
|
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
|
2020-06-10 04:56:34 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|TRUE
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
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
|
|
|
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
2010-09-12 08:46:55 +02:00
|
|
|
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
|
|
|
|
2019-09-20 20:45:07 +02:00
|
|
|
!if $(SOURCE_DEBUG_ENABLE) == TRUE
|
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
|
|
|
|
2020-05-08 14:16:50 +02:00
|
|
|
[PcdsFixedAtBuild.IA32]
|
|
|
|
|
#
|
|
|
|
|
# The NumberOfPages values below are ad-hoc. They are updated sporadically at
|
|
|
|
|
# best (please refer to git-blame for past updates). The values capture a set
|
|
|
|
|
# of BIN hints that made sense at a particular time, for some (now likely
|
|
|
|
|
# unknown) workloads / boot paths.
|
|
|
|
|
#
|
2020-05-08 14:16:51 +02:00
|
|
|
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x80
|
|
|
|
|
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x10
|
|
|
|
|
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x80
|
|
|
|
|
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100
|
|
|
|
|
gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100
|
2020-05-08 14:16:50 +02:00
|
|
|
|
2016-04-29 08:20:31 +02:00
|
|
|
[PcdsFixedAtBuild.X64]
|
2019-05-16 10:18:07 +02:00
|
|
|
#
|
|
|
|
|
# Network Pcds
|
|
|
|
|
#
|
|
|
|
|
!include NetworkPkg/NetworkPcds.dsc.inc
|
2017-01-19 04:53:08 +01:00
|
|
|
|
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
|
|
|
|
OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE
The following flash-related base addresses:
- PcdFlashNvStorageVariableBase64,
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase,
are always set to constant (invariable) values in the "-D SMM_REQUIRE"
build of OVMF. (That's because in the SMM build, actual pflash is a hard
requirement, and the RAM-based emulation is never available.)
Set said PCDs statically, at build. This will allow us to depend on their
values in the PEI phase.
When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report
file comparison).
When SMM_REQUIRE is TRUE, the report file shows the following changes:
- "PcdOvmfFlashNvStorageFtwSpareBase" and
"PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any
module directly,
- for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase"
and "PcdFlashNvStorageVariableBase64", the access method changes from
DYN to FIXED,
- for the latter PCDs, the zero (dynamic default) values are replaced with
the desired constants.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-4-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:37 +01:00
|
|
|
!if $(SMM_REQUIRE) == FALSE
|
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
|
OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE
The following flash-related base addresses:
- PcdFlashNvStorageVariableBase64,
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase,
are always set to constant (invariable) values in the "-D SMM_REQUIRE"
build of OVMF. (That's because in the SMM build, actual pflash is a hard
requirement, and the RAM-based emulation is never available.)
Set said PCDs statically, at build. This will allow us to depend on their
values in the PEI phase.
When SMM_REQUIRE is FALSE, this change has no effect (confirmed by report
file comparison).
When SMM_REQUIRE is TRUE, the report file shows the following changes:
- "PcdOvmfFlashNvStorageFtwSpareBase" and
"PcdOvmfFlashNvStorageFtwWorkingBase" are no longer consumed by any
module directly,
- for "PcdFlashNvStorageFtwSpareBase", "PcdFlashNvStorageFtwWorkingBase"
and "PcdFlashNvStorageVariableBase64", the access method changes from
DYN to FIXED,
- for the latter PCDs, the zero (dynamic default) values are replaced with
the desired constants.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-4-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:37 +01:00
|
|
|
!endif
|
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
|
OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXE
The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.
Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):
- the memory hotplug area (optional, the size comes from QEMU),
- the 64-bit PCI host aperture (we set a default size).
While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.
(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)
Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).
As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option
-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536
The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).
For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.
For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ref: https://github.com/tianocore/edk2/issues/59
Ref: http://www.nvidia.com/object/tesla-servers.html
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-04 19:30:45 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0
|
2019-06-26 13:37:42 +02:00
|
|
|
!ifdef $(CSM_ENABLE)
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0
|
|
|
|
|
!else
|
OvmfPkg: PlatformPei: determine the 64-bit PCI host aperture for X64 DXE
The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.
Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):
- the memory hotplug area (optional, the size comes from QEMU),
- the 64-bit PCI host aperture (we set a default size).
While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.
(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)
Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).
As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option
-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536
The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).
For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.
For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ref: https://github.com/tianocore/edk2/issues/59
Ref: http://www.nvidia.com/object/tesla-servers.html
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-04 19:30:45 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x800000000
|
2019-06-26 13:37:42 +02:00
|
|
|
!endif
|
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
|
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
|
OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug
MaxCpuCountInitialization() currently handles the following options:
(1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0)
In this case, PlatformPei makes MpInitLib enumerate APs up to the
default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until
the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses.
(Whichever is reached first.)
Time-limited AP enumeration had never been reliable on QEMU/KVM, which
is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF.
(2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero)
In this case, PlatformPei sets
- PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count
(FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"),
- and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity"
(MAX_UINT32, ~71 minutes).
That causes MpInitLib to enumerate exactly the present (boot) APs.
With CPU hotplug in mind, this method is not good enough. Because,
using QEMU terminology, UefiCpuPkg expects
PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count
("MachineState.smp.max_cpus"), which includes present and not present
CPUs both (with not present CPUs being subject for hot-plugging).
FW_CFG_NB_CPUS does not include not present CPUs.
Rewrite MaxCpuCountInitialization() for handling the following cases:
(1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set
to values different from the defaults.)
(2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via
FW_CFG_NB_CPUS), but not the possible CPUs count
("MachineState.smp.max_cpus").
In this case, the behavior remains unchanged.
The way MpInitLib is instructed to do the same differs however: we now
set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count
(while continuing to set PcdCpuMaxLogicalProcessorNumber identically).
PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant.
(3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via
FW_CFG_NB_CPUS), and the possible CPUs count
("MachineState.smp.max_cpus").
We tell UefiCpuPkg about the possible CPUs count through
PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU
count for precise and quick AP enumeration, via
PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is
irrelevant again.
This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE.
As a side effect, the patch also enables S3 to work with CPU hotplug at
once, *without* SMM_REQUIRE.
(Without the patch, S3 resume fails, if a CPU is hot-plugged at OS
runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume
causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not
permitted.
With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely
"MachineState.smp.max_cpus". Therefore, the CPU structures allocated
during normal boot can accommodate the CPUs at S3 resume that have been
hotplugged prior to S3 suspend.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191022221554.14963-4-lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-10-08 09:15:38 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber|0
|
2016-11-24 15:18:44 +01:00
|
|
|
|
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
|
2019-09-20 10:56:47 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase|FALSE
|
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
|
|
|
|
|
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
2018-02-22 14:20:58 +01:00
|
|
|
gEfiSecurityPkgTokenSpaceGuid.PcdTpmInstanceGuid|{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
|
|
|
|
|
!endif
|
|
|
|
|
|
OvmfPkg: control PXEv4 / PXEv6 boot support from the QEMU command line
Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting
the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from
fw_cfg.
These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6
boot. If a PXE version is disabled, the corresponding LoadFile protocol
instance is not produced by UefiPxeBcDxe, and so
EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not
generate corresponding *new* boot options either. (Existent boot options
are not deleted.)
Hook the library into the UefiPxeBcDxe driver. (The driver is already
included from "NetworkComponents.dsc.inc", but we can list it again in the
DSC file, for providing <LibraryClasses> overrides.)
In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does
not have fw_cfg access in the PEI phase. Hence a NULL class library that
can be linked into UefiPxeBcDxe.
When listing the PCDs under [PcdsDynamicDefault], stick with the DEC
default values.
QEMU switches:
-fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn]
-fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn]
The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation
from QEMU's "docs/specs/fw_cfg.txt".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-04-24 09:53:51 +02:00
|
|
|
[PcdsDynamicDefault.X64]
|
|
|
|
|
# IPv4 and IPv6 PXE Boot support.
|
|
|
|
|
gEfiNetworkPkgTokenSpaceGuid.PcdIPv4PXESupport|0x01
|
|
|
|
|
gEfiNetworkPkgTokenSpaceGuid.PcdIPv6PXESupport|0x01
|
|
|
|
|
|
2020-01-08 15:38:43 +01:00
|
|
|
[PcdsDynamicHii]
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE && $(TPM_CONFIG_ENABLE) == TRUE
|
2020-01-08 15:38:43 +01:00
|
|
|
gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x0|"1.3"|NV,BS
|
|
|
|
|
gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev|L"TCG2_VERSION"|gTcg2ConfigFormSetGuid|0x8|3|NV,BS
|
|
|
|
|
!endif
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# Components Section - list of all EDK II Modules needed by this Platform.
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
[Components.IA32]
|
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
|
OvmfPkg: include FaultTolerantWritePei and VariablePei with -D SMM_REQUIRE
FaultTolerantWritePei consumes:
- PcdFlashNvStorageFtwWorkingBase,
- PcdFlashNvStorageFtwSpareBase.
VariablePei consumes:
- PcdFlashNvStorageVariableBase64.
Due to the previous patches in this series, the above PCDs are available
in the PEI phase, in the SMM_REQUIRE build.
FaultTolerantWritePei produces a GUID-ed HOB with
FAULT_TOLERANT_WRITE_LAST_WRITE_DATA as contents. It also installs a Null
PPI that carries the same gEdkiiFaultTolerantWriteGuid as the HOB.
VariablePei depends on the Null PPI mentioned above with a DEPEX, consumes
the HOB (which is safe due to the DEPEX), and produces
EFI_PEI_READ_ONLY_VARIABLE2_PPI.
This enables read-only access to non-volatile UEFI variables in the PEI
phase, in the SMM_REQUIRE build.
For now, the DxeLoadCore() function in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c" will not access the
"MemoryTypeInformation" variable, because OVMF's PlatformPei always
produces the MemoryTypeInformation HOB.
(Note: when the boot mode is BOOT_ON_S3_RESUME, PlatformPei doesn't build
the HOB, but that's in sync with DxeLoadCore() also not looking for either
the HOB or the UEFI variable.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200310222739.26717-5-lersek@redhat.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
2020-03-10 23:27:38 +01:00
|
|
|
MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
|
|
|
|
|
MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
|
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
|
|
|
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
2018-02-22 14:20:58 +01:00
|
|
|
OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf
|
2020-02-26 16:24:31 +01:00
|
|
|
SecurityPkg/Tcg/TcgPei/TcgPei.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
|
2019-07-19 00:53:26 +02:00
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.inf
|
2018-02-22 15:26:34 +01:00
|
|
|
}
|
2018-02-22 14:20:58 +01:00
|
|
|
!endif
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[Components.X64]
|
|
|
|
|
#
|
|
|
|
|
# DXE Phase modules
|
|
|
|
|
#
|
|
|
|
|
MdeModulePkg/Core/Dxe/DxeMain.inf {
|
|
|
|
|
<LibraryClasses>
|
2016-12-01 15:45:12 +01:00
|
|
|
NULL|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
|
2013-07-26 05:14:08 +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
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
2020-02-26 16:24:33 +01:00
|
|
|
NULL|SecurityPkg/Library/DxeTpmMeasureBootLib/DxeTpmMeasureBootLib.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
|
|
|
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
|
2019-05-15 09:15:53 +02:00
|
|
|
NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
!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)
|
2019-05-15 09:15:53 +02:00
|
|
|
NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
|
|
|
|
|
NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
|
2016-04-18 03:47:55 +02:00
|
|
|
!endif
|
|
|
|
|
}
|
2020-02-29 10:31:34 +01:00
|
|
|
OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.inf
|
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
|
2020-03-28 21:00:44 +01:00
|
|
|
!if $(PVSCSI_ENABLE) == TRUE
|
|
|
|
|
OvmfPkg/PvScsiDxe/PvScsiDxe.inf
|
2020-05-04 23:05:56 +02:00
|
|
|
!endif
|
|
|
|
|
!if $(MPT_SCSI_ENABLE) == TRUE
|
|
|
|
|
OvmfPkg/MptScsiDxe/MptScsiDxe.inf
|
2020-07-17 08:11:20 +02:00
|
|
|
!endif
|
|
|
|
|
!if $(LSI_SCSI_ENABLE) == TRUE
|
|
|
|
|
OvmfPkg/LsiScsiDxe/LsiScsiDxe.inf
|
2020-03-28 21:00:44 +01:00
|
|
|
!endif
|
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-07-26 05:14:08 +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
|
|
|
|
2019-06-26 13:37:41 +02:00
|
|
|
!ifndef $(CSM_ENABLE)
|
2016-10-11 07:42:24 +02:00
|
|
|
OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
|
2019-06-26 13:37:41 +02:00
|
|
|
!endif
|
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
|
|
|
|
|
|
OvmfPkg: control PXEv4 / PXEv6 boot support from the QEMU command line
Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting
the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from
fw_cfg.
These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6
boot. If a PXE version is disabled, the corresponding LoadFile protocol
instance is not produced by UefiPxeBcDxe, and so
EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not
generate corresponding *new* boot options either. (Existent boot options
are not deleted.)
Hook the library into the UefiPxeBcDxe driver. (The driver is already
included from "NetworkComponents.dsc.inc", but we can list it again in the
DSC file, for providing <LibraryClasses> overrides.)
In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does
not have fw_cfg access in the PEI phase. Hence a NULL class library that
can be linked into UefiPxeBcDxe.
When listing the PCDs under [PcdsDynamicDefault], stick with the DEC
default values.
QEMU switches:
-fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn]
-fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn]
The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation
from QEMU's "docs/specs/fw_cfg.txt".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2020-04-24 09:53:51 +02:00
|
|
|
NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf {
|
|
|
|
|
<LibraryClasses>
|
|
|
|
|
NULL|OvmfPkg/Library/PxeBcPcdProducerLib/PxeBcPcdProducerLib.inf
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-16 10:18:07 +02:00
|
|
|
!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)
|
2019-05-15 09:15:53 +02:00
|
|
|
OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
|
2014-03-31 22:36:15 +02:00
|
|
|
<LibraryClasses>
|
|
|
|
|
PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
|
|
|
|
|
}
|
2019-05-15 09:15:53 +02:00
|
|
|
OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
|
2011-11-10 23:04:49 +01:00
|
|
|
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
|
|
|
|
|
}
|
2020-02-26 20:43:41 +01:00
|
|
|
OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.inf {
|
|
|
|
|
<PcdsFixedAtBuild>
|
|
|
|
|
gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
|
|
|
|
|
}
|
2020-05-14 15:48:22 +02: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:26:45 +02:00
|
|
|
OvmfPkg/AmdSevDxe/AmdSevDxe.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
|
2020-02-26 23:11:54 +01:00
|
|
|
OvmfPkg/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)
|
|
|
|
|
#
|
2020-02-26 23:11:46 +01:00
|
|
|
OvmfPkg/CpuHotplugSmm/CpuHotplugSmm.inf
|
2015-11-30 19:41:56 +01:00
|
|
|
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>
|
2020-02-26 23:11:43 +01:00
|
|
|
SmmCpuPlatformHookLib|OvmfPkg/Library/SmmCpuPlatformHookLibQemu/SmmCpuPlatformHookLibQemu.inf
|
2015-11-30 19:48:46 +01:00
|
|
|
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
|
|
|
|
2020-01-08 15:38:42 +01:00
|
|
|
#
|
2020-02-26 16:24:29 +01:00
|
|
|
# TPM support
|
2020-01-08 15:38:42 +01:00
|
|
|
#
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_ENABLE) == TRUE
|
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
|
|
|
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
|
2019-07-19 00:53:26 +02:00
|
|
|
NULL|SecurityPkg/Library/HashInstanceLibSm3/HashInstanceLibSm3.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
|
|
|
}
|
2020-02-26 16:24:29 +01:00
|
|
|
!if $(TPM_CONFIG_ENABLE) == TRUE
|
2020-01-08 15:38:42 +01:00
|
|
|
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
|
|
|
|
|
!endif
|
2020-02-26 16:24:32 +01:00
|
|
|
SecurityPkg/Tcg/TcgDxe/TcgDxe.inf {
|
|
|
|
|
<LibraryClasses>
|
|
|
|
|
Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.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
|
