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
|
|
|
|
|
#
|
2013-11-12 19:34:11 +01:00
|
|
|
# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
|
2009-05-27 23:10:18 +02:00
|
|
|
#
|
2010-04-28 14:43:04 +02:00
|
|
|
# This program and the accompanying materials
|
2009-05-27 23:10:18 +02:00
|
|
|
# are licensed and made available under the terms and conditions of the BSD License
|
|
|
|
|
# which accompanies this distribution. The full text of the license may be found at
|
|
|
|
|
# http://opensource.org/licenses/bsd-license.php
|
2012-09-12 09:18:21 +02:00
|
|
|
#
|
2009-05-27 23:10:18 +02:00
|
|
|
# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
|
|
|
|
|
# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
|
|
|
|
|
#
|
2010-02-24 00:58:38 +01:00
|
|
|
##
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
[Defines]
|
2011-06-28 04:24:46 +02:00
|
|
|
DEC_SPECIFICATION = 0x00010005
|
2009-05-27 23:10:18 +02:00
|
|
|
PACKAGE_NAME = OvmfPkg
|
|
|
|
|
PACKAGE_GUID = 2daf5f34-50e5-4b9d-b8e3-5562334d87e5
|
|
|
|
|
PACKAGE_VERSION = 0.1
|
|
|
|
|
|
2009-09-16 18:28:55 +02:00
|
|
|
[Includes]
|
|
|
|
|
Include
|
|
|
|
|
|
Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 19:50:40 +02:00
|
|
|
[LibraryClasses]
|
2012-11-02 19:26:48 +01:00
|
|
|
## @libraryclass Loads and boots a Linux kernel image
|
|
|
|
|
#
|
|
|
|
|
LoadLinuxLib|Include/Library/LoadLinuxLib.h
|
|
|
|
|
|
Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 19:50:40 +02:00
|
|
|
## @libraryclass Save and restore variables using a file
|
|
|
|
|
#
|
|
|
|
|
NvVarsFileLib|Include/Library/NvVarsFileLib.h
|
|
|
|
|
|
2018-04-28 23:22:11 +02:00
|
|
|
## @libraryclass Provides services to work with PCI capabilities in PCI
|
|
|
|
|
# config space.
|
|
|
|
|
PciCapLib|Include/Library/PciCapLib.h
|
|
|
|
|
|
OvmfPkg: introduce PciCapPciIoLib
Add a library class, and a UEFI_DRIVER lib instance, that are layered on
top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend
into PciCapLib, for config space access.
(Side note:
Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns
EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and
Count is not valid for the PCI configuration header of the PCI
controller", this patch doesn't directly document the EFI_UNSUPPORTED
error code, for ProtoDevTransferConfig() and its callers
ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers
to "unspecified error codes". The reason is that in edk2, the
PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return
EFI_INVALID_PARAMETER for the above situation.
Namely, PciIoConfigRead() and PciIoConfigWrite() first call
PciIoVerifyConfigAccess(), which indeed produces the standard
EFI_UNSUPPORTED error code, if the device's config space is exceeded.
However, if PciIoVerifyConfigAccess() passes, and we reach
RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then
RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge
doesn't support extended config space (see commit 014b472053ae3).
For all kinds of Limit violations in IO, MMIO, and config space,
RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not
EFI_UNSUPPORTED. That error code is then propagated up to, and out of,
PciIoConfigRead() and PciIoConfigWrite().
[1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
[2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-04-28 23:23:10 +02:00
|
|
|
## @libraryclass Layered on top of PciCapLib, allows clients to plug an
|
|
|
|
|
# EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config
|
|
|
|
|
# space access.
|
|
|
|
|
PciCapPciIoLib|Include/Library/PciCapPciIoLib.h
|
|
|
|
|
|
OvmfPkg: introduce PciCapPciSegmentLib
Add a library class, and a BASE lib instance, that are layered on top of
PciCapLib, and allow clients to plug a PciSegmentLib backend into
PciCapLib, for config space access.
(Side note:
The "MaxDomain" parameter is provided because, in practice, platforms
exist where a PCI Express device may show up on a root bridge such that
the root bridge doesn't support access to extended config space. Earlier
the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit
014b472053ae3. However, that solution does not apply to the PciSegmentLib
class, because:
(1) The config space accessor functions of the PciSegmentLib class, such
as PciSegmentReadBuffer(), have no way of informing the caller whether
access to extended config space actually succeeds.
(For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which
could in theory benefit from commit 014b472053ae3, the
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly
ignored, because there's no way for the lib instance to propagate it
to the PciSegmentLib caller. If the
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then
DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with
indeterminate value.)
(2) There is no *general* way for any firmware platform to provide, or
use, a PciSegmentLib instance in which access to extended config space
always succeeds.
In brief, on a platform where config space may be limited to 256 bytes,
access to extended config space through PciSegmentLib may invoke undefined
behavior; therefore PciCapPciSegmentLib must give platforms a way to
prevent such access.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-04-28 23:22:59 +02:00
|
|
|
## @libraryclass Layered on top of PciCapLib, allows clients to plug a
|
|
|
|
|
# PciSegmentLib backend into PciCapLib, for config space
|
|
|
|
|
# access.
|
|
|
|
|
PciCapPciSegmentLib|Include/Library/PciCapPciSegmentLib.h
|
|
|
|
|
|
2012-05-31 01:14:38 +02:00
|
|
|
## @libraryclass Access QEMU's firmware configuration interface
|
|
|
|
|
#
|
|
|
|
|
QemuFwCfgLib|Include/Library/QemuFwCfgLib.h
|
|
|
|
|
|
2017-02-22 01:59:41 +01:00
|
|
|
## @libraryclass S3 support for QEMU fw_cfg
|
|
|
|
|
#
|
|
|
|
|
QemuFwCfgS3Lib|Include/Library/QemuFwCfgS3Lib.h
|
|
|
|
|
|
2015-01-02 13:07:57 +01:00
|
|
|
## @libraryclass Rewrite the BootOrder NvVar based on QEMU's "bootorder"
|
|
|
|
|
# fw_cfg file.
|
|
|
|
|
#
|
|
|
|
|
QemuBootOrderLib|Include/Library/QemuBootOrderLib.h
|
|
|
|
|
|
Clean up DEC files:
1) Remove section header comment blocks that do not provide any information
2) Combine PCDs listed in multiple sections into a single section that supports multiple PCD types to reduce maintenance overhead
3) Remove ModuleTypeList comments from [Includes], [Protocols], [Ppis], and [Guids] sections that do not properly describe the module type restrictions.
4) Clean up formatting of GUID structure declarations
5) Remove ".common" from section names if they are not required.
6) Order sections consistently as [Defines], [Includes], [LibraryClasses], [Guid], [Ppis], [Protocols], [PcdsFeatureFlag], [PcdsFixedAtBuild], [PcdsPatchableInModule], [PcdsDynamic], and [PcdsDynamicEx]
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11633 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-09 19:50:40 +02:00
|
|
|
## @libraryclass Serialize (and deserialize) variables
|
|
|
|
|
#
|
|
|
|
|
SerializeVariablesLib|Include/Library/SerializeVariablesLib.h
|
|
|
|
|
|
2015-02-28 21:32:39 +01:00
|
|
|
## @libraryclass Invoke Xen hypercalls
|
|
|
|
|
#
|
|
|
|
|
XenHypercallLib|Include/Library/XenHypercallLib.h
|
|
|
|
|
|
2015-02-28 21:34:16 +01:00
|
|
|
## @libraryclass Manage XenBus device path and I/O handles
|
|
|
|
|
#
|
|
|
|
|
XenIoMmioLib|Include/Library/XenIoMmioLib.h
|
|
|
|
|
|
2010-02-24 00:58:38 +01:00
|
|
|
[Guids]
|
2016-03-22 10:16:44 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
|
|
|
|
|
gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
|
|
|
|
|
gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
|
|
|
|
|
gVirtioMmioTransportGuid = {0x837dca9e, 0xe874, 0x4d82, {0xb2, 0x9a, 0x23, 0xfe, 0x0e, 0x23, 0xd1, 0xe2}}
|
2018-06-13 09:29:33 +02:00
|
|
|
gQemuRamfbGuid = {0x557423a1, 0x63ab, 0x406c, {0xbe, 0x7e, 0x91, 0xcd, 0xbc, 0x08, 0xc4, 0x57}}
|
2016-03-22 10:16:44 +01:00
|
|
|
gXenBusRootDeviceGuid = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
|
2016-03-13 17:35:05 +01:00
|
|
|
gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2010-03-21 01:33:59 +01:00
|
|
|
[Protocols]
|
2016-03-22 10:16:44 +01:00
|
|
|
gVirtioDeviceProtocolGuid = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
|
|
|
|
|
gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}}
|
|
|
|
|
gXenIoProtocolGuid = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
|
2017-07-06 15:26:50 +02:00
|
|
|
gIoMmuAbsentProtocolGuid = {0xf8775d50, 0x8abd, 0x4adf, {0x92, 0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
|
2010-03-21 01:33:59 +01:00
|
|
|
|
2009-09-26 09:15:48 +02:00
|
|
|
[PcdsFixedAtBuild]
|
2014-01-21 20:39:13 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize|0x0|UINT32|1
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|0x0|UINT32|0x15
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize|0x0|UINT32|0x16
|
2009-09-26 09:15:48 +02:00
|
|
|
|
2012-07-26 18:36:39 +02:00
|
|
|
## This flag is used to control the destination port for PlatformDebugLibIoPort
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0x402|UINT16|4
|
|
|
|
|
|
2012-10-18 19:07:48 +02:00
|
|
|
## When VirtioScsiDxe is instantiated for a HBA, the numbers of targets and
|
|
|
|
|
# LUNs are retrieved from the host during virtio-scsi setup.
|
|
|
|
|
# MdeModulePkg/Bus/Scsi/ScsiBusDxe then scans all MaxTarget * MaxLun
|
|
|
|
|
# possible devices. This can take extremely long, for example with
|
|
|
|
|
# MaxTarget=255 and MaxLun=16383. The *inclusive* constants below limit
|
|
|
|
|
# MaxTarget and MaxLun, independently, should the host report higher values,
|
|
|
|
|
# so that scanning the number of devices given by their product is still
|
|
|
|
|
# acceptably fast.
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxTargetLimit|31|UINT16|6
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdVirtioScsiMaxLunLimit|7|UINT32|7
|
|
|
|
|
|
2013-11-12 19:34:11 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|0x0|UINT32|0x8
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize|0x0|UINT32|0x9
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize|0x0|UINT32|0xa
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize|0|UINT32|0xb
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase|0x0|UINT32|0xc
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase|0x0|UINT32|0xd
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase|0x0|UINT32|0xe
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress|0x0|UINT32|0xf
|
2014-01-21 20:38:34 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|0x0|UINT32|0x11
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize|0x0|UINT32|0x12
|
2014-01-21 20:38:43 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|0x0|UINT32|0x13
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize|0x0|UINT32|0x14
|
2014-03-04 09:03:23 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase|0x0|UINT32|0x18
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize|0x0|UINT32|0x19
|
OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
BaseExtractGuidedSectionLib.inf
The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.
BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.
LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is
gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF
When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
GetExtractGuidedSectionHandlerInfo()
PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS
Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:
SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
SecStartupPhase2()
FindAndReportEntryPoints()
FindPeiCoreImageBase()
DecompressMemFvs()
ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]
Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.
This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).
This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:
crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
vs.
crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.
Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.
Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between
PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
and
PcdOvmfSecPeiTempRamBase == 8256 KB.
- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).
- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
supported and we're not currently resuming.
The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):
sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32
PcdMaximumGuidedExtractHandler * (
sizeof(GUID) + // 16
sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8
sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8
)
OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.
Regarding the lifecycle of the new area:
(a) when and how it is initialized after first boot of the VM
The library linked into SecMain finds that the area lacks the signature.
It initializes the signature, plus the rest of the structure. This is
independent of S3 support.
Consumption of the area is also limited to SEC (but consumption does
depend on full-config-boot).
(b) how it is protected from memory allocations during DXE
It is not, in the general case; and we don't need to. Nothing else links
against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.
(c) how it is protected from the OS
When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().
When S3 is not supported, the range is not protected.
(d) how it is accessed on the S3 resume path
Examined by the library linked into SecMain. Registrations update the
table in-place (based on GUID matches).
(e) how it is accessed on the warm reset path
If S3 is enabled, then the OS won't damage the table (due to (c)), hence
see (d).
If S3 is unsupported, then the OS may or may not overwrite the
signature. (It likely will.) This is identical to the pre-patch status.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15433 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-05 23:26:09 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize|0x0|UINT32|0x1a
|
OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer
The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
memory, temporarily, than what PEIFV and DXEFV will ultimately need.
First, it uses an output buffer for decompression, second, the
decompression itself needs a scratch buffer (and this scratch buffer is
the highest area that SEC uses).
DecompressMemFvs() used to be called on normal boots only (ie. not on S3
resume), which is why the decompression output buffer and the scratch
buffer were allowed to scribble over RAM. However, we'll soon start to
worry during S3 resume that the runtime OS might tamper with the
pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3
resume too, from pristine flash. For this we'll need to know the end of
the scratch buffer in advance, so we can prepare a non-malicious OS for
it.
Calculate the end of the scratch buffer statically in the FDF files, and
assert in DecompressMemFvs() that the runtime decompression will match it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19036 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:20 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
|
2013-11-12 19:34:11 +01:00
|
|
|
|
2011-05-05 18:15:35 +02:00
|
|
|
[PcdsDynamic, PcdsDynamicEx]
|
2010-11-02 06:27:15 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
|
2013-11-12 19:35:23 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
|
2014-11-14 01:37:39 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId|0|UINT16|0x1b
|
2015-08-06 12:13:55 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE|BOOLEAN|0x21
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2016-05-09 22:39:44 +02:00
|
|
|
## The IO port aperture shared by all PCI root bridges.
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase|0x0|UINT64|0x22
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoSize|0x0|UINT64|0x23
|
|
|
|
|
|
2016-02-26 16:29:19 +01:00
|
|
|
## The 32-bit MMIO aperture shared by all PCI root bridges.
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Base|0x0|UINT64|0x24
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio32Size|0x0|UINT64|0x25
|
|
|
|
|
|
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
|
|
|
## The 64-bit MMIO aperture shared by all PCI root bridges.
|
|
|
|
|
#
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Base|0x0|UINT64|0x26
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size|0x0|UINT64|0x27
|
|
|
|
|
|
2017-07-04 13:52:34 +02:00
|
|
|
## The following setting controls how many megabytes we configure as TSEG on
|
2017-07-04 15:09:51 +02:00
|
|
|
# Q35, for SMRAM purposes. Permitted defaults are: 1, 2, 8. Other defaults
|
|
|
|
|
# cause undefined behavior. During boot, the PCD is updated by PlatformPei
|
|
|
|
|
# to reflect the extended TSEG size, if one is advertized by QEMU.
|
2017-07-04 13:52:34 +02:00
|
|
|
#
|
2017-07-04 15:09:51 +02:00
|
|
|
# This PCD is only accessed if PcdSmmSmramRequire is TRUE (see below).
|
2017-07-04 13:52:34 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes|8|UINT16|0x20
|
|
|
|
|
|
2012-03-09 18:38:21 +01:00
|
|
|
[PcdsFeatureFlag]
|
2015-01-02 13:08:02 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderPciTranslation|TRUE|BOOLEAN|0x1c
|
2015-01-02 13:08:19 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQemuBootOrderMmioTranslation|FALSE|BOOLEAN|0x1d
|
2015-11-30 19:41:10 +01:00
|
|
|
|
|
|
|
|
## This feature flag enables SMM/SMRAM support. Note that it also requires
|
|
|
|
|
# such support from the underlying QEMU instance; if that support is not
|
|
|
|
|
# present, the firmware will reject continuing after a certain point.
|
|
|
|
|
#
|
|
|
|
|
# The flag also acts as a general "security switch"; when TRUE, many
|
|
|
|
|
# components will change behavior, with the goal of preventing a malicious
|
|
|
|
|
# runtime OS from tampering with firmware structures (special memory ranges
|
|
|
|
|
# used by OVMF, the varstore pflash chip, LockBox etc).
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire|FALSE|BOOLEAN|0x1e
|
