2010-02-24 00:58:38 +01:00
|
|
|
## @file
|
2009-05-27 23:10:18 +02:00
|
|
|
# Platform PEI driver
|
|
|
|
|
#
|
|
|
|
|
# This module provides platform specific function to detect boot mode.
|
2014-03-04 09:02:16 +01:00
|
|
|
# Copyright (c) 2006 - 2014, 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
|
|
|
|
|
#
|
|
|
|
|
# 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]
|
|
|
|
|
INF_VERSION = 0x00010005
|
|
|
|
|
BASE_NAME = PlatformPei
|
|
|
|
|
FILE_GUID = 222c386d-5abc-4fb4-b124-fbb82488acf4
|
|
|
|
|
MODULE_TYPE = PEIM
|
|
|
|
|
VERSION_STRING = 1.0
|
|
|
|
|
ENTRY_POINT = InitializePlatform
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# The following information is for reference only and not required by the build tools.
|
|
|
|
|
#
|
|
|
|
|
# VALID_ARCHITECTURES = IA32 X64 IPF EBC
|
|
|
|
|
#
|
|
|
|
|
|
2010-01-30 01:10:44 +01:00
|
|
|
[Sources]
|
2009-05-27 23:10:18 +02:00
|
|
|
Cmos.c
|
|
|
|
|
Fv.c
|
|
|
|
|
MemDetect.c
|
|
|
|
|
Platform.c
|
2011-08-05 17:43:05 +02:00
|
|
|
Xen.c
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
[Packages]
|
2014-03-04 09:02:16 +01:00
|
|
|
IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
|
2009-05-27 23:10:18 +02:00
|
|
|
MdePkg/MdePkg.dec
|
|
|
|
|
MdeModulePkg/MdeModulePkg.dec
|
2011-10-28 08:04:01 +02:00
|
|
|
UefiCpuPkg/UefiCpuPkg.dec
|
2009-05-27 23:10:18 +02:00
|
|
|
OvmfPkg/OvmfPkg.dec
|
|
|
|
|
|
|
|
|
|
[Guids]
|
|
|
|
|
gEfiMemoryTypeInformationGuid
|
2011-08-05 17:43:05 +02:00
|
|
|
gEfiXenInfoGuid
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
|
[LibraryClasses]
|
2015-12-01 00:36:31 +01:00
|
|
|
BaseLib
|
2009-05-27 23:10:18 +02:00
|
|
|
DebugLib
|
|
|
|
|
HobLib
|
|
|
|
|
IoLib
|
2011-01-13 06:46:24 +01:00
|
|
|
PciLib
|
2009-05-27 23:10:18 +02:00
|
|
|
PeiResourcePublicationLib
|
2011-03-22 02:55:08 +01:00
|
|
|
PeiServicesLib
|
2009-05-27 23:10:18 +02:00
|
|
|
PeiServicesTablePointerLib
|
|
|
|
|
PeimEntryPoint
|
2014-03-04 09:01:58 +01:00
|
|
|
QemuFwCfgLib
|
2011-10-28 08:04:01 +02:00
|
|
|
MtrrLib
|
2012-07-31 20:17:37 +02:00
|
|
|
PcdLib
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2010-01-30 01:10:44 +01:00
|
|
|
[Pcd]
|
2014-01-21 20:39:13 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
|
OvmfPkg: enable PIIX4 IO space in the PEI phase
I. There are at least three locations in OvmfPkg that manipulate the PMBA
and related PIIX4 registers.
1. MiscInitialization() [OvmfPkg/PlatformPei/Platform.c]
module type: PEIM -- Pre-EFI Initialization Module
(a) currently sets the PMBA only: 00.01.3 / 0x40 bits [15:6]
2. AcpiTimerLibConstructor() [OvmfPkg/Library/AcpiTimerLib/AcpiTimerLib.c]
module type: BASE -- probably callable anywhere after PEI
(a) sets the PMBA if needed: 00.01.3 / 0x40 bits [15:6]
(b) sets PCICMD/IOSE if needed: 00.01.3 / 0x04 bit 0
(c) sets PMREGMISC/PMIOSE: 00.01.3 / 0x80 bit 0
3. AcpiInitialization() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
module type: DXE_DRIVER -- Driver eXecution Environment
(a) sets SCI_EN, which depends on correct PMBA setting from earlier
(
The relative order of #1 and #3 is dictated minimally by their module
types. Said relative order can be verified with the boot log:
27 Loading PEIM at 0x00000822320 EntryPoint=0x00000822580
PlatformPei.efi
28 Platform PEIM Loaded
1259 PlatformBdsInit
1270 PlatformBdsPolicyBehavior
Line 28 is printed by InitializePlatform()
[OvmfPkg/PlatformPei/Platform.c] which is the entry point of that
module. The other two lines are printed by the corresponding functions
in "OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".
)
Currently #2 (AcpiTimerLibConstructor()) is called in a random spot
(whenever it gets loaded from the firmware image) and masks the
insufficient setup in #1. We shouldn't depend on that, PEI should finish
with IO space being fully accessibe. In addition, PEI should program the
same PMBA value as AcpiTimerLib.
II. The PEI change notwithstanding, AcpiTimerLib should stay defensive and
ensure proper PM configuration for itself (either by confirming or by
doing).
III. Considering a possible cleanup/unification of #2 and #3: timer
functions relying on AcpiTimerLibConstructor(),
- MicroSecondDelay()
- NanoSecondDelay()
- GetPerformanceCounter()
- GetPerformanceCounterProperties()
- GetTimeInNanoSecond()
may be called before #3 is reached (in Boot Device Selection phase), so we
should not move the initialization from #2 to #3. (Again, AcpiTimerLib
should contain its own setup.)
We should also not move #3 to an earlier phase -- SCI_EN is premature
unless we're about to boot real soon ("enable generation of SCI upon
assertion of PWRBTN_STS, LID_STS, THRM_STS, or GPI_STS bits").
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13722 6f19259b-4bc3-4df7-8a09-765794883524
2012-09-12 09:19:16 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
|
2014-03-04 09:02:16 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdS3AcpiReservedMemoryBase
|
2014-03-04 09:02:45 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
|
2014-03-04 09:02:52 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
|
2014-03-04 09:03:23 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageBase
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfLockBoxStorageSize
|
OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
BaseExtractGuidedSectionLib.inf
The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.
BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.
LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is
gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF
When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
GetExtractGuidedSectionHandlerInfo()
PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS
Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:
SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
SecStartupPhase2()
FindAndReportEntryPoints()
FindPeiCoreImageBase()
DecompressMemFvs()
ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]
Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.
This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).
This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:
crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
vs.
crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.
Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.
Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between
PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
and
PcdOvmfSecPeiTempRamBase == 8256 KB.
- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).
- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
supported and we're not currently resuming.
The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):
sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32
PcdMaximumGuidedExtractHandler * (
sizeof(GUID) + // 16
sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8
sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8
)
OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.
Regarding the lifecycle of the new area:
(a) when and how it is initialized after first boot of the VM
The library linked into SecMain finds that the area lacks the signature.
It initializes the signature, plus the rest of the structure. This is
independent of S3 support.
Consumption of the area is also limited to SEC (but consumption does
depend on full-config-boot).
(b) how it is protected from memory allocations during DXE
It is not, in the general case; and we don't need to. Nothing else links
against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.
(c) how it is protected from the OS
When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().
When S3 is not supported, the range is not protected.
(d) how it is accessed on the S3 resume path
Examined by the library linked into SecMain. Registrations update the
table in-place (based on GUID matches).
(e) how it is accessed on the warm reset path
If S3 is enabled, then the OS won't damage the table (due to (c)), hence
see (d).
If S3 is unsupported, then the OS may or may not overwrite the
signature. (It likely will.) This is identical to the pre-patch status.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15433 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-05 23:26:09 +02:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
|
2014-11-14 01:37:39 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
|
OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set
If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.
One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
suspend-resume cycles; at S3 resume SEC just reuses the originally
decompressed PEIFV.
However, if we don't trust the OS, then SEC must decompress PEIFV from the
pristine flash every time, lest we execute OS-injected code or work with
OS-injected data.
Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
the decompression brings DXEFV with itself, plus it uses a temporary
output buffer and a scratch buffer too, which even reach above the end of
the finally installed DXEFV. For this reason we must keep away a
non-malicious OS from DXEFV too, plus the memory up to
PcdOvmfDecomprScratchEnd.
The delay introduced by the LZMA decompression on S3 resume is negligible.
If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
(from the DEC file), and then this patch has no effect (not counting some
changed debug messages).
If QEMU doesn't support S3 (or the user disabled it on the QEMU command
line), then this patch has no effect also.
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@19037 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:24 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
|
OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set
PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:
- PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
so that it ends with the RAM below 4GB,
- QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
created for the RAM below 4GB; plus MTRR attributes are set
(independently of S3 vs. normal boot)
- MemMapInitialization(): an MMIO resource descriptor HOB is created for
PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
2GB).
The first two of these is adjusted for the configured TSEG size, if
PcdSmmSmramRequire is set:
- In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.
- In QemuInitializeRam(), we must keep the DXE out of TSEG.
One idea would be to simply trim the [1MB .. LowerMemorySize] memory
resource descriptor HOB, leaving a hole for TSEG in the memory space
map.
The SMM IPL will however want to massage the caching attributes of the
SMRAM range that it loads the SMM core into, with
gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
instead of trimming this range, split the TSEG area off, and report it
as a cacheable reserved memory resource.
Finally, since reserved memory can be allocated too, pre-allocate TSEG
in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
this step alone does not suffice without the resource descriptor HOB
trickery: if we omit that, then the DXE IPL PEIM fails to load and start
the DXE core.)
- In MemMapInitialization(), the start of the PCI MMIO range is not
affected.
We choose the largest option (8MB) for the default TSEG size. Michael
Kinney pointed out that the SMBASE relocation in PiSmmCpuDxeSmm consumes
SMRAM proportionally to the number of CPUs. From the three options
available, he reported that 8MB was both necessary and sufficient for the
SMBASE relocation to succeed with 255 CPUs:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3137
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020/focus=3177
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: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19039 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:33 +01:00
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
|
2014-03-04 09:02:16 +01:00
|
|
|
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
|
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
|
|
|
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
|
2009-05-27 23:10:18 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
|
2009-09-07 22:18:17 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
|
2013-12-08 02:36:25 +01:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
|
2015-06-26 18:09:39 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
|
2015-09-15 10:35:14 +02:00
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
|
|
|
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable
|
2012-07-31 20:17:37 +02:00
|
|
|
gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
|
2009-05-27 23:10:18 +02:00
|
|
|
|
OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set
If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
not trusted and we should defend against it tampering with the firmware's
data.
One such datum is the PEI firmware volume (PEIFV). Normally PEIFV is
decompressed on the first boot by SEC, then the OS preserves it across S3
suspend-resume cycles; at S3 resume SEC just reuses the originally
decompressed PEIFV.
However, if we don't trust the OS, then SEC must decompress PEIFV from the
pristine flash every time, lest we execute OS-injected code or work with
OS-injected data.
Due to how FVMAIN_COMPACT is organized, we can't decompress just PEIFV;
the decompression brings DXEFV with itself, plus it uses a temporary
output buffer and a scratch buffer too, which even reach above the end of
the finally installed DXEFV. For this reason we must keep away a
non-malicious OS from DXEFV too, plus the memory up to
PcdOvmfDecomprScratchEnd.
The delay introduced by the LZMA decompression on S3 resume is negligible.
If -D SMM_REQUIRE is not specified, then PcdSmmSmramRequire remains FALSE
(from the DEC file), and then this patch has no effect (not counting some
changed debug messages).
If QEMU doesn't support S3 (or the user disabled it on the QEMU command
line), then this patch has no effect also.
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@19037 6f19259b-4bc3-4df7-8a09-765794883524
2015-11-30 19:41:24 +01:00
|
|
|
[FeaturePcd]
|
|
|
|
|
gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
|
|
|
|
|
|
2011-03-22 02:55:08 +01:00
|
|
|
[Ppis]
|
|
|
|
|
gEfiPeiMasterBootModePpiGuid
|
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
[Depex]
|
|
|
|
|
TRUE
|
|
|
|
|
|
