summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/AmdSevDxe
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Use newly defined Unaccepted Memory TypeSachin Ganesh2024-05-081-2/+2
| | | | | | | | | | | | | | EFI_RESOURCE_MEMORY_UNACCEPTED has been officially defined in the PI 1.8 specification. So all temporary solutions have been replaced with the actual definition. Cc: Felix Polyudov <felixp@ami.com> Cc: Dhanaraj V <vdhanaraj@ami.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Signed-off-by: Sachin Ganesh <sachinganesh@ami.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/AmdSevDxe: Update ConfidentialComputing blob struct definitionRoth, Michael via groups.io2023-04-261-1/+3
| | | | | | | | | | | | | | | | | | | | The Confidential Computing blob defined here is intended to match the definition defined by linux guest kernel. Previously, both definitions relied on natural alignment, but that relies on both OVMF and kernel being compiled as 64-bit. While there aren't currently any plans to enable SNP support for 32-bit compilations, the kernel definition has since been updated to use explicit padding/reserved fields to avoid this dependency. Update OVMF to match that definition. While at it, also fix up the Reserved fields to match the numbering used in the kernel. No functional changes (for currently-supported environments, at least). Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* OvmfPkg/AmdSevDxe: Allocate SEV-SNP CC blob as EfiACPIReclaimMemoryMichael Roth2023-04-261-14/+48
| | | | | | | | | | | | | | The SEV-SNP Confidential Computing blob contains metadata that should remain accessible for the life of the guest. Allocate it as EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest operating system later. Reported-by: Dov Murik <dovmurik@linux.ibm.com> Suggested-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-101-1/+1
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg: Consume new alignment-related macrosGerd Hoffmann2023-04-011-4/+2
| | | | | | | | | | This patch substitutes the macros that were renamed in the second patch with the new, shared alignment macros. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg: Rename IS_ALIGNED macros to avoid name collisionsGerd Hoffmann2023-04-011-3/+3
| | | | | | | | | | | | | This patch is a preparation for the patches that follow. The subsequent patches will introduce and integrate new alignment-related macros, which collide with existing definitions in OvmfPkg. Temporarily rename them to avoid build failure, till they can be substituted with the new, shared definitions. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/AmdSevDxe: Close mAcceptAllMemoryEventDionna Glaze2023-02-151-0/+1
| | | | | | | | | | | | | | | | This event should only trigger once. It should be idempotent, but the allocation of the memory map itself is observable and can cause ExitBootServices to fail with a modified map key. Cc: Thomas Lendacky <Thomas.Lendacky@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Michael Roth <michael.roth@amd.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Fix SevMemoryAcceptance memory attributesDionna Glaze2023-02-151-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hard-coded attributes for the re-added memory space should instead forward the replaced descriptor's capabilities. Tested on Linux with efi=debug. Prior to this change, an 8GiB VM running a kernel without unaccepted memory support shows this entry efi: mem94: [Conventional| | |CC| | | | | | | | | | | ] range=[0x0000000100000000-0x000000023fffffff] (5120MB) This does not have the cache capabilities one would expect for system memory, UC|WC|WT|WB. After this change, the same entry becomes efi: mem94: [Conventional| | |CC| | | | | | | |WB|WT|WC|UC] range=[0x0000000100000000-0x000000023fffffff] (5120MB) This has all the expected attributes. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> [ardb: drop the EFI_MEMORY_CPU_CRYPTO flag - it isn't used anywhere else in EDK2 or Linux so it doesn't actually do anything, and it is unclear whether it is intended for use by the guest in the first place] Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Implement AcceptAllUnacceptedMemory in AmdSevDxeDionna Glaze2023-01-262-3/+22
| | | | | | | | | | | | | | | | | This protocol implementation disables the accept-all-memory behavior of the BeforeExitBootServices event this driver adds. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add memory acceptance event in AmdSevDxeDionna Glaze2023-01-262-0/+98
| | | | | | | | | | | | | | | | | | | The added behavior is to accept all unaccepted memory at ExitBootServices if the behavior is not disabled. This allows safe upgrades for OS loaders to affirm their support for the unaccepted memory type. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Min M. Xu" <min.m.xu@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: "Michael D. Kinney" <michael.d.kinney@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Realize EfiMemoryAcceptProtocol in AmdSevDxeSophia Wolf2023-01-122-4/+54
| | | | | | | | | | | | | | | | | | When a guest OS does not support unaccepted memory, the unaccepted memory must be accepted before returning a memory map to the caller. EfiMemoryAcceptProtocol is defined in MdePkg and is implemented / Installed in AmdSevDxe for AMD SEV-SNP memory acceptance. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Dionna Glaze <dionnaglaze@google.com> Message-Id: <20221108164616.3251967-2-dionnaglaze@google.com>
* OvmfPkg/AmdSev: expose the SNP reserved pages through configuration tableBrijesh Singh2021-12-092-0/+30
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Now that both the secrets and cpuid pages are reserved in the HOB, extract the location details through fixed PCD and make it available to the guest OS through the configuration table. 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: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: Apply uncrustify changesMichael Kubacki2021-12-071-9/+14
| | | | | | | | | | | | 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>
* OvmfPkg/BaseMemEncryptSevLib: remove Flush parameterBrijesh Singh2021-05-291-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20210519181949.6574-14-brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: use MemEncryptSevClearMmioPageEncMask() to clear EncMaskBrijesh Singh2021-05-291-6/+4
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Use the MemEncryptSevClearMmioPageEncMask() to clear memory encryption mask for the Mmio and NonExistent address range. 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: Laszlo Ersek <lersek@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Message-Id: <20210519181949.6574-11-brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: Clear encryption bit on PCIe MMCONFIG rangeTom Lendacky2021-01-072-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 The PCIe MMCONFIG range should be treated as an MMIO range. However, there is a comment in the code explaining why AddIoMemoryBaseSizeHob() is not called. The AmdSevDxe walks the GCD map looking for MemoryMappedIo or NonExistent type memory and will clear the encryption bit for these ranges. Since the MMCONFIG range does not have one of these types, the encryption bit is not cleared for this range. Add support to detect the presence of the MMCONFIG range and clear the encryption bit. This will be needed for follow-on support that will validate that MMIO is not being performed to an encrypted address range under SEV-ES. Even though the encryption bit was set for this range, this still worked under both SEV and SEV-ES because the address range is marked by the hypervisor as MMIO in the nested page tables: - For SEV, access to this address range triggers a nested page fault (NPF) and the hardware supplies the guest physical address (GPA) in the VMCB's EXITINFO2 field as part of the exit information. However, the encryption bit is not set in the GPA, so the hypervisor can process the request without any issues. - For SEV-ES, access to this address range triggers a #VC. Since OVMF runs identity mapped (VA == PA), the virtual address is used to avoid the lookup of the physical address. The virtual address does not have the encryption bit set, so the hypervisor can process the request without any issues. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <711ae2dcb6cb29e4c60862c18330cff627269b81.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-092-15/+2
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state mapLaszlo Ersek2018-03-062-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>: [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html Original commit message from Brijesh: > When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE + > SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by > both guest and hypervisor. Since the data need to be accessed by both > hence we must map the SMMSaved State area as unencrypted (i.e C-bit > cleared). > > This patch clears the SavedStateArea address before SMBASE relocation. > Currently, we do not clear the SavedStateArea address after SMBASE is > relocated due to the following reasons: > > 1) Guest BIOS never access the relocated SavedStateArea. > > 2) The C-bit works on page-aligned address, but the SavedStateArea > address is not a page-aligned. Theoretically, we could roundup the > address and clear the C-bit of aligned address but looking carefully we > found that some portion of the page contains code -- which will causes a > bigger issue for the SEV guest. When SEV is enabled, all the code must > be encrypted otherwise hardware will cause trap. Changes by Laszlo: - separate AmdSevDxe bits from SmmCpuFeaturesLib bits; - spell out PcdLib dependency with #include and in LibraryClasses; - replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages() function; - consequently, pass page-aligned BaseAddress to MemEncryptSevClearPageEncMask(); - zero the pages before clearing the C-bit; - pass Flush=TRUE to MemEncryptSevClearPageEncMask(); - harden the treatment of MemEncryptSevClearPageEncMask() failure. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: refresh #includes and LibraryClassesLaszlo Ersek2018-03-062-7/+1
| | | | | | | | | | | | List those and only those libraries that are used. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sectionsLaszlo Ersek2018-03-062-10/+9
| | | | | | | | | | Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: rewrap to 79 characters widthLaszlo Ersek2018-03-062-19/+22
| | | | | | | | | | | | | There are many overlong lines; it's hard to work with the module like this. Rewrap all files to 79 columns. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: Add AmdSevDxe driverBrijesh Singh2017-07-102-0/+118
When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-21 14:34:16 +0000