Tianocore/edk2.git/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf, branch master

OvmfPkg/BaseMemEncryptSevLib: Fetch Sev data from the work area

2026-08-27T06:37:01+00:00

The first call to MemEncryptSevGetEncryptionMask() in the Dxe phase will look for the encryption mask for the page table entry by reading the PcdPteMemoryEncryptionAddressOrMask (dynamic PCD) token. The value is then cached for subsequent accesses. But if the first call has interrupts disabled, as is the case in the MmioExit function in the #VC handler then the PcdGet64() will re-enable interrupts unexpectedly. A hypervisor may then inject interrupts into the guest whilst the guest is not expected to be interrupted. This leads to the ovmf image hanging when handling too many nested #VC exceptions. This patch avoids using the PcdPteMemoryEncryptionAddressOrMask token in the MemEncryptSevGetEncryptionMask() function as it cannot be called safely from a context where interrupts are disabled. Instead, we fetch the values from the SEC_SEV_ES_WORK_AREA in the Dxe phase. The work area is already used in the Pei phase, and is available in the Dxe phase as it is marked as either EfiBootServicesData or EfiACPIMemoryNVS. However, the work area will be inaccessible when SetVirtualAddressMap() is called, so we only read the work area in the Dxe phase through a constructor function. Signed-off-by: John Berg Signed-off-by: Ivan Orlov

OvmfPkg/BaseMemEncryptSevLib: Make GetSevEsWorkArea() Pei/Dxe shared

2026-08-27T06:37:01+00:00

This is a small refactor to the BaseMemEncryptSevLib in the OvmfPkg which moves the function used in the Pei phase for accessing the SEC_SEV_ES_WORK_AREA, into the common Pei and Dxe code. The Dxe phase will consume the work area in a subsequent patch. Signed-off-by: John Berg

OvmfPkg: Remove OVMF IA32

2025-09-09T18:49:32+00:00

This commit removes OVMF IA32 from edk2 per RFC https://edk2.groups.io/g/devel/topic/rfc_remove_ovmf_ia32_and/114152215. OVMF IA32 is a 32 bit only platform that no longer represents the vast majority of physical platforms. The RFC details more reasoning in much more depth. OVMF IA32 will be kept in a branch off the edk2-stable202508 tag for any long term consumers; it will receive build break updates only (e.g. if an upstream submodule changes location). Signed-off-by: Oliver Smith-Denny

OvmfPkg/BaseMemEncryptSevLib: Use AmdSvsmSnpPvalidate() to validate pages

2024-04-17T20:04:41+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 The PVALIDATE instruction is used to change the SNP validation of a page, but that can only be done when running at VMPL0. To prepare for running at a less priviledged VMPL, use the AmdSvsmLib library API to perform the PVALIDATE. The AmdSvsmLib library will perform the proper operation on behalf of the caller. Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Laszlo Ersek Cc: Michael Roth Cc: Min Xu Signed-off-by: Tom Lendacky Acked-by: Gerd Hoffmann

OvmfPkg/UefiCpuPkg/UefiPayloadPkg: Rename VmgExitLib to CcExitLib

2022-11-14T04:55:34+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4123 VmgExitLib once was designed to provide interfaces to support #VC handler and issue VMGEXIT instruction. After TDVF (enable TDX feature in OVMF) is introduced, this library is updated to support #VE as well. Now the name of VmgExitLib cannot reflect what the lib does. This patch renames VmgExitLib to CcExitLib (Cc means Confidential Computing). This is a simple renaming and there is no logic changes. After renaming all the VmgExitLib related codes are updated with CcExitLib. These changes are in OvmfPkg/UefiCpuPkg/UefiPayloadPkg. Cc: Guo Dong Cc: Sean Rhodes Cc: James Lu Cc: Gua Guo Cc: Eric Dong Cc: Ray Ni Cc: Brijesh Singh Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: James Bottomley Cc: Jiewen Yao Cc: Tom Lendacky Reviewed-by: James Lu Reviewed-by: Gua Guo Reviewed-by: Jiewen Yao Reviewed-by: Ray Ni Signed-off-by: Min Xu

OvmfPkg/BaseMemEncryptLib: use the SEV_STATUS MSR value from workarea

2022-02-28T02:46:08+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3582 Improve the MemEncryptSev{Es,Snp}IsEnabled() to use the SEV_STATUS MSR value saved in the workarea. Since workarea is valid until the PEI phase, so, for the Dxe phase use the PcdConfidentialComputingGuestAttr to determine which SEV technology is enabled. Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Acked-by: Gerd Hoffmann Signed-off-by: Brijesh Singh Acked-by: Jiewen Yao

OvmfPkg/MemEncryptSevLib: add support to validate system RAM

2021-12-09T06:28:10+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Many of the integrity guarantees of SEV-SNP are enforced through the Reverse Map Table (RMP). Each RMP entry contains the GPA at which a particular page of DRAM should be mapped. The guest can request the hypervisor to add pages in the RMP table via the Page State Change VMGEXIT defined in the GHCB specification section 2.5.1 and 4.1.6. Inside each RMP entry is a Validated flag; this flag is automatically cleared to 0 by the CPU hardware when a new RMP entry is created for a guest. Each VM page can be either validated or invalidated, as indicated by the Validated flag in the RMP entry. Memory access to a private page that is not validated generates a #VC. A VM can use the PVALIDATE instruction to validate the private page before using it. During the guest creation, the boot ROM memory is pre-validated by the AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called during the SEC and PEI phase to validate the detected system RAM. One of the fields in the Page State Change NAE is the RMP page size. The page size input parameter indicates that either a 4KB or 2MB page should be used while adding the RMP entry. During the validation, when possible, the MemEncryptSevSnpValidateSystemRam() will use the 2MB entry. A hypervisor backing the memory may choose to use the different page size in the RMP entry. In those cases, the PVALIDATE instruction should return SIZEMISMATCH. If a SIZEMISMATCH is detected, then validate all 512-pages constituting a 2MB region. Upon completion, the PVALIDATE instruction sets the rFLAGS.CF to 0 if instruction changed the RMP entry and to 1 if the instruction did not change the RMP entry. The rFlags.CF will be 1 only when a memory region is already validated. We should not double validate a memory as it could lead to a security compromise. If double validation is detected, terminate the boot. Cc: Michael Roth Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Acked-by: Jiewen Yao Acked-by: Gerd Hoffmann Signed-off-by: Brijesh Singh

OvfmPkg/VmgExitLib: Validate #VC MMIO is to un-encrypted memory

2021-01-07T19:34:39+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 When SEV-ES is active, and MMIO operation will trigger a #VC and the VmgExitLib exception handler will process this MMIO operation. A malicious hypervisor could try to extract information from encrypted memory by setting a reserved bit in the guests nested page tables for a non-MMIO area. This can result in the encrypted data being copied into the GHCB shared buffer area and accessed by the hypervisor. Prevent this by ensuring that the MMIO source/destination is un-encrypted memory. For the APIC register space, access is allowed in general. Cc: Jordan Justen Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Brijesh Singh Acked-by: Laszlo Ersek Signed-off-by: Tom Lendacky Message-Id: <0cf28470ad5e694af45f7f0b35296628f819567d.1610045305.git.thomas.lendacky@amd.com>

OvmfPkg/MemEncryptSevLib: Address range encryption state interface

2021-01-07T19:34:39+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 Update the MemEncryptSevLib library to include an interface that can report the encryption state on a range of memory. The values will represent the range as being unencrypted, encrypted, a mix of unencrypted and encrypted, and error (e.g. ranges that aren't mapped). Cc: Jordan Justen Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Brijesh Singh Acked-by: Laszlo Ersek Signed-off-by: Tom Lendacky Message-Id: <0d98f4d42a2b67310c29bac7bcdcf1eda6835847.1610045305.git.thomas.lendacky@amd.com>

OvmfPkg/MemEncryptSevLib: Make the MemEncryptSevLib available for SEC

2021-01-07T19:34:39+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In preparation for a new interface to be added to the MemEncryptSevLib library that will be used in SEC, create an SEC version of the library. This requires the creation of SEC specific files. Some of the current MemEncryptSevLib functions perform memory allocations which cannot be performed in SEC, so these interfaces will return an error during SEC. Also, the current MemEncryptSevLib library uses some static variables to optimize access to variables, which cannot be used in SEC. Cc: Jordan Justen Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Brijesh Singh Acked-by: Laszlo Ersek Signed-off-by: Tom Lendacky Message-Id: