Commit Graph

710 Commits

Author SHA1 Message Date
Gerd Hoffmann 775d6cd7ed OvmfPkg/QemuFwCfgDxeLib: use PcdConfidentialComputingGuestAttr
Check PcdConfidentialComputingGuestAttr instead of calling
MemEncryptSevIsEnabled() and MemEncryptTdxIsEnabled() to figure
whenever SEV or TDX is enabled.

This allows to remove the MemEncryptSevLib + MemEncryptTdxLib
dependencies.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2024-12-04 12:40:35 +00:00
Alexander Gryanko 24d835a131 OvmfPkg/Library/HardwareInfoLib: Fix memory allocation for a root bridge
Currently, PciHostBridgeUtilityGetRootBridgesHostProvided allocates memory
for aperture structures without clearing memory. This causes garbage in
the Translation field, but the Base and Limit fields have the correct
values because they are copied from the HOST_BRIDGE_INFO fields in the
HardwareInfoPciHostBridgeHostBridgeHostBridgeGetApertures function.

RootBridge: PciRoot(0x0)
  Support/Attr: 70069 / 70069
    DmaAbove4G: No
NoExtConfSpace: No
     AllocAttr: 3 (CombineMemPMem Mem64Decode)
           Bus: 0 - 80 Translation=0
            Io: 6000 - FFFF Translation=5E9EB018
           Mem: 80000000 - DFFFFFFF Translation=0
    MemAbove4G: 600000000000 - 7FFFFFFFFFFF Translation=0
          PMem: FFFFFFFFFFFFFFFF - 0 Translation=0
   PMemAbove4G: FFFFFFFFFFFFFFFF - 0 Translation=0

Signed-off-by: Alexander Gryanko <xpahos@gmail.com>
2024-11-27 22:06:12 +00:00
Oliver Steffen 9c4542a064 OvmfPkg: Rerun dispatcher after initializing virtio-rng
Since the pixiefail CVE fix the network stack requires a hardware
random number generator. This can currently be a modern CPU supporting
the RDRAND instruction or a virtio-rng device.
The latter is initialized during the BDS phase.
To ensure all depending (network) modules are also started, we need to
run the dispatcher once more after the device was initialized.
Without this, network boot is not available under certain hardware
configurations.

Fixes: 4c4ceb2ceb ("NetworkPkg: SECURITY PATCH CVE-2023-45237")

Analysed-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
2024-11-27 18:07:10 +00:00
Gerd Hoffmann 8c8e05db24 OvmfPkg/PlatformInitLib: enable x2apic mode if needed
Enable x2apic mode in case the number of possible CPUs (including
hotplug-able CPus which are not (yet) online) is larger than 255.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2024-11-25 12:22:38 +00:00
Tom Lendacky d502cc7702 OvmfPkg/PlatformInitLib: Retry NV vars FV check as shared
When OVMF is built with SECURE_BOOT_ENABLE, the variable store will be
populated and validated in PlatformValidateNvVarStore(). When an SEV
or an SEV-ES guest is running, this may be encrypted or unencrypted
depending on how the guest was started. If the guest was started with the
combined code and variable contents (OVMF.fd), then the variable store
will be encrypted. If the guest was started with the separate code and
variables contents (OVMF_CODE.fd and OVMF_VARS.fd), then the variable
store will be unencrypted.

When PlatformValidateNvVarStore() is first invoked, the variable store
area is initially mapped encrypted, which may or may not pass the variable
validation step depending how the guest was launched. To accomodate this,
retry the validation step on failure after remapping the variable store
area as unencrypted.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
2024-11-23 18:02:30 +00:00
Jiaxin Wu e34460c8b2 OvmfPkg/Library: Impl SmmCpuPlatformHookBeforeMmiHandler func
This patch is to add SmmCpuPlatformHookBeforeMmiHandler func
for OVMF.

Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
2024-10-12 08:56:05 +00:00
Ceping Sun ec18fa81d3 OvmfPkg: Use TdInfo instead of fw_cfg to get cpu count in TDVF
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>
2024-09-13 18:10:08 +00:00
Ceping Sun e5715711a4 OvmfPkg/QemuFwCfgS3Lib: Disable S3 detection in TDVF
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>
2024-09-09 02:57:02 +00:00
Ceping Sun d997d3c62f OvmfPkg: Use TdHob instead of e820tables to get memory info in TDVF
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>
2024-09-03 15:55:34 +00:00
Gerd Hoffmann 2069a63a8e OvmfPkg/PlatformInitLib: allow switching to 4-level paging
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>
2024-08-30 22:13:44 +00:00
Anthony PERARD 0b0b7041cc OvmfPkg/OvmfXen: Introduce Xen's ResetSystemLib, to use xen hypercall
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>
2024-08-30 16:55:41 +00:00
Anthony PERARD 6ed258d89d OvmfPkg/XenHypercallLib: Add SchedOp hypercall
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>
2024-08-30 16:55:41 +00:00
Jason Andryuk 0e6f6c715c OvmfPkg/XenHypercallLib: Use direct hypercalls
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>
2024-08-30 16:55:41 +00:00
Ceping Sun 9d5a9940e4 OvmfPkg: Refactor PcdSetNxForStack usage in TDVF
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>
2024-08-30 15:45:40 +00:00
Ceping Sun 383f729ac0 OvmfPkg/PlatformInitLib: Reserve Sec Page Tables in TDVF
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>
2024-08-29 01:53:14 +00:00
Leif Lindholm e2528a5209 OvmfPkg: remove last instances of EFI_D_
Change debug print levels to modern DEBUG_ format.

Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
2024-07-31 08:59:21 +00:00
Alexey Kardashevskiy 2809966189 OvmfPkg: Enable AMD SEV-ES DebugVirtualization
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
2024-07-04 20:39:26 +00:00
Alexey Kardashevskiy 9f06feb5d2 OvmfPkg: Add AMD SEV-ES DebugVirtualization feature support
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/
2024-07-04 20:39:26 +00:00
Gerd Hoffmann ce4c76e46d OvmfPkg/Sec: Setup MTRR early in the boot process.
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 e8aa4c6546 ("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>
2024-06-26 06:04:49 +00:00
Tobin Feldman-Fitzthum 10b4bb8d6d AmdSev: Halt on failed blob allocation
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>
2024-06-25 15:27:42 +00:00
Corvin Köhne ffce430d2b OvmfPkg/BhyvePkg: honor FwCfg when setting the bootorder
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] 6632a0a4e3
[2] 480bef9481

Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
2024-06-18 19:18:07 +00:00
Gerd Hoffmann 90cb1ec332 OvmfPkg/PlatformInitLib: allow PhysBits larger than 48
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>
2024-06-06 09:06:28 +00:00
Gerd Hoffmann 603ad2d6ae OvmfPkg/PlatformInitLib: add support for GuestPhysBits
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>
2024-06-06 09:06:28 +00:00
Chao Li cac1ea6c2a OvmfPkg: Add no hardcode version of FdtNorFlashQemuLib
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>
2024-06-04 22:51:09 +00:00
Sachin Ganesh b82c9631da OvmfPkg: Use newly defined Unaccepted Memory Type
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>
2024-05-08 11:34:49 +00:00
Jiaxin Wu 4a6400b084 OvmfPkg/SmmCpuFeaturesLib: Check Smbase Relocation is done or not
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>
2024-05-08 01:53:58 +00:00
Jiaxin Wu 04c36d5a1b OvmfPkg: Refine SmmAccess implementation
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>
2024-05-08 01:53:58 +00:00
Jiaxin Wu 6a468a8b55 OvmfPkg/PlatformInitLib: Create gEfiSmmSmramMemoryGuid
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>
2024-05-08 01:53:58 +00:00
Jiaxin Wu 3dfd64305b OvmfPkg/SmmRelocationLib: Add library instance for OVMF
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>
2024-05-08 01:53:58 +00:00
Michael Roth fecf55a66a OvmfPkg/CcExitLib: Drop special handling for Encrypted MMIO to APIC
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>
2024-05-02 12:43:50 +00:00
Chao Li ec6e59aefe OvmfPkg: Remove QemuFwCfgLibMmio.inf
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>
2024-04-30 11:10:10 +00:00
Chao Li 3d87214a20 OvmfPkg: Copy the same new INF as QemuFwCfgLibMmio.inf
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>
2024-04-30 11:10:10 +00:00
Chao Li fcce7f77e6 OvmfPkg: Add the QemuFwCfgMmioLib PEI stage version
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>
2024-04-30 11:10:10 +00:00
Chao Li 748d57d40f OvmfPkg: Add the way of HOBs in QemuFwCfgLibMmio
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>
2024-04-30 11:10:10 +00:00
Chao Li 5e31c5666d OvmfPkg: Separate QemuFwCfgLibMmio.c into two files
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>
2024-04-30 11:10:10 +00:00
Adam Dunlap e3fa6986ae OvmfPkg: Harden #VC instruction emulation somewhat (CVE-2024-25742)
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>
2024-04-23 17:29:55 +00:00
Tom Lendacky 0afb874349 OvmfPkg/BaseMemEncryptLib: Check for presence of an SVSM when not at VMPL0
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>
2024-04-17 20:04:41 +00:00
Tom Lendacky 47001ab989 Ovmfpkg/CcExitLib: Provide SVSM discovery support
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>
2024-04-17 20:04:41 +00:00
Tom Lendacky 28fecae8a3 OvmfPkg/AmdSvsmLib: Add support for the SVSM create/delete vCPU calls
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>
2024-04-17 20:04:41 +00:00
Tom Lendacky 18fdffe825 OvmfPkg/BaseMemEncryptSevLib: Maximize Page State Change efficiency
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>
2024-04-17 20:04:41 +00:00
Tom Lendacky b505f11f39 OvmfPkg/AmdSvsmLib: Add support for the SVSM_CORE_PVALIDATE call
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>
2024-04-17 20:04:41 +00:00
Tom Lendacky f6bf37c171 OvmfPkg/BaseMemEncryptSevLib: Use AmdSvsmSnpPvalidate() to validate pages
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>
2024-04-17 20:04:41 +00:00
Tom Lendacky 6ced1e91ef Ovmfpkg/AmdSvsmLib: Create AmdSvsmLib to handle SVSM related services
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>
2024-04-17 18:30:03 +00:00
Tom Lendacky 069f9911a3 OvmfPkg/BaseMemEncryptSevLib: Maximize Page State Change efficiency
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>
2024-04-17 18:30:03 +00:00
Tom Lendacky 2b330b57db OvmfPkg/BaseMemEncryptSevLib: Re-organize page state change support
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>
2024-04-17 18:30:03 +00:00
Tom Lendacky 5fe9db0f82 OvmfPkg/BaseMemEncryptSevLib: Calculate memory size for Page State Change
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>
2024-04-17 18:30:03 +00:00
Tom Lendacky 6b14ef6b28 OvmfPkg/BaseMemEncryptSevLib: Fix uncrustify errors
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>
2024-04-17 18:30:03 +00:00
Tom Lendacky c212fec9cf OvmfPkg/BaseMemEncryptLib: Fix error check from AsmRmpAdjust()
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>
2024-04-17 18:30:03 +00:00
Min M Xu 93ff80a218 OmvfPkg/HashLibTdx: Add HashLibTdx
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>
2024-04-17 03:04:13 +00:00
Ceping Sun a1a6da80aa OvmfPkg/CcExitLib: Update TDVMCALL_EXPOSE_REGS_MASK
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>
2024-03-19 09:42:06 +00:00