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

OvmfPkg/BaseMemEncryptSevLib: Fix read-only pagetable support

2026-09-11T08:27:12+00:00

SetMemoryEncDec() ensures that any newly created pagetable pages are marked read-only upon completion of the pagetable changes. This is done by calling EnablePageTableProtection(). EnablePageTableProtection() invokes SetPageTablePoolReadOnly() which expects the input PageTableBase parameter to point to the beginning of the level 4 pagetable as it calculates the offset/index into the pagetable based on the input address. However, there is a bug that is seen when the input address is above 512GB. SetMemoryEncDec() uses the PageMapLevel4Entry variable when it invokes EnablePageTableProtection(), which points to the start of the level 4 pagetable if the address is below 512GB. Once above that range, PageMapLevel4Entry points past the start of the pagetable. This causes SetPageTablePoolReadOnly() to improperly address pagetable entries. This was recently exposed when 7735ed4f8eb3 ("OvmfPkg/PlatformInitLib: Set dynamic MMIO window size to 1/4") pushed the MMIO range above 512GB. Fix the issue by always using the Cr3BaseAddress value when calling EnablePageTableProtection(). Since PageMapLevel4Entry is never used outside of the loop anymore, remove the initialization to NULL. Also, the check for Cr3BaseAddress being NULL does not need to be done inside the loop, so move it to outside the loop (which will suppress incorrect compiler/analyzer warnings). Signed-off-by: Tom Lendacky

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/BaseMemEncryptSevLib: IGVM data HOB ranges are prevalidated

2026-04-08T20:38:21+00:00

Exclude these ranges in addition to the ranges from the static mPreValidatedRange array, by checking the IGVM data HOBs in DetectPreValidatedOverLap(). Signed-off-by: Gerd Hoffmann

OvmfPkg/BaseMemEncryptSevLib: DEBUG_VERBOSE -> DEBUG_PAGING

2026-03-23T09:55:50+00:00

Use new DEBUG_PAGING log bit in OvmfPkg/BaseMemEncryptSevLib. Signed-off-by: Gerd Hoffmann

OvmfPkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Note: Headers taken directly from external projects, such as those in OvmfPkg/Include/IndustryStandard/Xen/ were not modified since they may be periodically re-synced and do not follow other edk2 coding stadards. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

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/MemEncryptSevLib: Check if SEV-SNP coherency mitigitation is needed

2025-09-09T17:43:31+00:00

CPUID bit Fn8000001F_EBX[31] defines the COHERNECY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed. Add support to check for this CPUID bit and avoid the mitigation if set. Signed-off-by: Tom Lendacky

OvmfPkg/MemEncryptSevLib: Evict cache lines during SNP memory validation

2025-09-09T17:43:31+00:00

An SNP cache coherency vulnerability may require a mitigation to evict cache lines after memory has been validated. Perform this mitigation after having validated memory. CVE-2024-36331 Signed-off-by: Michael Roth Co-developed-by: Tom Lendacky Signed-off-by: Tom Lendacky

OvmfPkg: Enable AMD SEV-ES DebugVirtualization

2024-07-04T20:39:26+00:00

Write the feature bit into PcdConfidentialComputingGuestAttr and enable DebugVirtualization in PEI, SEC, DXE. Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Michael Roth Cc: Min Xu Reviewed-by: Tom Lendacky Signed-off-by: Alexey Kardashevskiy --- Changes: v5: * "rb" from Tom v4: * s/DebugSwap/DebugVirtualization/g