summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Library
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/Library: Impl SmmCpuPlatformHookBeforeMmiHandler funcJiaxin Wu2024-10-121-1/+19
| | | | | | | This patch is to add SmmCpuPlatformHookBeforeMmiHandler func for OVMF. Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
* OvmfPkg: Use TdInfo instead of fw_cfg to get cpu count in TDVFCeping Sun2024-09-132-2/+15
| | | | | | | | | | | | | | | | Currently TDVF gets cpu count information via fw_cfg, but this information can also be retrieved by calling of TdCall.TdInfo. And TdCall is responded by tdx-module which is trust. So, from the security perspective we shall use TdCall.Tdinfo instead of fw_cfg. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
* OvmfPkg/QemuFwCfgS3Lib: Disable S3 detection in TDVFCeping Sun2024-09-091-0/+5
| | | | | | | | | | | | | | | | | Refer to the section 2.1 of tdx-virtual-firmware-design-guide spec, APCI S3 is not supported in TDVF. Therefore, TDVF should not read the S3 status via fw_cfg and always set it as unsupported. spec: https://cdrdv2.intel.com/v1/dl/getContent/733585 Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
* OvmfPkg: Use TdHob instead of e820tables to get memory info in TDVFCeping Sun2024-09-031-0/+34
| | | | | | | | | | | | | | | | | | | Currently, TDVF gets LowMemory and FistNonAddress from the e820tables via fw_cfg, while TD-Hob can also provide the memory info of LowMemory and FistNonAddress. In current stage e820tables are not measured but TD-Hob is measured in early phase by TDVF. So, from the security perspective we'd better use the information from TD-Hob instead of e820tables. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
* OvmfPkg/PlatformInitLib: allow switching to 4-level pagingGerd Hoffmann2024-08-303-0/+185
| | | | | | | | | | | | | | | | There are a number of mostly older guests such as RHEL-7 which do not support 5-level paging. This patch adds support for switching from 5-level paging mode back to 4-level paging mode. This is done in PEI, after inspecting the address space needed (installed memory and reservations configured via fw_cfg). By default small guests (which need less than 1 TB) will use 4-level paging mode. There is a fw_cfg override though, so it is possible to force the one or the other this way: qemu-system-x86_64 -fw_cfg name=opt/org.tianocode/PagingLevel,string=5 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/OvmfXen: Introduce Xen's ResetSystemLib, to use xen hypercallAnthony PERARD2024-08-304-0/+229
| | | | | | | | | | | | When booting OvmfXen, the ACPI interface for shutdown/reset might not be available, instead use the hypercall interface. While it's probably possible to use the hypercall in all cases, we keep using the same interface while it still possible. That is ACPI on HVM guest, and fallback to hypercall on PVH guest. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
* OvmfPkg/XenHypercallLib: Add SchedOp hypercallAnthony PERARD2024-08-301-0/+14
| | | | | | | | | | | | | | | Add a new function to allow to make an hypercall to shutdown the machine. This import "sched.h" public header from Xen Project's repo. Some changes have been made to be closer to EDK2's coding style. Add the entire OvmfPkg/Include/IndustryStandard/Xen/ directory to LicenseCheck ignore. All the existing header files, as well as the new sched.h, are MIT licensed. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
* OvmfPkg/XenHypercallLib: Use direct hypercallsJason Andryuk2024-08-304-44/+148
| | | | | | | | | | | This removes the need to allocate memory for the hypercall page, particularly for use during runtime. This also makes the library usable in all phases, so LIBRARY_CLASS can remove the restrictions. The processor vendor is used to select vmmcall or vmcall instructions. The listed vendors are those in the Xen tree. Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
* OvmfPkg: Refactor PcdSetNxForStack usage in TDVFCeping Sun2024-08-302-1/+5
| | | | | | | | | | | | | | In the current code, TDVF reads the PcdSetNxForStack value via fw_cfg , but overwrites it with a fixed value after the read is complete. In this patch, TDVF removes the redundant logic code. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
* OvmfPkg/PlatformInitLib: Reserve Sec Page Tables in TDVFCeping Sun2024-08-291-0/+12
| | | | | | | | | | | | | | | | In the system boot phase, if OS postpone onlining some CPU until later, the sec page tables could be overwritten. So, TDVF needs to reserve the initial page tables that would be used by APs on Mailbox wakeup. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Elena Reshetova <elena.reshetova@intel.com> Cc: Kirill A Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com>
* OvmfPkg: remove last instances of EFI_D_Leif Lindholm2024-07-311-1/+1
| | | | | | Change debug print levels to modern DEBUG_ format. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
* OvmfPkg: Enable AMD SEV-ES DebugVirtualizationAlexey Kardashevskiy2024-07-042-2/+10
| | | | | | | | | | | | | | | | | | | | | Write the feature bit into PcdConfidentialComputingGuestAttr and enable DebugVirtualization in PEI, SEC, DXE. 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/g
* OvmfPkg: Add AMD SEV-ES DebugVirtualization feature supportAlexey Kardashevskiy2024-07-044-3/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/
* OvmfPkg/Sec: Setup MTRR early in the boot process.Gerd Hoffmann2024-06-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically before running lzma uncompress of the main firmware volume. This is needed to make sure caching is enabled, otherwise the uncompress can be extremely slow. Adapt the ASSERTs and MTRR setup in PlatformInitLib to the changes. Background: Depending on virtual machine configuration kvm may uses EPT memory types to apply guest MTRR settings. In case MTRRs are disabled kvm will use the uncachable memory type for all mappings. The vmx_get_mt_mask() function in the linux kernel handles this and can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kvm/vmx/vmx.c?h=v6.7.1#n7580 In most VM configurations kvm uses MTRR_TYPE_WRBACK unconditionally. In case the VM has a mdev device assigned that is not the case though. Before commit e8aa4c6546ad ("UefiCpuPkg/ResetVector: Cache Disable should not be set by default in CR0") kvm also ended up using MTRR_TYPE_WRBACK due to KVM_X86_QUIRK_CD_NW_CLEARED. After that commit kvm evaluates guest mtrr settings, which why setting up MTRRs early is important now. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* AmdSev: Halt on failed blob allocationTobin Feldman-Fitzthum2024-06-251-5/+8
| | | | | | | | | | | | A malicious host may be able to undermine the fw_cfg interface such that loading a blob fails. In this case rather than continuing to the next boot option, the blob verifier should halt. For non-confidential guests, the error should be non-fatal. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
* OvmfPkg/BhyvePkg: honor FwCfg when setting the bootorderCorvin Köhne2024-06-182-6/+12
| | | | | | | | | | | Bhyve has added support for the bootorder FwCfg file some time ago [1][2]. This FwCfg file is currently ignored by the OVMF and has no effect. Copy the relevant code from Qemu to Bhyve to make it usable. [1] https://github.com/freebsd/freebsd-src/commit/6632a0a4e3ab68b0e31b612e8aeca14de3fc8159 [2] https://github.com/freebsd/freebsd-src/commit/480bef9481f0c44b19ac4b2adb09f6c3191acd41 Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
* OvmfPkg/PlatformInitLib: allow PhysBits larger than 48Gerd Hoffmann2024-06-061-5/+5
| | | | | | | If GuestPhysBits reports more than 48 phys-bits can be used allow to go beyond that limit. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/PlatformInitLib: add support for GuestPhysBitsGerd Hoffmann2024-06-061-3/+14
| | | | | | | | | | | | | | Add support for GuestPhysBits (cpuid 0x80000008, eax, bits 23:16). GuestPhysBits is a field which can be set by the hypervisor to inform the guest about the /usable/ physical address space bits. This can be smaller than the PhysBits of the CPU, for example because of nested paging limitations. OVMF will read GuestPhysBits, log the value, in case it is set use it as upper limit. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Add no hardcode version of FdtNorFlashQemuLibChao Li2024-06-042-0/+211
| | | | | | | | | | | | | | | | | | | | | | | | | | This library is copied from ArmVirtPkg, in the Arm version, the value of PcdFlashNvStorageVariableBase, PcdFlashNvStorageFtwWorkingBase and PcdFlashNvStorageFtwSpareBase are hardcoded in INC file. This version will calculate them from FDT resource and using the set PCD to store when the NorFlashInitialise is called. By default, the first available flash(not used for storage UEFI code) as NV variable storage medium. In this way, UEFI can better handle the change of flash base address, which is suitable for different cpu architecture board implementation. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4770 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn> Co-authored-by: Xianglai Li <lixianglai@loongson.cn> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Use newly defined Unaccepted Memory TypeSachin Ganesh2024-05-082-6/+6
| | | | | | | | | | | | | | 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/SmmCpuFeaturesLib: Check Smbase Relocation is done or notJiaxin Wu2024-05-081-11/+22
| | | | | | | | | | | | | | | | | | | | | | | | Based on gSmmBaseHobGuid: If gSmmBaseHobGuid found, means SmBase info has been relocated and recorded in the SmBase array. So, this patch check smbase relocation is done or not in SmmCpuFeaturesInitializeProcessor(). With SmmRelocationLib, gSmmBaseHobGuid will be always created. Here this patch just makes the function/logic correct. The SMM Relocation logic can be totally cleaned from the SmmCpuFeaturesLib. But it will happen in the future patch set, this patch does not target to the cleanup work. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg: Refine SmmAccess implementationJiaxin Wu2024-05-082-0/+11
| | | | | | | | | | | | | | | | | | | | This patch refines the SmmAccess implementation: 1. SmramMap will be retrieved from the gEfiSmmSmramMemoryGuid instead of original from the TSEG Memory Base register. 2. Remove the gEfiAcpiVariableGuid creation, thus the DESCRIPTOR_INDEX definition can be also cleaned. 3. The gEfiAcpiVariableGuid HOB is moved to the OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuidJiaxin Wu2024-05-082-40/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the PiSmmCpuDxeSmm driver, SMRAM allocation for SMI handlers and processor Save State areas was traditionally performed using the Smst->AllocatePages() function during the DXE phase. The introduction of SmmRelocationLib changes this process by moving the allocation to the PEI phase, where Smst->AllocatePages() is not accessible. Instead, the allocation is now handled by partitioning the SMRAM based on the information provided by a GUID HOB (identified by gEfiSmmSMramMemoryGuid). This patch is to ensure that OVMF produces the gEfiSmmSMramMemoryGuid HOB, allowing SmmRelocationLib to reserve the necessary memory for SMBASE relocation. More info for the change: 1. The EFI_SMM_SMRAM_MEMORY_GUID HOB, as defined in the PI specification, vol.3, section 5, which is used to describe the SMRAM memory regions supported by the platform. This HOB should be produced during the memory detection phase to align with the PI spec. 2. In addition to the memory reserved for ACPI S3 resume, an increasing number of features require reserving SMRAM for specific purposes, such as SmmRelocation. Other advanced features in Intel platforms also necessitate this. The implementation of these features varies and is entirely dependent on the platform. This is why an increasing number of platforms are adopting the EFI_SMM_SMRAM_MEMORY_GUID HOB for SMRAM description. 3. It is crucial that the SMRAM information remains consistent when retrieved from the platform, whether through the SMM ACCESS PPI/Protocol or the EFI_SMM_SMRAM_MEMORY_GUID HOB. Inconsistencies can lead to unexpected issues, most commonly memory region conflicts. 4. The SMM ACCESS PPI/Protocol can be naturally implemented for general use. The common approach is to utilize the EFI_SMM_SMRAM_MEMORY_GUID HOB. For reference, see the existing implementation in the EDK2 repository at edk2/UefiPayloadPkg/SmmAccessDxe/SmmAccessDxe.inf and edk2-platforms/Silicon/Intel/IntelSiliconPkg/Feature/ SmmAccess/Library/PeiSmmAccessLib/PeiSmmAccessLib.inf. Next patch will refine the OVMF SMM Access to consume the EFI_SMM_SMRAM_MEMORY_GUID HOB. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/SmmRelocationLib: Add library instance for OVMFJiaxin Wu2024-05-088-0/+1293
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are below 2 differences between AMD & OVMF according existing implementation: 1.The mode of the CPU check is different between the AMD & OVMF. OVMF: CpuSaveState->x86.SMMRevId & 0Xffff AMD: LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA 2.Existing SmBase configuration is different between the AMD & OVMF. OVMF: if ((CpuSaveState->x86.SMMRevId & 0xFFFF) == 0) { CpuSaveState->x86.SMBASE = mSmBaseForAllCpus[CpuIndex]; } else { CpuSaveState->x64.SMBASE = mSmBaseForAllCpus[CpuIndex]; } AMD: AmdCpuState->x64.SMBASE = mSmBaseForAllCpus[CpuIndex]; This patch provides the SmmRelocationLib library instance for OVMF to handle the logic difference, and it won't change the existing implementation code logic. Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/CcExitLib: Drop special handling for Encrypted MMIO to APICMichael Roth2024-05-021-11/+1
| | | | | | | | | | | | | | | | | | | The current #VC handler guards against MMIO to addresses that are mapped with the encryption bit set, but has an special exception for MMIO accesses to the APIC base address so allow for early access during SEC. Now that the SEC page table has the encryption bit cleared for the APIC base address range, there is no longer any need for this special handling. Go ahead and remove it. Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Remove QemuFwCfgLibMmio.infChao Li2024-04-301-54/+0
| | | | | | | | | | | | All of platforms are switching to QemuFwCfgMmioDxeLib.inf, remove QemuFwCfgLibMmio.inf now. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Chao Li <lichao@loongson.cn>
* OvmfPkg: Copy the same new INF as QemuFwCfgLibMmio.infChao Li2024-04-301-0/+54
| | | | | | | | | | | | | Copy QemuFwCfgLibMmio.inf to QemuFwCfgMmioDxeLib.inf, QemuFwCfgLibMmio.inf will be deleted when all platforms switching is completed. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Chao Li <lichao@loongson.cn>
* OvmfPkg: Add the QemuFwCfgMmioLib PEI stage versionChao Li2024-04-302-0/+281
| | | | | | | | | | | | | Added the PEI stage library for QemuFwCfgMmioLib, which uses the FDT to find the fw_cfg and parse it. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Co-authored-by: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Chao Li <lichao@loongson.cn>
* OvmfPkg: Add the way of HOBs in QemuFwCfgLibMmioChao Li2024-04-304-27/+216
| | | | | | | | | | | | | | | | | | | Added the HOB methods to load and store the QEMU firmware configure address, data address and DMA address, which are not enabled during the DXE stage. Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc"). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn>
* OvmfPkg: Separate QemuFwCfgLibMmio.c into two filesChao Li2024-04-304-186/+327
| | | | | | | | | | | | | | | | | | | | | | Separate QemuFwCfgLibMmio.c into two files named QemuFwCfgLibMmio.c and QemuFwCfgLibMmioDxe.c, added a new header named QemuFwCfgLibMmioInternal.h for MMIO version. Some DXE stage variables became non-static in this patch, they will be restored to static in the next patch. Build-tested only (with "ArmVirtQemu.dsc and RiscVVirtQemu.dsc"). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4755 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn>
* OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)Adam Dunlap2024-04-231-11/+173
| | | | | | | | | | | | | | | | | | Ensure that when a #VC exception happens, the instruction at the instruction pointer matches the instruction that is expected given the error code. This is to mitigate the ahoi WeSee attack [1] that could allow hypervisors to breach integrity and confidentiality of the firmware by maliciously injecting interrupts. This change is a translated version of a linux patch e3ef461af35a ("x86/sev: Harden #VC instruction emulation somewhat") [1] https://ahoi-attacks.github.io/wesee/ Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Adam Dunlap <acdunlap@google.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0Tom Lendacky2024-04-171-3/+6
| | | | | | | | | | | | | | | | | | | | 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 <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* Ovmfpkg/CcExitLib: Provide SVSM discovery supportTom Lendacky2024-04-173-4/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 The SVSM specification documents an alternative method of discovery for the SVSM using a reserved CPUID bit and a reserved MSR. For the CPUID support, the #VC handler of an SEV-SNP guest should modify the returned value in the EAX register for the 0x8000001f CPUID function by setting bit 28 when an SVSM is present. For the MSR support, new reserved MSR 0xc001f000 has been defined. A #VC should be generated when accessing this MSR. The #VC handler is expected to ignore writes to this MSR and return the physical calling area address (CAA) on reads of this MSR. 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: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/AmdSvsmLib: Add support for the SVSM create/delete vCPU callsTom Lendacky2024-04-171-1/+53
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 The RMPADJUST instruction is used to alter the VMSA attribute of a page, but the VMSA attribute can only be changed when running at VMPL0. When an SVSM is present, use the SVSM_CORE_CREATE_VCPU and SVSM_CORE_DELTE_VCPU calls to add or remove the VMSA attribute on a page instead of issuing the RMPADJUST instruction directly. Implement the AmdSvsmSnpVmsaRmpAdjust() API to perform the proper operation to update the VMSA attribute. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/BaseMemEncryptSevLib: Maximize Page State Change efficiencyTom Lendacky2024-04-171-0/+7
| | | | | | | | | | | | | | | | | | | 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 <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/AmdSvsmLib: Add support for the SVSM_CORE_PVALIDATE callTom Lendacky2024-04-171-1/+182
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 The PVALIDATE instruction can only be performed at VMPL0. An SVSM will be present when running at VMPL1 or higher. When an SVSM is present, use the SVSM_CORE_PVALIDATE call to perform memory validation instead of issuing the PVALIDATE instruction directly. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/BaseMemEncryptSevLib: Use AmdSvsmSnpPvalidate() to validate pagesTom Lendacky2024-04-174-74/+9
| | | | | | | | | | | | | | | | | | | | 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 <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* Ovmfpkg/AmdSvsmLib: Create AmdSvsmLib to handle SVSM related servicesTom Lendacky2024-04-172-0/+305
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 Add initial support for the new AmdSvsmLib library to OvmfPkg. The initial implementation fully implements the library interfaces. The SVSM presence check, AmdSvsmIsSvsmPresent(), determines the presence of an SVSM by checking if an SVSM has been advertised in the SEV-SNP Secrets Page. The VMPL API, AmdSvsmSnpGetVmpl(), returns the VMPL level at which OVMF is currently running. The CAA API, AmdSvsmSnpGetCaa(), returns the Calling Area Address when an SVSM is present, 0 otherwise. The PVALIDATE API, AmdSvsmSnpPvalidate(), copies the PVALIDATE logic from the BaseMemEncryptSevLib library for the initial implementation. The BaseMemEncryptSevLib library will be changed to use this new API so that the decision as to whether the SVSM is needed to perform the operation can be isolated to this library. The VMSA API, AmdSvsmSnpVmsaRmpAdjust(), copies the RMPUPDATE logic from the MpInitLib library for the initial implementation. The MpInitLib library will be changed to use this new API so that the decision as to whether the SVSM is needed to perform the operation can be isolated to this library. Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/BaseMemEncryptSevLib: Maximize Page State Change efficiencyTom Lendacky2024-04-171-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change supportTom Lendacky2024-04-176-51/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 In preparation for running under an SVSM at VMPL1 or higher (higher numerically, lower privilege), re-organize the way a page state change is performed in order to free up the GHCB for use by the SVSM support. Currently, the page state change logic directly uses the GHCB shared buffer to build the page state change structures. However, this will be in conflict with the use of the GHCB should an SVSM call be required. Instead, use a separate buffer (an area in the workarea during SEC and an allocated page during PEI/DXE) to hold the page state change request and only update the GHCB shared buffer as needed. Since the information is copied to, and operated on, in the GHCB shared buffer this has the added benefit of not requiring to save the start and end entries for use when validating the memory during the page state change sequence. 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: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/BaseMemEncryptSevLib: Calculate memory size for Page State ChangeTom Lendacky2024-04-171-4/+8
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 Calculate the amount of memory that can be use to build the Page State Change data (SNP_PAGE_STATE_CHANGE_INFO) instead of using a hard-coded size. This allows for changes to the GHCB shared buffer size without having to make changes to the page state change code. 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: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/BaseMemEncryptSevLib: Fix uncrustify errorsTom Lendacky2024-04-171-12/+15
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 In prep for follow-on patches, fix an area of the code that does not meet the uncrustify coding standards. 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: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/BaseMemEncryptLib: Fix error check from AsmRmpAdjust()Tom Lendacky2024-04-171-4/+4
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4654 The AsmRmpAdjust() function returns a UINT32, however in SevSnpIsVmpl0() the return value is checked with EFI_ERROR() when it should just be compared to 0. Fix the error check. 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: Laszlo Ersek <lersek@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Min Xu <min.m.xu@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
* OmvfPkg/HashLibTdx: Add HashLibTdxMin M Xu2024-04-172-0/+250
| | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4752 This library is the one of SecurityPkg/Library/HashLibTdx. It is designed for Intel TDX enlightened OVMF. So moving it from SecurityPkg to OvmfPkg. To prevent breaking the build, the moving is splitted into 2 patch. SecurityPkg/Library/HashLibTdx will be deleted in the next patch. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/CcExitLib: Update TDVMCALL_EXPOSE_REGS_MASKCeping Sun2024-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4696 Refer to the [GHCI] spec, TDVF should clear the BIT5 for RBP in the mask. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.5 https://cdrdv2.intel.com/v1/dl/getContent/726792 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> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Isaku Yamahata <isaku.yamahata@intel.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/PlatformInitLib: add 5-level paging supportGerd Hoffmann2024-02-291-19/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | Adjust physical address space logic for la57 mode (5-level paging). With a larger logical address space we can identity-map a larger physical address space. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Message-Id: <20240222105407.75735-4-kraxel@redhat.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Oliver Steffen <osteffen@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> [lersek@redhat.com: turn the "Cc:" message headers from Gerd's on-list posting into "Cc:" tags in the commit message, in order to pacify "PatchCheck.py"]
* OvmfPkg: Align XenRealTimeClockLib function headers with return valuesSuqiang Ren2024-02-091-4/+18
| | | | | | | | | | | | | | | XenRealTimeClockLib is used to back the runtime services time functions, so align the description of the function return values with the defined values for these services as described in UEFI Spec 2.10. REF: UEFI spec 2.10 section 8 Services ? Runtime Services Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
* ArmVirtPkg: Move PlatformBootManagerLib to OvmfPkgChao Li2024-02-064-0/+1541
| | | | | | | | | | | | | | | | | | | Moved the PlatformBootManagerLib to OvmfPkg and renamed to PlatformBootManagerLibLight for easy use by other ARCH. Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc"). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4663 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Lazlo Ersek <lersek@redhat.com> Signed-off-by: Chao Li <lichao@loongson.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* ArmVirtPkg: Move the FdtSerialPortAddressLib to OvmfPkgChao Li2024-02-062-0/+283
| | | | | | | | | | | | | | | | | | Move the FdtSerialPortAddressLib to Ovmfpkg so that other ARCH can easily use it. Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc"). BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584 Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leif Lindholm <quic_llindhol@quicinc.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Chao Li <lichao@loongson.cn> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Update PlatformAddressWidthInitialization for CloudHvThomas Barrett2024-01-151-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | In addition to initializing the PhysMemAddressWidth and FirstNonAddress fields in PlatformInfoHob, the PlatformAddressWidthInitialization function is responsible for initializing the PcdPciMmio64Base and PcdPciMmio64Size fields. Currently, for CloudHv guests, the PcdPciMmio64Base is placed immediately after either the 4G boundary or the last RAM region, whichever is greater. We do not change this behavior. Previously, when booting CloudHv guests with greater than 1TiB of high memory, the PlatformAddressWidthInitialization function incorrect calculates the amount of RAM using the overflowed 24-bit CMOS register. Now, we update the PlatformAddressWidthInitialization behavior on CloudHv to scan the E820 entries to detect the amount of RAM. This allows CloudHv guests to boot with greater than 1TiB of RAM Signed-off-by: Thomas Barrett <tbarrett@crusoeenergy.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-03-07 06:46:51 +0000