summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/QemuBootOrderLib: skip unsupported entries in StoreQemuBootOrderGerd Hoffmann2022-09-281-26/+30
| | | | | | | | When finding an unsupported entry just skip over and continue with the next entry instead of stop processing altogether. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/QemuBootOrderLib: allow slash in rom filenamesGerd Hoffmann2022-09-281-1/+18
| | | | | | | | See comment for details. Needed to avoid the parser abort, so we can continue parsing the bootorder fw_cfg file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformInitLib: q35 mtrr setup fixGerd Hoffmann2022-09-281-8/+18
| | | | | | | | | | | | | | | | | Traditional q35 memory layout is 2.75 GB of low memory, leaving room for the pcie mmconfig at 0xb0000000 and the 32-bit pci mmio window at 0xc0000000. Because of that OVMF tags the memory range above 0xb0000000 as uncachable via mtrr. A while ago qemu started to gigabyte-align memory by default (to make huge pages more effective) and q35 uses only 2G of low memory in that case. Which effectively makes the 32-bit pci mmio window start at 0x80000000. This patch updates the mtrr setup code accordingly. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PeilessStartupLib: move mPageTablePool to stackMin M Xu2022-09-281-49/+68
| | | | | | | | | | | | | PeilessStartupLib is running in SEC phase. In this phase global variable is not allowed to be modified. This patch moves mPageTablePool to stack and pass it as input parameter between functions. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Allow runtime control of IPv4 and IPv6 support on QEMUArd Biesheuvel2022-09-101-0/+18
| | | | | | | | | | | | | | Wire up the newly added UefiDriverEntrypoint in a way that ties dispatch of the Ip4Dxe and Ip6Dxe drivers to QEMU fw_cfg variables 'opt/org.tianocore/IPv4Support' and 'opt/org.tianocore/IPv6Support' respectively. Setting both variables to 'n' disables IP based networking entirely, without the need for additional code changes at the NIC driver or network boot protocol level. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: gather common NetworkComponents overrides in .dsc.inc fileArd Biesheuvel2022-09-106-55/+22
| | | | | | | | | | | | All QEMU based OVMF platforms override the same set of network components, to specify NULL library class resolutions that modify the behavior of those components in a QEMU specific way. Before adding more occurrences of that, let's drop those definitions in a common include file. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Introduce alternate UefiDriverEntrypoint to inhibit driver loadArd Biesheuvel2022-09-103-0/+209
| | | | | | | | | | | | | | | | | Add a new library that can be incorporated into any driver built from source, and which permits loading of the driver to be inhibited based on the value of a QEMU fw_cfg boolean variable. This will be used in a subsequent patch to allow dispatch of the IPv4 and IPv6 network protocol driver to be controlled from the QEMU command line. This approach is based on the notion that all UEFI and DXE drivers share a single UefiDriverEntryPoint implementation, which we can easily swap out at build time with one that will abort execution based on the value of some QEMU fw_cfg variable. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/LegacyBootManagerLib: Fix debug macro argumentsMichael Kubacki2022-09-091-3/+3
| | | | | | | | | | | | | | | | The DEBUG macro updated in this patch previously contained 11 print specifiers in the debug string but passeed 13 arguments. This change attempts to update the macro to the author's intention so the number of specifiers match the number of arguments. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Update I/O port related to ACPI devices for CloudHvSebastien Boeuf2022-09-081-2/+2
| | | | | | | | | | Both ACPI shutdown and ACPI PM timer devices has been moved to different port addresses in the latest version of Cloud Hypervisor. These changes need to be reflected on the OVMF firmware. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/QemuVideoDxe: fix bochs mode initGerd Hoffmann2022-09-071-1/+33
| | | | | | | | | | | | | | | Add VgaInb() helper function to read vga registers. With that in place fix the unblanking. We need to put the ATT_ADDRESS_REGISTER flip flop into a known state, which is done by reading the INPUT_STATUS_1_REGISTER. Reading the INPUT_STATUS_1_REGISTER only works when the device is in color mode, so make sure that bit (0x01) is set in MISC_OUTPUT_REGISTER. Currently the mode setting works more by luck because ATT_ADDRESS_REGISTER flip flop happens to be in the state we need. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/QemuBootOrderLib: add StoreQemuBootOrder()Gerd Hoffmann2022-09-065-0/+143
| | | | | | | | | | | | The function reads the boot order from qemu fw_cfg, translates it into device paths and stores them in 'QemuBootOrderNNNN' variables. In case there is no boot ordering configured the function will do nothing. Use case: Allow applications loaded via 'qemu -kernel bootloader.efi' obey the boot order. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/OvmfPkg*.dsc: Increase ACPI Reclaim memory sizeannie li2022-09-063-3/+3
| | | | | | | | | | | | | | | | | | | | | | The current ACPI Reclaim memory size is set as 0x10 (64KiB). The ACPI table size will be increased if the memory slots' number of the guest gets increased. In the guest with more memory slots, the ACPI Reclaim memory size may not be sufficient for hibernation. This may cause resume failure of the hibernated guest that was booted up with a fresh copied writable OVMF_VARS file. However, the failure doesn't happen in following hibernation/resume cycles. The ACPI_MAX_RAM_SLOTS is set as 256 in the current QEMU. With ACPI_MAX_RAM_SLOTS, 18 pages are required to be allocated in ACPI Reclaim memory. However, due to the 0x10 (16 pages) setting, 2 extra pages will be allocated in other space. This may break the hibernation/resume in the above scenario. This patch increases the ACPI Reclaim memory size to 0x12, i.e. PcdMemoryTypeEfiACPIReclaimMemory is set as 0x12 (18 pages). Signed-off-by: Annie Li <annie.li@oracle.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/IncompatiblePciDeviceSupportDxe: Ignore OptionRom in Sev guestLee, Chun-Yi2022-09-062-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Reference: https://bugzilla.tianocore.org/show_bug.cgi?id=4031 This patch is similar to the c477b2783f patch for Td guest. Host VMM may inject OptionRom which is untrusted in Sev guest. So PCI OptionRom needs to be ignored if it is Sev guest. According to "Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage" PI spec 1.7, type-specific flags can be set to 0 when Address Translation Offset == 6 to skip device option ROM. Without this patch, Sev guest may shows invalid MMIO opcode error as following: Invalid MMIO opcode (F6) ASSERT /home/abuild/rpmbuild/BUILD/edk2-edk2-stable202202/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c(1041): ((BOOLEAN)(0==1)) The OptionRom must be disabled both on Td and Sev guests, so we direct use CcProbe(). Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Add build-flag SECURE_BOOT_FEATURE_ENABLEDMin M Xu2022-09-065-0/+45
| | | | | | | | | | | | | | | | | | | | | | | SECURE_BOOT_FEATURE_ENABLED is the build-flag defined when secure boot is enabled. Currently this flag is used in below lib: - OvmfPkg/PlatformPei - PeilessStartupLib So it is defined in below 5 .dsc - OvmfPkg/CloudHv/CloudHvX64.dsc - OvmfPkg/IntelTdx/IntelTdxX64.dsc - OvmfPkg/OvmfPkgIa32.dsc - OvmfPkg/OvmfPkgIa32X64.dsc - OvmfPkg/OvmfPkgX64.dsc Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/TdxDxe: Set PcdEmuVariableNvStoreReservedMin M Xu2022-09-062-0/+3
| | | | | | | | | | | | | | Set PcdEmuVariableNvStoreReserved with the value in PlatformInfoHob. It is the address of the EmuVariableNvStore reserved in Pei-less startup. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/NvVarsFileLib: Shortcut ConnectNvVarsToFileSystem in secure-bootMin M Xu2022-09-061-0/+7
| | | | | | | | | | | | | | | | | OvmfPkg/Library/NvVarsFileLib allows loading variables into emulated varstore from a on-disk NvVars file. We can't allow that when secure boot is active. So check secure-boot feature and shortcut the ConnectNvVarsToFileSystem() function when sb is enabled. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Reserve and init EmuVariableNvStore in Pei-less StartupMin M Xu2022-09-061-0/+7
| | | | | | | | | | | | | | | | | | | | | EmuVariableNvStore is reserved and init with below 2 functions defined in PlatformInitLib: - PlatformReserveEmuVariableNvStore - PlatformInitEmuVariableNvStore PlatformInitEmuVariableNvStore works when secure boot feature is enabled. This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc) and EmuVariableNvStore is cleared when OVMF is launched with -bios parameter. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/PlatformPei: Update ReserveEmuVariableNvStoreMin M Xu2022-09-061-18/+7
| | | | | | | | | | | | | | | | | | | | | ReserveEmuVariableNvStore is updated with below 2 functions defined in PlatformInitLib: - PlatformReserveEmuVariableNvStore - PlatformInitEmuVariableNvStore PlatformInitEmuVariableNvStore works when secure boot feature is enabled. This is because secure boot needs the EFI variables (PK/KEK/DB/DBX, etc) and EmuVariableNvStore is cleared when OVMF is launched with -bios parameter. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/PlatformInitLib: Add functions for EmuVariableNvStoreMin M Xu2022-09-063-0/+292
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are 3 functions added for EmuVariableNvStore: - PlatformReserveEmuVariableNvStore - PlatformInitEmuVariableNvStore - PlatformValidateNvVarStore PlatformReserveEmuVariableNvStore allocate storage for NV variables early on so it will be at a consistent address. PlatformInitEmuVariableNvStore copies the content in PcdOvmfFlashNvStorageVariableBase to the storage allocated by PlatformReserveEmuVariableNvStore. This is used in the case that OVMF is launched with -bios parameter. Because in that situation UEFI variables will be partially emulated, and non-volatile variables may lose their contents after a reboot. This makes the secure boot feature not working. PlatformValidateNvVarStore is renamed from TdxValidateCfv and it is used to validate the integrity of FlashNvVarStore (PcdOvmfFlashNvStorageVariableBase). It should be called before PlatformInitEmuVariableNvStore is called to copy over the content. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/PeilessStartupLib: Delete TdxValidateCfvMin M Xu2022-09-063-178/+0
| | | | | | | | | | | | | | | | | | TdxValidateCfv is used to validate the integrity of FlashNvVarStore (PcdOvmfFlashNvStorageVariableBase) and it is not Tdx specific. So it will be moved to PlatformInitLib and be renamed to PlatformValidateNvVarStore in the following patch. And it will be called before EmuVaribleNvStore is initialized with the content in FlashNvVarStore. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Set default Pci PCDs in Tdx guestMin M Xu2022-09-061-13/+13
| | | | | | | | | | | | | | | | | | | | | | In previous implementation below Pci related PCDs were set based on the ResourceDescriptor passed in TdHob. - PcdPciMmio64Base / PcdPciMmio64Size - PcdPciMmio32Base / PcdPciMmio32Size - PcdPciIoBase / PcdPciIoSize The PCDs will not be set if TdHob doesn't include these information. This patch set the PCDs with the information initialized in PlatformInitLib by default. Then TdxDxe will check the ResourceDescriptor in TdHob and reset them if they're included. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Update CcProbeLib to DxeCcProbeLibMin M Xu2022-09-065-36/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974 CcProbeLib once was designed to probe the Confidential Computing guest type by checking the PcdOvmfWorkArea. But this memory is allocated with either EfiACPIMemoryNVS or EfiBootServicesData. It cannot be accessed after ExitBootService. Please see the detailed analysis in BZ#3974. To fix this issue, CcProbeLib is redesigned as 2 implementation: - SecPeiCcProbeLib - DxeCcProbeLib In SecPeiCcProbeLib we check the CC guest type by reading the PcdOvmfWorkArea. Because it is used in SEC / PEI and we don't worry about the issues in BZ#3974. In DxeCcProbeLib we cache the GuestType in Ovmf work area in a variable. After that the Guest type is returned with the cached value. So that we don't need to worry about the access to Ovmf work area after ExitBootService. The reason why we probe CC guest type in 2 different ways is the global varialbe. Global variable cannot be used in SEC/PEI and CcProbe is called very frequently. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Add SecPeiCcProbeLibMin M Xu2022-09-062-0/+56
| | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974 SecPeiCcProbeLib is designed to probe the Confidential Computing guest type in SEC/PEI phase. The CC guest type was set by each CC guest at the beginning of boot up and saved in PcdOvmfWorkArea. Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: increase max debug message length to 512Laszlo Ersek2022-09-051-1/+1
| | | | | | | | | | | | Increase the maximum line length for debug messages. While log messages should be short, they can still get quite long, for example when printing device paths or config strings in HII routing. 512 chars is an empirically good value. Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Oliver Steffen <osteffen@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/BhyvePkg: use correct PlatformSecureLibCorvin Köhne2022-09-051-1/+1
| | | | | | | | There's no bhyve specific PlatformSecureLib any more. Use the default one of OvmfPkg which works too. Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com> Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
* OvmfPkg: Remove duplicated wordsPierre Gondois2022-09-0511-15/+15
| | | | | | | | In an effort to clean the documentation of the above package, remove duplicated words. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* OvmfPkg/PlatformDxe: Handle all requests in ExtractConfig and RouteConfigDimitrije Pavlov2022-09-053-3/+116
| | | | | | | | | | | | | | | | | | | | | | | Per the UEFI specification, if the Request argument in EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() is NULL or does not contain any request elements, the implementation should return all of the settings being abstracted for the particular ConfigHdr reference. The current implementation returns EFI_INVALID_PARAMETER if Request is NULL or does not contain any request elements. Instead, construct a new ConfigRequest to handle these cases per the specification. In addition, per the UEFI specification, if the Configuration argument in EFI_HII_CONFIG_ACCESS_PROTOCOL.RouteConfig() has a ConfigHdr that specifies a non-existing target, the implementation should return EFI_NOT_FOUND. The current implementation returns EFI_INVALID_PARAMETER if Configuration has a non-existing target in ConfigHdr. Instead, perform a check and return EFI_NOT_FOUND in this case. Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformDxe: Check RouteConfig arguments for spec complianceYuan Yu2022-09-051-1/+1
| | | | | | | | | | | | Per UEFI Spec 2.9, EFI_HII_CONFIG_ROUTING_PROTOCOL.RouteConfig() should return EFI_INVALID_PARAMETER if caller passes in a NULL for the Configuration parameter (see 35.4 EFI HII Configuration Routing Protocol). Add a check to return EFI_INVALID_PARAMETER when Configuration is NULL. Signed-off-by: Yuan Yu <yuanyu@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Add BUILD_SHELL flag for IA32, IA32X64, X64Oliver Steffen2022-09-056-6/+42
| | | | | | | | | | | | | | | | | Add BUILD_SHELL flag, similar to the one in OvmfPkg/AmdSev, to enable/disable building of the UefiShell as part of the firmware image. The UefiShell should not be included for secure production systems (e.g. SecureBoot) because it can be used to circumvent security features. The default value for BUILD_SHELL is TRUE to keep the default behavior of the Ovmf build. Note: the default for AmdSev is FALSE. The BUILD_SHELL flag for AmdSev was introduced in b261a30c900a8. Signed-off-by: Oliver Steffen <osteffen@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/VirtioFsDxe: Check GetDriverName argumentsDimitrije Pavlov2022-08-161-0/+4
| | | | | | | | | | | The current implementation does not check if Language or DriverName are NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are NULL. Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com> Reviewed-by: Sunny Wang <sunny.wang@arm.com>
* OvmfPkg/VirtioGpuDxe: Check QueryMode argumentsDimitrije Pavlov2022-08-161-1/+4
| | | | | | | | | | | The current implementation does not check if Info or SizeInfo pointers are NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are NULL. Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com> Reviewed-by: Sunny Wang <sunny.wang@arm.com>
* OvmfPkg/PlatformDxe: Check ExtractConfig and RouteConfig argumentsDimitrije Pavlov2022-08-161-0/+8
| | | | | | | | | | | | The current implementation does not check if Progress or Results pointers in ExtractConfig are NULL, or if Progress pointer in RouteConfig is NULL. This causes the SCT test suite to crash. Add a check to return EFI_INVALID_PARAMETER if any of these pointers are NULL. Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com> Reviewed-by: Sunny Wang <sunny.wang@arm.com>
* OvmfPkg/QemuVideoDxe: Zero out PixelInformation in QueryModeDimitrije Pavlov2022-08-011-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Ensure that the PixelInformation field of the EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is zeroed out in EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() and EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() when PixelFormat is PixelBlueGreenRedReserved8BitPerColor. According to UEFI 2.9 Section 12.9, PixelInformation field of the EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is valid only if PixelFormat is PixelBitMask. This means that firmware is not required to fill out the PixelInformation field for other PixelFormat types, which implies that the QemuVideoDxe implementation is technically correct. However, not zeroing out those fields will leak the contents of the memory returned by the memory allocator, so it is better to explicitly set them to zero. In addition, the SCT test suite relies on PixelInformation always having a consistent value, which causes failures. Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/XenHypercallLib: Fix naming of AArch64Anthony PERARD2022-07-282-1/+1
| | | | | | | | | | Fix path to follow naming convention of "AArch64", and allow the path in "Maintainers.txt" to work as expected. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3982 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Change default to disable MptScsi and PvScsiMichael D Kinney2022-07-287-14/+14
| | | | | | | | | | | | | | | | | | | | | | The email addresses for the reviewers of the MptScsi and PvScsi are no longer valid. Disable the MptScsi and PvScsi drivers in all DSC files until new maintainers/reviewers can be identified. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Pipeline: Resolve SecureBootVariableLib dependencyKun Qin2022-07-076-0/+6
| | | | | | | | | | | | | | | | | | | | The new changes in SecureBootVariableLib brought in a new dependency of PlatformPKProtectionLib. This change added the new library instance from SecurityPkg to resolve pipeline builds. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Kun Qin <kuqin12@gmail.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
* OvmfPkg/PlatformCI: add IntelTdxBuild.pyMin Xu2022-07-012-0/+48
| | | | | | | | | | | | | | Add build test for OvmfPkg/IntelTdx Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <Jiewen.yao@intel.com> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Min Xu <min.m.xu@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
* Ovmf: Include HardwareInfoLib library classes for IntelTdxNicolas Ojeda Leon2022-06-241-0/+2
| | | | | | | | | | | Include HardwareInfoLib classes in the IntelTdxX64.dsc for this platform to use it during build given that PciHostBridgeUtilityLib depends on it. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* OvmfPkg/PciHostBridgeUtilityLib: Initialize RootBridges apertures with specNicolas Ojeda Leon2022-06-222-5/+328
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consume the host-provided specification of PCI host bridges if available. Using the DxeHardwareInfoLib, populate a list of hardware descriptors based on the content of the "hardware-info" fw-cfg file, if provided. In the affirmative case, use the resources and attributes specified by the hypervisor for each Host Bridge to create the RootBridge elements. In Ovmf platforms, the host can provide the specification of non-discoverable hardware resources like PCI host bridges. If the proper fw-cfg file is found, parse the contents provided by the host into a linked list by using the Hardware Info library. Then, using the list of PCI host bridges' descriptions, populate the PCI_ROOT_BRIDGES array with the resources and attributes specified by the host. If the file is not provided or no Host Bridge is found in it, fold back to the legacy method based on pre-defined apertures and rules. In some use cases, the host requires additional control over the hardware resources' configurations in the guest for performance and discoverability reasons. For instance, to disclose information about the PCI hierarchy to the guest so that this can profit from optimized accesses. In this case, the host can decide to describe multiple PCI Host Bridges and provide a specific set of resources (e.g. MMIO apertures) so that the guest uses the values provided. Using the provided values may entitle the guest to added performance, for example by using specific MMIO mappings that can enable peer-to-peer communication across the PCI hierarchy or by allocating memory closer to a device for faster DMA transactions. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* Ovmf/PlatformPei: Use host-provided GPA end if availableNicolas Ojeda Leon2022-06-222-7/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Read the "hardware-info" item from fw-cfg to extract specifications of PCI host bridges and analyze the 64-bit apertures of them to find out the highest 64-bit MMIO address required which determines the address space required by the guest, and, consequently, the FirstNonAddress used to calculate size of physical addresses. Using the static PeiHardwareInfoLib, read the fw-cfg file of hardware information to extract, one by one, all the host bridges. Find the last 64-bit MMIO address of each host bridge, using the HardwareInfoPciHostBridgeLib API, and compare it to an accumulate value to discover the highest address used, which corresponds to the highest value that must be included in the guest's physical address space. Given that platforms with multiple host bridges may provide the PCI apertures' addresses, the memory detection logic must take into account that, if the host provided the MMIO windows that can and must be used, the guest needs to take those values. Therefore, if the MMIO windows are found in the host-provided fw-cfg file, skip all the logic calculating the physical address size and just use the value provided. Since each PCI host bridge corresponds to an element in the information provided by the host, each of these must be analyzed looking for the highest address used. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* Ovmf/HardwareInfoLib: Add Dxe lib to dynamically parse heterogenous dataNicolas Ojeda Leon2022-06-2210-0/+301
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the Hardware Info library, create the DxeHardwareInfoLib which implements the whole API capable of parsing heterogeneous hardware information. The list-like API grants callers a flexible and common pattern to retrieve the data. Moreover, the initial source is a BLOB which generalizes the host-to-guest transmission mechanism. The Hardware Info library main objective is to provide a way to describe non-discoverable hardware so that the host can share the available resources with the guest in Ovmf platforms. This change features and embraces the main idea behind the library by providing an API that parses a BLOB into a linked list to retrieve hardware data from any source. Additionally, list-like APIs are provided so that the hardware info list can be traversed conveniently. Similarly, the capability is provided to filter results by specific hardware types. However, heterogeneous elements can be added to the list, increasing the flexibility. This way, a single source, for example a fw-cfg file, can be used to describe several instances of multiple types of hardware. This part of the Hardware Info library makes use of dynamic memory and is intended for stages in which memory services are available. A motivation example is the PciHostBridgeLib. This library, part of the PCI driver populates the list of PCI root bridges during DXE stage for future steps to discover the resources under them. The hardware info library can be used to obtain the detailed description of available host bridges, for instance in the form of a fw-cfg file, and parse that information into a dynmaic list that allows, first to verify consistency of the data, and second discover the resources availabe for each root bridge. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* Ovmf/HardwareInfoLib: Create Pei lib to parse directly from fw-cfgNicolas Ojeda Leon2022-06-2213-0/+377
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define the HardwareInfoLib API and create the PeiHardwareInfoLib which implements it, specifically for Pei usage, supporting only static accesses to parse data directly from a fw-cfg file. All list-like APIs are implemented as unsupported and only a fw-cfg wrapper to read hardware info elements is provided. The Hardware Info library is intended to describe non-discoverable hardware information and share that from the host to the guest in Ovmf platforms. The QEMU fw-cfg extension for this library provides a first variation to parse hardware info by reading it directly from a fw-cfg file. This library offers a wrapper function to the plain QmeuFwCfgReadBytes which, specifically, parses header-data pairs out of the binary values in the file. For this purpose, the approach is incremental, reading the file block by block and outputting the values only for a specific known hardware type (e.g. PCI host bridges). One element is returned in each call until the end of the file is reached. Considering fw-cfg as the first means to transport hardware info from the host to the guest, this wrapping library offers the possibility to statically, and in steps, read a specific type of hardware info elements out of the file. This method reads one hardware element of a specific type at a time, without the need to pre-allocate memory and read the whole file or dynamically allocate memory for each new element found. As a usage example, the static approach followed by this library enables early UEFI stages to use and read hardware information supplied by the host. For instance, in early times of the PEI stage, hardware information can be parsed out from a fw-cfg file prescinding from memory services, that may not yet be available, and avoiding dynamic memory allocations. Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* OvmfPkg/Library: Create base HardwareInfoLib for PCI Host BridgesNicolas Ojeda Leon2022-06-223-0/+823
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create the Hardware Info library base together with the specifics to describe PCI Host Bridges. The Hardware Info library is intended to be used for disclosing non-discoverable hardware information from the host to the guest in Ovmf platforms. Core functionality will provide the possibility to parse information from a generic BLOB into runtime structures. The library is conceived in a generic way so that further hardware elements can also be described using it. For such purpose the length of the BLOB is not restricted but instead regarded as a sequence of header-info elements that allow the parsing during runtime. The first type of hardware defined will be PCI host bridges, providing the possibility to define multiple and specify the resources each of them can use. This enables the guest firmware to configure PCI resources properly. Having the size of each individual element favors the reuse of a single interface to convey descriptions of an arbitrary number of heterogenous hardware elements. Furthermore, flexible access mechanisms coupled with the size will grant the possibility of interpreting them in a single run. Define the base types of the generic Hardware Info library to parse heterogeneous data. Also provide the specific changes to support PCI host bridges as the first hardware type supported by the library. Additionally, define the HOST_BRIDGE_INFO structure to describe PCI host bridges along with the functionality to parse such information into proper structures used by the PCI driver in a centralized manner and taking care of versioning. As an example and motivation, the library will be used to define multiple PCI host bridges for complex platforms that require it. The first means of transportation that will be used is going to be fw-cfg, over which a stream of bytes will be transferred and later parsed by the hardware info library. Accordingly, the PCI driver will make use of these host bridges definitions to populate the list of Root Bridges and proceed with the configuration and discovery of underlying hardware components. As mentioned before, the binary data to be parsed by the Hardware Info library should be organized as a sequence of Header-element pairs in which the header describes the type and size of the associated element that comes right after it. As an illustration, to provide inforation of 3 host bridges the data, conceptually, would look like this: Header PCI Host Bridge (type and size) # 1 PCI Host Bridge info # 1 Header PCI Host Bridge (type and size) # 2 PCI Host Bridge info # 2 Header PCI Host Bridge (type and size) # 3 PCI Host Bridge info # 3 Cc: Alexander Graf <graf@amazon.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Nicolas Ojeda Leon <ncoleon@amazon.com>
* OvmfPkg: reduce the number of dsc include files for tpm libsGerd Hoffmann2022-06-228-41/+18
| | | | | | | | We can have multiple [LibraryClasses] sections, so we can place all TPM-related library configuration to a single include file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Use PcdOvmfWorkAreaBase instead of PcdSevEsWorkAreaBaseMin M Xu2022-06-162-3/+3
| | | | | | | | | | | | | It is an typo error that HobList pointer should be stored at PcdOvmfWorkAreaBase, not PcdSevEsWorkAreaBase. Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* Revert "OvmfPkg/Sec: fix stack switch"Gerd Hoffmann2022-06-101-4/+0
| | | | | | | | | This reverts commit ff36b2550f94dc5fac838cf298ae5a23cfddf204. Has no effect because GCC_IA32_CC_FLAGS and GCC_X64_CC_FLAGS are unused. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/Sec: fix stack switchGerd Hoffmann2022-06-081-0/+4
| | | | | | | | | | | | | | | | | | | | The ebp/rbp register can either be used for the frame pointer or as general purpose register. With gcc (and clang) this depends on the -f(no-)omit-frame-pointer switch. This patch updates tools_def.template to explicitly set the compiler option and also add a define to allow conditionally compile code. The new define is used to fix stack switching in TemporaryRamMigration. The ebp/rbp must not be touched when the compiler can use it as general purpose register. With version 12 gcc starts actually using the register, so changing it leads to firmware crashes in some configurations. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3934 Reported-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Delete SecMeasurementLibTdxMin M Xu2022-06-074-420/+0
| | | | | | | | | | The feature of SecMeasurementLibTdx is replaced by SecTpmMeasurementLibTdx (which is in SecurityPkg). So SecMeasurementLibTdx is deleted. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Implement MeasureHobList/MeasureFvImageMin M Xu2022-06-075-3/+224
| | | | | | | | | | | | | | | | | | | | | MeasureHobList and MeasureFvImage once were implemented in SecMeasurementTdxLib. The intention of this patch-set is to refactor SecMeasurementTdxLib to be an instance of TpmMeasurementLib. So these 2 functions (MeasureHobList/MeasureFvImage) are moved to PeilessStartupLib. This is because: 1. RTMR based trusted boot is implemented in Config-B (See below link) 2. PeilessStartupLib is designed for PEI-less boot and it is the right place to do the measurement for Hoblist and Config-FV. Config-B: https://edk2.groups.io/g/devel/message/76367 Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.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/IntelTdx: Enable RTMR based measurement and measure bootMin Xu2022-06-032-1/+16
| | | | | | | | | | | | | | | | | RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853 Enable RTMR based measurement and measure boot for Td guest. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Ken Lu <ken.lu@intel.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Min Xu <min.m.xu@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 15:00:35 +0000