Tianocore/edk2.git/OvmfPkg/Library/BaseMemEncryptSevLib/X64, 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: 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/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/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0

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

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 Currently, an SEV-SNP guest will terminate if it is not running at VMPL0. The requirement for running at VMPL0 is removed if an SVSM is present. Update the current VMPL0 check to additionally check for the presence of an SVSM is the guest is not running at VMPL0. Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Laszlo Ersek Cc: Michael Roth Cc: Min Xu Acked-by: Gerd Hoffmann Signed-off-by: Tom Lendacky

OvmfPkg/BaseMemEncryptSevLib: Maximize Page State Change efficiency

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

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 Similar to the Page State Change optimization added previously, also take into account the possiblity of using the SVSM for PVALIDATE instructions. Conditionally adjust the maximum number of entries based on how many entries the SVSM calling area can support. Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Laszlo Ersek Cc: Michael Roth Cc: Min Xu Acked-by: Gerd Hoffmann Signed-off-by: Tom Lendacky

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/BaseMemEncryptSevLib: Maximize Page State Change efficiency

2024-04-17T18:30:03+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 When building the Page State Change entries for a range of memory, it can happen that multiple calls to BuildPageStateBuffer() need to be made. If the size of the input work area passed to BuildPageStateBuffer() exceeds the number of entries that can be passed to the hypervisor using the GHCB shared buffer, the Page State Change VMGEXIT support will issue multiple VMGEXITs to process all entries in the buffer. However, it could be that the final VMGEXIT for each round of Page State Changes is only for a small number of entries and subsequent VMGEXITs may still be issued to handle the full range of memory requested. To maximize the number of entries processed during the Page State Change VMGEXIT, limit BuildPageStateBuffer() to not build entries that exceed the maximum number of entries that can be handled in a single Page State Change VMGEXIT. Cc: Ard Biesheuvel Cc: Erdem Aktas Cc: Gerd Hoffmann Cc: Jiewen Yao Cc: Laszlo Ersek Cc: Michael Roth Cc: Min Xu Reviewed-by: Gerd Hoffmann Signed-off-by: Tom Lendacky