Tianocore/edk2.git/OvmfPkg/Include/Library/MemEncryptSevLib.h, branch master

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: Add AMD SEV-ES DebugVirtualization feature support

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

The SEV-ES DebugVirtualization feature enables type B swapping of debug registers on #VMEXIT and makes #DB and DR7 intercepts unnecessary and unwanted. When DebugVirtualization is enabled, this stops booting if interaction from the HV. Add new API to PEI, SEC, DXE. This does not change the existing behaviour yet. 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/

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

OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled()

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

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Create a function that can be used to determine if VM is running as an SEV-SNP guest. 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

OvmfPkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Andrew Fish

OvmfPkg: introduce a common work area

2021-08-27T12:10:40+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429 Both the TDX and SEV support needs to reserve a page in MEMFD as a work area. The page will contain meta data specific to the guest type. Currently, the SEV-ES support reserves a page in MEMFD (PcdSevEsWorkArea) for the work area. This page can be reused as a TDX work area when Intel TDX is enabled. Based on the discussion [1], it was agreed to rename the SevEsWorkArea to the OvmfWorkArea, and add a header that can be used to indicate the work area type. [1] https://edk2.groups.io/g/devel/message/78262?p=,,,20,0,0,0::\ created,0,SNP,20,2,0,84476064 Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel Cc: Erdem Aktas Signed-off-by: Brijesh Singh Reviewed-by: Min Xu Reviewed-by: Jiewen Yao

OvmfPkg/BaseMemEncryptSevLib: remove Flush parameter

2021-05-29T12:15:21+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The Flush parameter is used to provide a hint whether the specified range is Mmio address. Now that we have a dedicated helper to clear the memory encryption mask for the Mmio address range, its safe to remove the Flush parameter from MemEncryptSev{Set,Clear}PageEncMask(). Since the address specified in the MemEncryptSev{Set,Clear}PageEncMask() points to a system RAM, thus a cache flush is required during the encryption mask update. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel Cc: Laszlo Ersek Cc: Erdem Aktas Reviewed-by: Laszlo Ersek Signed-off-by: Brijesh Singh Message-Id: <20210519181949.6574-14-brijesh.singh@amd.com>

OvmfPkg/BaseMemEncryptSevLib: introduce MemEncryptSevClearMmioPageEncMask()

2021-05-29T12:15:21+00:00

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MemEncryptSevClearMmioPageEncMask() helper can be used for clearing the memory encryption mask for the Mmio region. The MemEncryptSevClearMmioPageEncMask() is a simplified version of MemEncryptSevClearPageEncMask() -- it does not flush the caches after clearing the page encryption mask. Cc: James Bottomley Cc: Min Xu Cc: Jiewen Yao Cc: Tom Lendacky Cc: Jordan Justen Cc: Ard Biesheuvel Cc: Laszlo Ersek Cc: Erdem Aktas Reviewed-by: Laszlo Ersek Signed-off-by: Brijesh Singh Message-Id: <20210519181949.6574-10-brijesh.singh@amd.com>

OvmfPkg/VmgExitLib: Support nested #VCs

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

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 In order to be able to issue messages or make interface calls that cause another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support for nested #VCs. In order to support nested #VCs, GHCB backup pages are required. If a #VC is received while currently processing a #VC, a backup of the current GHCB content is made. This allows the #VC handler to continue processing the new #VC. Upon completion of the new #VC, the GHCB is restored from the backup page. The #VC recursion level is tracked in the per-vCPU variable area. Support is added to handle up to one nested #VC (or two #VCs total). If a second nested #VC is encountered, an ASSERT will be issued and the vCPU will enter CpuDeadLoop (). For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory layout, with two new fixed PCDs to provide the address and size of the backup area. For PEI/DXE, the GHCB backup pages are allocated as boot services pages using the memory allocation library. Cc: Jordan Justen Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Brijesh Singh Acked-by: Laszlo Ersek Signed-off-by: Tom Lendacky Message-Id: