2009-05-27 23:10:18 +02:00
|
|
|
/** @file
|
|
|
|
Build FV related hobs for platform.
|
|
|
|
|
2014-01-21 20:39:13 +01:00
|
|
|
Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.<BR>
|
2019-04-04 01:06:33 +02:00
|
|
|
SPDX-License-Identifier: BSD-2-Clause-Patent
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
**/
|
|
|
|
|
|
|
|
#include "PiPei.h"
|
2014-03-04 09:02:59 +01:00
|
|
|
#include "Platform.h"
|
2009-05-27 23:10:18 +02:00
|
|
|
#include <Library/DebugLib.h>
|
|
|
|
#include <Library/HobLib.h>
|
|
|
|
#include <Library/PeiServicesLib.h>
|
|
|
|
#include <Library/PcdLib.h>
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
2014-01-21 20:39:13 +01:00
|
|
|
Publish PEI & DXE (Decompressed) Memory based FVs to let PEI
|
|
|
|
and DXE know about them.
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
@retval EFI_SUCCESS Platform PEI FVs were initialized successfully.
|
|
|
|
|
|
|
|
**/
|
|
|
|
EFI_STATUS
|
|
|
|
PeiFvInitialization (
|
|
|
|
VOID
|
|
|
|
)
|
|
|
|
{
|
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
|
|
|
BOOLEAN SecureS3Needed;
|
|
|
|
|
2014-01-21 20:39:13 +01:00
|
|
|
DEBUG ((EFI_D_INFO, "Platform PEI Firmware Volume Initialization\n"));
|
2009-05-27 23:10:18 +02:00
|
|
|
|
2014-01-21 20:39:13 +01:00
|
|
|
//
|
|
|
|
// Create a memory allocation HOB for the PEI FV.
|
|
|
|
//
|
2014-03-04 09:02:59 +01:00
|
|
|
// Allocate as ACPI NVS is S3 is supported
|
2014-01-21 20:39:13 +01:00
|
|
|
//
|
|
|
|
BuildMemoryAllocationHob (
|
|
|
|
PcdGet32 (PcdOvmfPeiMemFvBase),
|
|
|
|
PcdGet32 (PcdOvmfPeiMemFvSize),
|
2014-03-04 09:02:59 +01:00
|
|
|
mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
|
2009-05-27 23:10:18 +02:00
|
|
|
);
|
|
|
|
|
2014-01-21 20:39:13 +01:00
|
|
|
//
|
|
|
|
// Let DXE know about the DXE FV
|
|
|
|
//
|
|
|
|
BuildFvHob (PcdGet32 (PcdOvmfDxeMemFvBase), PcdGet32 (PcdOvmfDxeMemFvSize));
|
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
|
|
|
SecureS3Needed = mS3Supported && FeaturePcdGet (PcdSmmSmramRequire);
|
|
|
|
|
2010-01-04 17:17:59 +01:00
|
|
|
//
|
2014-01-21 20:39:13 +01:00
|
|
|
// Create a memory allocation HOB for the DXE FV.
|
2010-01-04 17:17:59 +01: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
|
|
|
// If "secure" S3 is needed, then SEC will decompress both PEI and DXE
|
|
|
|
// firmware volumes at S3 resume too, hence we need to keep away the OS from
|
|
|
|
// DXEFV as well. Otherwise we only need to keep away DXE itself from the
|
|
|
|
// DXEFV area.
|
|
|
|
//
|
2010-01-04 17:17:59 +01:00
|
|
|
BuildMemoryAllocationHob (
|
2014-01-21 20:39:13 +01:00
|
|
|
PcdGet32 (PcdOvmfDxeMemFvBase),
|
|
|
|
PcdGet32 (PcdOvmfDxeMemFvSize),
|
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
|
|
|
SecureS3Needed ? EfiACPIMemoryNVS : EfiBootServicesData
|
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
|
|
|
//
|
|
|
|
// Additionally, said decompression will use temporary memory above the end
|
|
|
|
// of DXEFV, so let's keep away the OS from there too.
|
|
|
|
//
|
|
|
|
if (SecureS3Needed) {
|
|
|
|
UINT32 DxeMemFvEnd;
|
|
|
|
|
|
|
|
DxeMemFvEnd = PcdGet32 (PcdOvmfDxeMemFvBase) +
|
|
|
|
PcdGet32 (PcdOvmfDxeMemFvSize);
|
|
|
|
BuildMemoryAllocationHob (
|
|
|
|
DxeMemFvEnd,
|
|
|
|
PcdGet32 (PcdOvmfDecompressionScratchEnd) - DxeMemFvEnd,
|
|
|
|
EfiACPIMemoryNVS
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2014-01-21 20:39:13 +01:00
|
|
|
//
|
|
|
|
// Let PEI know about the DXE FV so it can find the DXE Core
|
|
|
|
//
|
|
|
|
PeiServicesInstallFvInfoPpi (
|
|
|
|
NULL,
|
|
|
|
(VOID *)(UINTN) PcdGet32 (PcdOvmfDxeMemFvBase),
|
|
|
|
PcdGet32 (PcdOvmfDxeMemFvSize),
|
|
|
|
NULL,
|
|
|
|
NULL
|
|
|
|
);
|
|
|
|
|
2009-05-27 23:10:18 +02:00
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
|
|
|
|