audk/OvmfPkg/AmdSevDxe/AmdSevDxe.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

366 lines
11 KiB
C
Raw Normal View History

/** @file
AMD Sev Dxe driver. This driver is dispatched early in DXE, due to being list
in APRIORI. It clears C-bit from MMIO and NonExistent Memory space when SEV
is enabled.
OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG range BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:48:18 +01:00
Copyright (c) 2017 - 2020, AMD Inc. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG range BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:48:18 +01:00
#include <IndustryStandard/Q35MchIch9.h>
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
#include <Library/BaseLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/DebugLib.h>
#include <Library/DxeServicesTableLib.h>
#include <Library/MemEncryptSevLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Guid/ConfidentialComputingSevSnpBlob.h>
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
#include <Library/PcdLib.h>
#include <Pi/PrePiDxeCis.h>
#include <Protocol/SevMemoryAcceptance.h>
#include <Protocol/MemoryAccept.h>
#include <Uefi/UefiSpec.h>
// Present, initialized, tested bits defined in MdeModulePkg/Core/Dxe/DxeMain.h
#define EFI_MEMORY_INTERNAL_MASK 0x0700000000000000ULL
STATIC
EFI_STATUS
AllocateConfidentialComputingBlob (
OUT CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION **CcBlobPtr
)
{
EFI_STATUS Status;
CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION *CcBlob;
Status = gBS->AllocatePool (
EfiACPIReclaimMemory,
sizeof (CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION),
(VOID **)&CcBlob
);
if (EFI_ERROR (Status)) {
return Status;
}
CcBlob->Header = SIGNATURE_32 ('A', 'M', 'D', 'E');
CcBlob->Version = 1;
CcBlob->Reserved = 0;
CcBlob->SecretsPhysicalAddress = (UINT64)(UINTN)FixedPcdGet32 (PcdOvmfSnpSecretsBase);
CcBlob->SecretsSize = FixedPcdGet32 (PcdOvmfSnpSecretsSize);
CcBlob->Reserved1 = 0;
CcBlob->CpuidPhysicalAddress = (UINT64)(UINTN)FixedPcdGet32 (PcdOvmfCpuidBase);
CcBlob->CpuidLSize = FixedPcdGet32 (PcdOvmfCpuidSize);
CcBlob->Reserved2 = 0;
*CcBlobPtr = CcBlob;
return EFI_SUCCESS;
}
STATIC EFI_HANDLE mAmdSevDxeHandle = NULL;
STATIC BOOLEAN mAcceptAllMemoryAtEBS = TRUE;
STATIC EFI_EVENT mAcceptAllMemoryEvent = NULL;
STATIC
EFI_STATUS
EFIAPI
AmdSevMemoryAccept (
IN EDKII_MEMORY_ACCEPT_PROTOCOL *This,
IN EFI_PHYSICAL_ADDRESS StartAddress,
IN UINTN Size
)
{
//
// The StartAddress must be page-aligned, and the Size must be a positive
// multiple of SIZE_4KB. Use an assert instead of returning an erros since
// this is an EDK2-internal protocol.
//
ASSERT (IS_ALIGNED (StartAddress, SIZE_4KB));
ASSERT (IS_ALIGNED (Size, SIZE_4KB));
ASSERT (Size != 0);
MemEncryptSevSnpPreValidateSystemRam (
StartAddress,
EFI_SIZE_TO_PAGES (Size)
);
return EFI_SUCCESS;
}
STATIC
EFI_STATUS
AcceptAllMemory (
VOID
)
{
EFI_GCD_MEMORY_SPACE_DESCRIPTOR *AllDescMap;
UINTN NumEntries;
UINTN Index;
EFI_STATUS Status;
DEBUG ((DEBUG_INFO, "Accepting all memory\n"));
/*
* Get a copy of the memory space map to iterate over while
* changing the map.
*/
Status = gDS->GetMemorySpaceMap (&NumEntries, &AllDescMap);
if (EFI_ERROR (Status)) {
return Status;
}
for (Index = 0; Index < NumEntries; Index++) {
CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Desc;
Desc = &AllDescMap[Index];
if (Desc->GcdMemoryType != EFI_GCD_MEMORY_TYPE_UNACCEPTED) {
continue;
}
Status = AmdSevMemoryAccept (
NULL,
Desc->BaseAddress,
Desc->Length
);
if (EFI_ERROR (Status)) {
break;
}
Status = gDS->RemoveMemorySpace (Desc->BaseAddress, Desc->Length);
if (EFI_ERROR (Status)) {
break;
}
Status = gDS->AddMemorySpace (
EfiGcdMemoryTypeSystemMemory,
Desc->BaseAddress,
Desc->Length,
// Allocable system memory resource capabilities as masked
// in MdeModulePkg/Core/Dxe/Mem/Page.c:PromoteMemoryResource
Desc->Capabilities & ~(EFI_MEMORY_INTERNAL_MASK | EFI_MEMORY_RUNTIME)
);
if (EFI_ERROR (Status)) {
break;
}
}
gBS->FreePool (AllDescMap);
gBS->CloseEvent (mAcceptAllMemoryEvent);
return Status;
}
VOID
EFIAPI
ResolveUnacceptedMemory (
IN EFI_EVENT Event,
IN VOID *Context
)
{
EFI_STATUS Status;
if (!mAcceptAllMemoryAtEBS) {
return;
}
Status = AcceptAllMemory ();
ASSERT_EFI_ERROR (Status);
}
STATIC
EFI_STATUS
EFIAPI
AllowUnacceptedMemory (
IN OVMF_SEV_MEMORY_ACCEPTANCE_PROTOCOL *This
)
{
mAcceptAllMemoryAtEBS = FALSE;
return EFI_SUCCESS;
}
STATIC
OVMF_SEV_MEMORY_ACCEPTANCE_PROTOCOL
mMemoryAcceptanceProtocol = { AllowUnacceptedMemory };
STATIC EDKII_MEMORY_ACCEPT_PROTOCOL mMemoryAcceptProtocol = {
AmdSevMemoryAccept
};
EFI_STATUS
EFIAPI
AmdSevDxeEntryPoint (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
EFI_STATUS Status;
EFI_GCD_MEMORY_SPACE_DESCRIPTOR *AllDescMap;
UINTN NumEntries;
UINTN Index;
CONFIDENTIAL_COMPUTING_SNP_BLOB_LOCATION *SnpBootDxeTable;
//
// Do nothing when SEV is not enabled
//
if (!MemEncryptSevIsEnabled ()) {
return EFI_UNSUPPORTED;
}
//
// Iterate through the GCD map and clear the C-bit from MMIO and NonExistent
// memory space. The NonExistent memory space will be used for mapping the
// MMIO space added later (eg PciRootBridge). By clearing both known MMIO and
// NonExistent memory space can gurantee that current and furture MMIO adds
// will have C-bit cleared.
//
Status = gDS->GetMemorySpaceMap (&NumEntries, &AllDescMap);
if (!EFI_ERROR (Status)) {
for (Index = 0; Index < NumEntries; Index++) {
CONST EFI_GCD_MEMORY_SPACE_DESCRIPTOR *Desc;
Desc = &AllDescMap[Index];
if ((Desc->GcdMemoryType == EfiGcdMemoryTypeMemoryMappedIo) ||
(Desc->GcdMemoryType == EfiGcdMemoryTypeNonExistent))
{
Status = MemEncryptSevClearMmioPageEncMask (
0,
Desc->BaseAddress,
EFI_SIZE_TO_PAGES (Desc->Length)
);
ASSERT_EFI_ERROR (Status);
}
}
FreePool (AllDescMap);
}
OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG range BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:48:18 +01:00
//
// If PCI Express is enabled, the MMCONFIG area has been reserved, rather
// than marked as MMIO, and so the C-bit won't be cleared by the above walk
// through the GCD map. Check for the MMCONFIG area and clear the C-bit for
// the range.
//
if (PcdGet16 (PcdOvmfHostBridgePciDevId) == INTEL_Q35_MCH_DEVICE_ID) {
Status = MemEncryptSevClearMmioPageEncMask (
OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG range BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:48:18 +01:00
0,
FixedPcdGet64 (PcdPciExpressBaseAddress),
EFI_SIZE_TO_PAGES (SIZE_256MB)
OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG range BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
2021-01-07 19:48:18 +01:00
);
ASSERT_EFI_ERROR (Status);
}
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
//
// When SMM is enabled, clear the C-bit from SMM Saved State Area
//
// NOTES: The SavedStateArea address cleared here is before SMBASE
// relocation. Currently, we do not clear the SavedStateArea address after
// SMBASE is relocated due to the following reasons:
//
// 1) Guest BIOS never access the relocated SavedStateArea.
//
// 2) The C-bit works on page-aligned address, but the SavedStateArea
// address is not a page-aligned. Theoretically, we could roundup the address
// and clear the C-bit of aligned address but looking carefully we found
// that some portion of the page contains code -- which will causes a bigger
// issues for SEV guest. When SEV is enabled, all the code must be encrypted
// otherwise hardware will cause trap.
//
// We restore the C-bit for this SMM Saved State Area after SMBASE relocation
// is completed (See OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c).
//
if (FeaturePcdGet (PcdSmmSmramRequire)) {
UINTN MapPagesBase;
UINTN MapPagesCount;
Status = MemEncryptSevLocateInitialSmramSaveStateMapPages (
&MapPagesBase,
&MapPagesCount
);
ASSERT_EFI_ERROR (Status);
//
// Although these pages were set aside (i.e., allocated) by PlatformPei, we
// could be after a warm reboot from the OS. Don't leak any stale OS data
// to the hypervisor.
//
ZeroMem ((VOID *)MapPagesBase, EFI_PAGES_TO_SIZE (MapPagesCount));
Status = MemEncryptSevClearPageEncMask (
0, // Cr3BaseAddress -- use current CR3
MapPagesBase, // BaseAddress
MapPagesCount // NumPages
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
);
if (EFI_ERROR (Status)) {
DEBUG ((
DEBUG_ERROR,
"%a: MemEncryptSevClearPageEncMask(): %r\n",
__func__,
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-01 22:05:55 +01:00
Status
));
ASSERT (FALSE);
CpuDeadLoop ();
}
}
Status = AllocateConfidentialComputingBlob (&SnpBootDxeTable);
if (EFI_ERROR (Status)) {
DEBUG ((
DEBUG_ERROR,
"%a: AllocateConfidentialComputingBlob(): %r\n",
__func__,
Status
));
ASSERT (FALSE);
CpuDeadLoop ();
}
if (MemEncryptSevSnpIsEnabled ()) {
//
// Memory acceptance began being required in SEV-SNP, so install the
// memory accept protocol implementation for a SEV-SNP active guest.
//
Status = gBS->InstallMultipleProtocolInterfaces (
&mAmdSevDxeHandle,
&gEdkiiMemoryAcceptProtocolGuid,
&mMemoryAcceptProtocol,
&gOvmfSevMemoryAcceptanceProtocolGuid,
&mMemoryAcceptanceProtocol,
NULL
);
ASSERT_EFI_ERROR (Status);
// SEV-SNP support does not automatically imply unaccepted memory support,
// so make ExitBootServices accept all unaccepted memory if support is
// not communicated.
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
ResolveUnacceptedMemory,
NULL,
&gEfiEventBeforeExitBootServicesGuid,
&mAcceptAllMemoryEvent
);
if (EFI_ERROR (Status)) {
DEBUG ((DEBUG_ERROR, "AllowUnacceptedMemory event creation for EventBeforeExitBootServices failed.\n"));
}
//
// If its SEV-SNP active guest then install the CONFIDENTIAL_COMPUTING_SEV_SNP_BLOB.
// It contains the location for both the Secrets and CPUID page.
//
return gBS->InstallConfigurationTable (
&gConfidentialComputingSevSnpBlobGuid,
SnpBootDxeTable
);
}
return EFI_SUCCESS;
}