summaryrefslogtreecommitdiff
path: root/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLibInternal.c
AgeCommit message (Collapse)AuthorFilesLines
2026-08-27OvmfPkg/BaseMemEncryptSevLib: Fetch Sev data from the work areaJohn Berg1-112/+35
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 <jhnberg@amazon.co.uk> Signed-off-by: Ivan Orlov <iorlov@amazon.co.uk>
2026-08-27OvmfPkg/BaseMemEncryptSevLib: Make GetSevEsWorkArea() Pei/Dxe sharedJohn Berg1-0/+1
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 <jhnberg@amazon.co.uk>
2025-09-09OvmfPkg/MemEncryptSevLib: Check if SEV-SNP coherency mitigitation is neededTom Lendacky1-4/+50
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 <thomas.lendacky@amd.com>
2024-07-04OvmfPkg: Add AMD SEV-ES DebugVirtualization feature supportAlexey Kardashevskiy1-3/+24
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 <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Alexey Kardashevskiy <aik@amd.com> --- Changes: v5: * "rb" from Tom v4: * s/DebugSwap/DebugVirtualization/
2022-02-28OvmfPkg/BaseMemEncryptLib: use the SEV_STATUS MSR value from workareaBrijesh Singh1-76/+65
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 <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
2021-12-09OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled()Brijesh Singh1-0/+27
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 <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
2021-12-07OvmfPkg: Apply uncrustify changesMichael Kubacki1-6/+6
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the OvmfPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Andrew Fish <afish@apple.com>
2021-01-07OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky1-0/+145
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To ensure that we always use a validated encryption mask for an SEV-ES guest, create a new interface in the MemEncryptSevLib library to return the encryption mask. This can be used in place of the multiple locations where CPUID is used to retrieve the value (which would require validation again) and allows the validated mask to be returned. The PEI phase will use the value from the SEV-ES work area. Since the SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>