OvmfPkg/AmdSevDxe: Close mAcceptAllMemoryEvent 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 attributes 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 AmdSevDxe 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 AmdSevDxe 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 AmdSevDxe 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 table 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 changes 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 parameter 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 EncMask 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 range 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 License 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 map 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 LibraryClasses 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 sections 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 width 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 driver 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>