summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* MdePkg: MdeLibs.dsc.inc: Apply StackCheckLibNull to All Module TypesOliver Smith-Denny8 days11-25/+0
| | | | | | | | | | | | | | | Now that the ResetVectors are USER_DEFINED modules, they will not be linked against StackCheckLibNull, which were the only modules causing issues. So, we can now remove the kludge we had before and the requirement for every DSC to include StackCheckLibNull for SEC modules and just apply StackCheckLibNull globally. This also changes every DSC to drop the SEC definition of StackCheckLibNull. Continuous-integration-options: PatchCheck.ignore-multi-package Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* OvmfPkg: Make ResetVector USER_DEFINEDOliver Smith-Denny8 days12-12/+12
| | | | | | | | | | Following the change in UefiCpuPkg, this moves OvmfPkg's ResetVectors to USER_DEFINED modules to prevent any NULL libraries from being linked against them, allowing for expected behavior from the ResetVector and for simpler implementation of NULL libraries applied globally. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* OvmfPkg: mark fixed network PCDsAleksandr Goncharov10 days8-8/+8
| | | | | | | | | | | | | | | | Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with dynamic PCDs Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Chao Li <lichao@loongson.cn> Cc: Bibo Mao <maobibo@loongson.cn> Cc: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* OvmfPkg: use NetworkDynamicPcds include fileAleksandr Goncharov10 days7-39/+7
| | | | | | | | | | | | | | | | | | | | Start using the include file in the OvmfPkg package to manage dynamic network-related PCDs. This change removes the manual addition of `PcdIPv4PXESupport` and `PcdIPv6PXESupport` from the DSC file, relying instead on the centralized include file introduced in NetworkPkg. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jianyong Wu <jianyong.wu@arm.com> Cc: Anatol Belski <anbelski@linux.microsoft.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Chao Li <lichao@loongson.cn> Cc: Bibo Mao <maobibo@loongson.cn> Cc: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
* 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: RiscV64: build BaseRiscVFpuLibHeinrich Schuchardt2024-10-041-0/+1
| | | | | | | | | Enable building the BaseRiscVFpuLib library for OvmfPkg to * Enable the FPU and set it to state 'dirty'. * Clear the fcsr CSR. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* OvmfPkg/CpuHotplugSmm: delay SMM exitGerd Hoffmann2024-09-131-0/+5
| | | | | | | | | | | | | Let APs wait until the BSP has completed the register updates to remove the CPU. This makes sure all APs stay in SMM mode until the CPU hot-unplug operation is complete, which in turn makes sure the ACPI lock is released only after the CPU hot-unplug operation is complete. Some background: The CPU hotplug SMI is triggered from an ACPI function which is protected by an ACPI lock. The ACPI function is in the ACPI tables generated by qemu. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Use TdInfo instead of fw_cfg to get cpu count in TDVFCeping Sun2024-09-133-2/+16
| | | | | | | | | | | | | | | | 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/RiscVVirtQemu: Remove non-needed !include lineMike Beaton2024-09-131-1/+0
| | | | | | | | | | RiscVVirt.dsc.inc includes NetworkPkg/NetworkLibs.dsc.inc. However RiscVVirt.dsc.inc is only ever included by RiscVVirtQemu.dsc, which has already included NetworkPkg/Network.dsc.inc, a general include file which brings in all the required includes for Network features at once, including NetworkPkg/NetworkLibs.dsc.inc. Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* OvmfPkg: Add StackCheckLibNullOliver Smith-Denny2024-09-1311-7/+25
| | | | | | | Remove the old stack check lib now that MdeLibs.inc includes the new one. Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
* OvmfPkg: Fix unable to build OVMF with -D NETWORK_ENABLE=0Mike Beaton2024-09-127-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=4829 7f17a15 (2024/02/22) "OvmfPkg: Shell*.inc: allow building without network support" breaks building OVMF with `-D NETWORK_ENABLE=0`. Before this commit we could build OVMF e.g. with the following command in the OvmfPkg directory: ./build.sh -D NETWORK_ENABLE=0 After the commit the same command fails early with: /home/user/OpenSource/edk2/OvmfPkg/OvmfPkgX64.dsc(15): error F001: Pcd (gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections) defined in DSC is not declared in DEC files referenced in INF files in FDF. Arch: ['X64'] The problem applies in Intel OvmfPkg platforms. Additionally, it applies in various other OvmfPkg platforms, but is masked buy another issue; namely that these platforms incorrectly still include some network packages when most are disabled. (A fix for that issue has previously been made, in OvmfPkg Intel platforms only, by d933ec1 followed by 7f17a15 .) This commit conditionally removes the undefined Pcd references in all OvmfPkg platforms which are now affected by this issue, and in all those which would be affected as and when the other issue mentioned above is fixed. Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
* OvmfPkg/LoongArchVirt: Modify loongarch uefi firmware sizeXianglai Li2024-09-121-11/+1
| | | | | | | | | | | | | | | | | | | | After the loongarch flash block size is changed from 128K to 256K, qemu requires that the UEFI firmware size be aligned with the flash block size(256K). Otherwise, the firmware cannot be loaded, Use the following code to resolve the old firmware loading problem: mv QEMU_EFI.fd QEMU_EFI.fd-bak cat QEMU_EFI.fd-bak /dev/zero | head -c 16m > ./QEMU_EFI.fd mv QEMU_VARS.fd QEMU_VARS.fd-bak cat QEMU_VARS.fd-bak /dev/zero | head -c 16m > ./QEMU_VARS.fd For the new firmware, we refer to other architecture UEFI and set the UEFI firmware size to align with the flash block size(256K). So for this patch, we set the UEFI firmware size to 256K alignment. Cc: Bibo Mao <maobibo@loongson.cn> Cc: Chao Li <lichao@loongson.cn> Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
* 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/PlatformPei: Build gCcEventEntryHobGuid at FirstCeping Sun2024-09-034-4/+13
| | | | | | | | | | | | | Since the PEI Hob service is ready after PEIM loaded, TDVF should build the Hob for TdHob and Cfv event at first. 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: Move kernel hashes section to endDionna Glaze2024-08-311-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | When launching a SEV-SNP VM, the ROM is not all that must be measured. The OvmfSevMetadata sections describe ranges of memory that must be measured with different types than PAGE_TYPE_NORMAL, except one. The SevSnpKernelHashes page is also PAGE_TYPE_NORMAL, but is populated by the VMM from configuration data that is separate from the OVMF build itself. To more compactly provide reference values for the measurement of the firmware separately from the kernel hashes, it's advantageous to measure as much known information as possible first. Whereas VMMs are permitted to measure these sections in any order they prefer, the normative order of how they appear in the .fd is easiest to follow. This change is semantics-preserving. Measurement calculation tools that do not follow the normative ordering would need updating to accommodate, but I don't know of any. The accounting for EC2 moving the CPUID page to the end of measurement would be unchanged. This change is to improve performance of a proposed launch update event log to separate responsibility for initially measured data before VM launch, application/vnd.amd.sevsnp.launch-updates+cbor: https://github.com/deeglaze/draft-deeglaze-amd-sev-snp-corim-profile Signed-off-by: Dionna Glaze <dionnaglaze@google.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: Using the new name of LoongArch CSR 0x20 registerChao Li2024-08-301-1/+1
| | | | | | | | | | Since the LoongArch SPEC has adjusted the CSR 0x20 register name and the MdePkg also added the new name, so enable it in OvmfPkg. 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/OvmfXen: Introduce Xen's ResetSystemLib, to use xen hypercallAnthony PERARD2024-08-305-5/+234
| | | | | | | | | | | | 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-304-1/+73
| | | | | | | | | | | | | | | 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/XenPlatformPei: Remove Hypercall PageJason Andryuk2024-08-302-26/+1
| | | | | | | | | | XenHypercallLib now makes direct hypercalls, so HyperPages is unnecessary and can be removed. Change the XenPvhDetected() ASSERT to use the Xen version. That has never been 0, AFAIK. 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-303-3/+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/QemuVideoDxe: ignore display resolutions smaller than 640x480Gerd Hoffmann2024-08-301-4/+14
| | | | | | GraphicsConsoleDxe will assert in case the resolution is too small. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/VirtioGpuDxe: ignore display resolutions smaller than 640x480Gerd Hoffmann2024-08-301-1/+2
| | | | | | GraphicsConsoleDxe will assert in case the resolution is too small. Signed-off-by: Gerd Hoffmann <kraxel@redhat.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/LoongArchVirt: Clear the PGD series registersChao Li2024-08-281-0/+6
| | | | | | | | | | | | Since the PGD series registers are in an unknown state when reset, some simulators will hang when restarting if these registers are not cleared, so they are cleared in this patch. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Chao Li <lichao@loongson.cn>
* OvmfPkg/TdTcg2Dxe: Fix the SeparatorEvent issue in RTMRsMin M Xu2024-08-271-3/+9
| | | | | | | | | | | | | | | | | | | | According to the TCG EFI platform specification, the firmware must measure the EV_SEPARATOR event into PCRs 0-7. As PCR[1] and PCR[7] map to RTMR[0], and PCRs [2-6] map to RTMR[1], it is necessary to measure one EV_SEPARATOR event into RTMR[0] and another one into RTMR[1]. An issue is found in TdTcg2Dxe that 2 EV_SEPARATOR events are measured to RTMR[0] but no EV_SEPARATOR event is measured to RTMR[1]. This patch fixes the above issue. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Qinkun Bao <qinkun@google.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg: Pass correct virtio-scsi request sizeSami Mujawar2024-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch at "1fc55a3933b0 OvmfPkg: Use heap memory for virtio-scsi request" modified the virtio-scsi request header memory to be allocated from the heap. In doing so the request structure header which was a local variable on the stack was converted to be a pointer. This required adjusting the size computation for the request header to reflect that the structure was changed to a pointer. Unfortunately, this was missed out in the call to VirtioAppendDesc() for enqueuing the request due to which only 8 bytes were being shared with the host instead of the size of the VIRTIO_SCSI_REQ structure which is 51 bytes. This resulted in the following error message to be printed by qemu: "qemu-system-<arch>: wrong size for virtio-scsi headers" and the virtio-scsi functionality degraded. Therefore, pass the correct size of the virtio-scsi request header when enqueuing the request. Reported-by: Aithal Srikanth <sraithal@amd.com> Tested-by: Aithal Srikanth <sraithal@amd.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
* OvmfPkg: Use heap memory for virtio-scsi requestSami Mujawar2024-07-311-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The storage space for virtio-scsi request header being shared with the host was from the stack as the request structure was a local function variable. A bug in the VMM can corrupt the stack space, and such issues can be very hard to debug. Note: This is only an issue with a normal guest VM (non-CCA). A CCA guest VM would perform bounce buffering for sharing the data and therefore not have this issue. Instead of using the stack for sharing the data with the host, memory can be allocated from the heap pool. However, pool allocations are not any safer in terms of pages being shared between different allocations, and so mapping a pool allocation for DMA may expose it to potential corruption by the VMM in exactly the same way. The only difference is the potential impact on program behaviour, which is much higher with the stack. Additionally, for guest-side corruption heap allocations can take advantage by turning on heap guard to help find the bug. Therefore, minor improvement can be achieved by allocating memory for the virtio-scsi request header from the heap for sharing with the host. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
* OvmfPkg: Use heap memory for virtio-blk requestSami Mujawar2024-07-311-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The storage space for virtio-blk request header being shared with the host was from the stack as the request structure was a local function variable. A bug in the VMM can corrupt the stack space, and such issues can be very hard to debug. Note: This is only an issue with a normal guest VM (non-CCA). A CCA guest VM would perform bounce buffering for sharing the data and therefore not have this issue. Instead of using the stack for sharing the data with the host, memory can be allocated from the heap pool. However, pool allocations are not any safer in terms of pages being shared between different allocations, and so mapping a pool allocation for DMA may expose it to potential corruption by the VMM in exactly the same way. The only difference is the potential impact on program behaviour, which is much higher with the stack. Additionally, for guest-side corruption heap allocations can take advantage by turning on heap guard to help find the bug. Therefore, minor improvement can be achieved by allocating memory for the virtio-blk request header from the heap for sharing with the host. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
* OvmfPkg/LoongArchVirtQemu: Drop bogus references to EfiResetSystemLibArd Biesheuvel2024-07-311-2/+0
| | | | | | | | These libraries do not implement EfiResetSystemLib to begin with, and this library class is going to be dropped. So drop these bogus references first. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: remove last instances of EFI_D_Leif Lindholm2024-07-312-2/+2
| | | | | | Change debug print levels to modern DEBUG_ format. Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
* OvmfPkg: Add network support for LoongArch QEMU platformChao Li2024-07-152-6/+6
| | | | | | | | | | Open the network option to enable networking on the LoongArch QEMU platform. 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/RiscVVirt: Configure zkr PCD for VirtDhaval2024-07-151-1/+1
| | | | | | | | | | | | | | Keep ZKR feature disabled by default until HW supports it. Feature is implemented in RISC-V BaseRngLib. Cc: Andrei Warkentin <andrei.warkentin@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com> Co-authored-by: Tim Wawrzynczak <tim@rivosinc.com>
* OvmfPkg: Fix the wild pointer in Fdt16550SerialProtHookLibChao Li2024-07-121-3/+3
| | | | | | | | | | There was a wild pointer in Fdt16550SerialProtHookLib which pointed to an unknown space, which was very wrong and has been fixed. 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/OvmfPkgX64: Set default value of CC_MEASUREMENT_ENABLE to TRUEMin M Xu2024-07-122-3/+3
| | | | | | | | | | | | | | | | | | | | | CC_MEASUREMENT_ENABLE is designed to control the loading of TdTcg2Dxe driver which is for EFI_CC_MEASUREMENT_PROTOCOL. TdTcg2Dxe is TD-Guest specific driver. From the security perspective a TD-Guest shall always load the TdTcg2Dxe driver so that EFI_CC_MEASUREMENT_PROTOCOL is installed and booting events are measured and extended to RTMRs. TdTcg2Dxe will check if it is running in a TD-Guest. If not then it returns right now and no EFI_CC_MEASUREMENT_PROTOCOL is installed. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
* OvmfPkg/Sec: Skip setup MTRR early in TD-GuestCeping Sun2024-07-112-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the commit ce4c76e (“OvmfPkg/Sec: Setup MTRR early in the boot process.”), we find an unexpected #VE is triggered in TD-Guest. The background of importing the above commit is that: Before running lzma uncompress of the main firmware volume, if not correctly set MTRR, that would make the uncompress be extremely slow. Detailed discussion info can refer to below links: https://edk2.groups.io/g/devel/message/114202 https://edk2.groups.io/g/devel/message/114977 Refer to [intel-tdx-module-1.5-base-spec] Section 11.3 and section11.6.1, CR0.CD is enforced to 0 in TD-Guest. And refer to section 18.2.1.4, TDX module MTRR emulation enforces WB in VMM. Currently the initial MTRR are: - Td-Guest : MTRR disabled, Type is WB. - Non-Td-Guest : MTRR disabled, Type is UC. In DXE phase, OVMF/TDVF would check the MTRR Type for MMIO (in CpuSetMemoryAttributes -> MtrrGetMemoryAttribute -> MtrrGetMemoryAttributeworker: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MtrrLib/MtrrLib.c#L929 ). If MTRR is disabled, it always returns UC. Otherwise, it returns the actual value. If it checks that the type is not UC then the MTRR is programmed. It is required to disable cache by setting CR0.CD to 1. That will trigger an unexpected #VE in TD-Guest. Based on above analysis we propose to skip "Setup MTRR early" in TD-Guest because of: - TD-Guest doesn’t have the issue that lzma uncompress extremely slow. - This patch will trigger an unexpected #VE in TD-Guest. intel-tdx-module-1.5-base-spec: https://cdrdv2.intel.com/v1/dl/getContent/733575 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/LoongArchVirt: Optimize the use of serial port librariesXianglai Li2024-07-051-11/+1
| | | | | | | | | | | | | | | | Because the complex dependency between SerialPortLib and PciExpressLib leads to multiple references to the lib library in the loongarch dsc file, optimizing SerialPortLib now simplifies multiple references to lib in the dsc file. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Bibo Mao <maobibo@loongson.cn> Cc: Chao Li <lichao@loongson.cn> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Xianglai Li <lixianglai@loongson.cn> Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
* OvmfPkg: Enable AMD SEV-ES DebugVirtualizationAlexey Kardashevskiy2024-07-043-5/+20
| | | | | | | | | | | | | | | | | | | | | 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-045-3/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/
* AmdSev: enable kernel hashes without initrdTobin Feldman-Fitzthum2024-07-041-10/+0
| | | | | | | | | | | | | | If kernel hashes are enabled but no initrd is provided, QEMU will still create an entry in the hash table, but it will be the hash of an empty buffer. Remove the explicit check for the length of the blob. This logic will be handled by the later hash comparison, which will still fail when the blob is not present but is expected, but will pass when the blob is not present and the hash table contains a hash of an empty buffer. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
* OvmfPkg: Create SP800155 HOBs from QemuFwCfgFileDionna Glaze2024-07-024-1/+155
| | | | | | | | | | | | | | | | | | | | | Signed firmware measurements are allowed to be passed along to in the TCG and CC event logs according to the TCG PC Client Platform Firware Profile. The event logs include events that Tcg2Dxe reads from appropriately GUIDed HOBs, so allow opt/org.tianocode/sp800155evt/%d to pass along events that the VMM sees fit to provide. One event per number, starting from 0, increasing by 1 until there are no more contiguous files. The VMM may provide reference measurements through UEFI variables that it references from the SP800-155 event3 structure given the appropriate RIM locator type, or via URL, etc. Each event read from fw_cfg, is written one-by-one to a EFI_HOB_GUID_TYPE HOB created for the event. The name they target gTcg800155PlatformIdEventHobGuid for the later Dxe driver to use to extend the event log. Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
* OvmfPkg/Sec: use cache type #defines from ArchitecturalMsr.hGerd Hoffmann2024-06-262-2/+2
| | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Sec: Setup MTRR early in the boot process.Gerd Hoffmann2024-06-264-10/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-254-15/+35
| | | | | | | | | | | | 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>
* AmdSev: Rework Blob VerifierTobin Feldman-Fitzthum2024-06-251-7/+28
| | | | | | | | | | | | | | | | | | | | | | | The Blob Verifier checks boot artifacts against a hash table injected by the hypervisor and measured by hardware. Update the Blob Verifier to enter a dead loop if the artifacts do not match. The verifier still returns ACCESS_DENIED in some cases, but this is considered non-fatal. These non-fatal cases occur when the artifact cannot be verified because the hashes table makes no claims about the artifiact (e.g. if the hashes table is not present or if there is no entry for the blob in question). Since the hash table is reflected in the launch measurement, it is okay to continue the boot in these cases. If the hash table does contain expected hash values, the boot cannot continue if the provided blobs do not match. In these cases we enter a dead loop to make sure no guest can boot with a TCB that does not reflect the launch measurement. Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
* OvmfPkg: refine TdTcg2DxeMike Maslenkin2024-06-212-5/+1
| | | | | | | This patch removes unused references to ResetNotification code. ACPI table generation refined by removing excessive CopyMem() call. Signed-off-by: Mike Maslenkin <mike.maslenkin@gmail.com>
* OvmfPkg/QemuVideoDxe: add feature PCD to remap framebuffer W/CArd Biesheuvel2024-06-184-1/+29
| | | | | | | | | | | | | | | | | | | | | | Some platforms (such as SBSA-QEMU on recent builds of the emulator) only tolerate misaligned accesses to normal memory, and raise alignment faults on such accesses to device memory, which is the default for PCIe MMIO BARs. When emulating a PCIe graphics controller, the framebuffer is typically exposed via a MMIO BAR, while the disposition of the region is closer to memory (no side effects on reads or writes, except for the changing picture on the screen; direct random access to any pixel in the image). In order to permit the use of such controllers on platforms that only tolerate these types of accesses for normal memory, it is necessary to remap the memory. Use the DXE services to set the desired capabilities and attributes. Hide this behavior under a feature PCD so only platforms that really need it can enable it. (OVMF on x86 has no need for this) Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/BhyvePkg: honor FwCfg when setting the bootorderCorvin Köhne2024-06-183-6/+13
| | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-21 15:46:37 +0000