summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgIa32X64.dsc
Commit message (Collapse)AuthorAgeFilesLines
...
* OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplugLaszlo Ersek2020-01-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MaxCpuCountInitialization() currently handles the following options: (1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0) In this case, PlatformPei makes MpInitLib enumerate APs up to the default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses. (Whichever is reached first.) Time-limited AP enumeration had never been reliable on QEMU/KVM, which is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF. (2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero) In this case, PlatformPei sets - PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count (FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"), - and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity" (MAX_UINT32, ~71 minutes). That causes MpInitLib to enumerate exactly the present (boot) APs. With CPU hotplug in mind, this method is not good enough. Because, using QEMU terminology, UefiCpuPkg expects PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count ("MachineState.smp.max_cpus"), which includes present and not present CPUs both (with not present CPUs being subject for hot-plugging). FW_CFG_NB_CPUS does not include not present CPUs. Rewrite MaxCpuCountInitialization() for handling the following cases: (1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set to values different from the defaults.) (2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via FW_CFG_NB_CPUS), but not the possible CPUs count ("MachineState.smp.max_cpus"). In this case, the behavior remains unchanged. The way MpInitLib is instructed to do the same differs however: we now set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count (while continuing to set PcdCpuMaxLogicalProcessorNumber identically). PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant. (3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via FW_CFG_NB_CPUS), and the possible CPUs count ("MachineState.smp.max_cpus"). We tell UefiCpuPkg about the possible CPUs count through PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU count for precise and quick AP enumeration, via PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is irrelevant again. This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE. As a side effect, the patch also enables S3 to work with CPU hotplug at once, *without* SMM_REQUIRE. (Without the patch, S3 resume fails, if a CPU is hot-plugged at OS runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not permitted. With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely "MachineState.smp.max_cpus". Therefore, the CPU structures allocated during normal boot can accommodate the CPUs at S3 resume that have been hotplugged prior to S3 suspend.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20191022221554.14963-4-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: use HII type PCDs for TPM2 config related variablesArd Biesheuvel2020-01-091-0/+6
| | | | | | | | | | | | | | | The HII pages that are part of Tcg2ConfigDxe expect the following PCDs to be of dynamic HII type, so declare them as such. gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev Currently, the TPM2 ACPI table is not produced, since we do not incorporate the Tcg2Smm module, which implements the SMI based physical presence interface exposed to the OS. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: reorganize TPM2 support in DSC/FDF filesArd Biesheuvel2020-01-091-3/+6
| | | | | | | | Put the TPM2 related DXE modules together in the DSC, and add a TPM2 support header comment while at it. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg DSC: Update tool chain name to CLANGPDBLiming Gao2019-11-151-3/+3
| | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2341 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Disable variable runtime cacheMichael Kubacki2019-11-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Sets gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache to FALSE in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc, and OvmfPkgX64.dsc so that when SMM_REQUIRE is TRUE, the SMM variable driver will not use the runtime variable cache. This is done for OvmfPkg because it currently depends upon a SMM variable GetVariable ()implementation as a simple method to exercise the SMM driver stack. This allows the following commands to be used for variables such as Boot####, BootOrder, and BootNext to test SMM timing and stability differences on the BSP (e.g. CPU#0) vs an AP (e.g. CPU#1). # taskset -c 0 efibootmgr # taskset -c 1 efibootmgr Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Enable CLANG9 tool chainLiming Gao2019-10-241-1/+3
| | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 1. Apply CLANG9 Linker option. 2. Exclude -mno-mmx -mno-sse compiler option for CLANG9 These two options will cause CLANG Linker crush. Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUEPeter Jones2019-10-221-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some tests check if it's defined or not. Additionally, in UefiPayloadPkg as well as some other trees, we define it as FALSE in the .dsc file. This patch changes all of the Ovmf platforms to explicitly define it as FALSE by default, and changes all of the checks to test if the value is TRUE. Signed-off-by: Peter Jones <pjones@redhat.com> Message-Id: <20190920184507.909884-1-pjones@redhat.com> [lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] [lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/AcpiPlatformDxe: Use XenPlatformLibAnthony PERARD2019-08-211-0/+1
| | | | | | | | | | This patch replace the XenDetected() function by the one in XenPlatformLib. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-15-anthony.perard@citrix.com>
* OvmfPkg: link SM3 support into Tcg2Pei and Tcg2DxeImran Desai2019-07-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781 GITHUB: https://github.com/idesai/edk2/tree/enable_sm3_measured_boot_v6 EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR banks. This digest algorithm is part of the China Crypto algorithm suite. This integration has dependency on the openssl_1_1_1b integration into edk2. This patch links SM3 support into Tcg2Pei and Tcg2Dxe. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Imran Desai <imran.desai@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190718225326.40839-5-imran.desai@intel.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* Revert "OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe"Laszlo Ersek2019-07-041-2/+0
| | | | | | | | | | | | | | | | | | This reverts commit a7c7d21ffa9ad14b418e728a882df0a9b8815bf6. The reason is that said commit had not been reviewed by OvmfPkg maintainers/reviewers, before it was pushed. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Imran Desai <imran.desai@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1781 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: use DxeTpmMeasurementLib if and only if TPM2_ENABLEGary Lin2019-07-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance became dependent on TpmMeasurementLib. For details, refer to commit 0d28d286bf4d ("OvmfPkg: resolve TpmMeasurementLib dependency introduced in r14687", 2013-09-21). (b) At the time, only one instance of TpmMeasurementLib existed, namely DxeTpmMeasurementLib. This lib instance didn't do anything -- like it was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE protocol implementations. (c) In commit 308521b13354 ("MdeModulePkg: Move TpmMeasurementLib LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was introduced. (d) In commit 285542ebbb03 ("OvmfPkg: Link AuthVariableLib for following merged variable driver deploy", 2015-07-01), a TpmMeasurementLib resolution became necessary regardless of SECURE_BOOT_ENABLE. And so TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the larger series containing commit 285542ebbb03 -- missed an opportunity for simplification: given (b), the DxeTpmMeasurementLib instance should have been simply replaced with the TpmMeasurementLibNull instance, regardless of SECURE_BOOT_ENABLE. (e) In commit 1abfa4ce4835 ("Add TPM2 support defined in trusted computing group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2 dependency in DxeTpmMeasurementLib. (f) Starting with commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module", 2018-03-09), OVMF would include a Tcg2 protocol implementation, thereby satisfying DxeTpmMeasurementLib's dependency. With TPM2_ENABLE, it would actually make sense to consume DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be used without SECURE_BOOT_ENABLE. Therefore, we have the following four scenarios: - TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected. - Neither enabled: works as expected. - Only TPM2_ENABLE: this build is currently incorrect, because Variable/RuntimeDxe consumes TpmMeasurementLib directly, but TpmMeasureAndLogData() will never reach the TPM because we link TpmMeasurementLibNull into the variable driver. This is a problem from the larger series containing (f). - Only SECURE_BOOT_ENABLE: this build works as expected, but it is wasteful -- given that the protocol database will never contain Tcg2 without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is a problem from (d). Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of *only* TPM2_ENABLE, we can fix / optimize the last two cases. v2: - Amend the title and description suggested by Laszlo - Move TpmMeasurementLib to the existed TPM2_ENABLE block Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20190704040731.5303-1-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: link SM3 support into Tcg2Pei and Tcg2DxeImran Desai2019-07-031-0/+2
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781 EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR banks. This digest algorithm is part of the China Crypto algorithm suite. This integration has dependency on the openssl_1_1_1b integration into edk2. This patch links SM3 support into Tcg2Pei and Tcg2Dxe. Signed-off-by: Imran Desai <imran.desai@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: jiewen.yao@intel.com
* OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabledDavid Woodhouse2019-06-261-0/+4
| | | | | | | | | | | | | | | | | | | | Mostly, this is only necessary for devices that the CSM might have native support for, such as VirtIO and NVMe; PciBusDxe will already degrade devices to 32-bit if they have an OpROM. However, there doesn't seem to be a generic way of requesting PciBusDxe to downgrade specific devices. There's IncompatiblePciDeviceSupportProtocol but that doesn't provide the PCI class information or a handle to the device itself, so there's no simple way to just match on all NVMe devices, for example. Just leave gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size set to zero for CSM builds, until/unless that can be fixed. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-5-dwmw2@infradead.org>
* OvmfPkg: Don't build in QemuVideoDxe when we have CSMDavid Woodhouse2019-06-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | QemuVideoDxe installs its own legacy INT 10h handler for the benefit of systems like Windows 2008r2 which attempt to use INT 10h even when booted via EFI. This interacts extremely badly with a CSM actually attempting to install a real video BIOS. The last thing done before invoking a legacy OpROM is to call INT 10h to set a plain text mode. In the case where it's the video BIOS OpROM being loaded, INT 10h will normally point to an iret stub in the CSM itself. Unless QemuVideoDxe has changed INT10h to point to a location in the 0xC0000 segment that it didn't allocate properly, so the real OpROM has been shadowed over them top of it, and the INT 10h vector now points to some random place in the middle of the newly-shadowed OpROM. Don't Do That Then. QemuVideoDxe doesn't do any acceleration and just sets up a linear framebuffer, so we don't lose much by just unconditionally using BiosVideoDxe instead when CSM is present. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-4-dwmw2@infradead.org>
* OvmfPkg: Refer to Shell app via its declared GUIDHao A Wu2019-06-171-2/+0
| | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843 Currently, the file GUID reference of the UEFI Shell app is indirected via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile, which is set to a fixed value for OvmfPkg. So instead, use the symbolic GUID in ShellPkg for this purpose, and drop the reference to this PCD, and to the IntelFrameworkModulePkg package entirely. Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkgHao A Wu2019-06-141-5/+5
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit updates the OVMF DSC/FDF files to consume the copied CSM components within OvmfPkg. Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Drop build flag USE_LEGACY_ISA_STACK and legacy ISA stackHao A Wu2019-06-111-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1842 According to the discussion at: https://edk2.groups.io/g/devel/topic/30918343#38093 For OVMF, we keep both ISA stacks: * The legacy one in PcAtChipsetPkg/IntelFrameworkModulePkg * The Sio bus based OVMF-specified one introduced by commit a5cc178aeb for a period of time (includes 1 stable tag: edk2-stable201905). And we also keep the Sio bus based OVMF-specified stack as the default one (via a build option 'USE_LEGACY_ISA_STACK') to validate its stability. This commit will propose to drop the legacy ISA stack from OVMF and remove the usage of the build flag 'USE_LEGACY_ISA_STACK' at the same time. This is considered as a preparation for the removal of PcAtChipsetPkg/IsaAcpiDxe & IntelFrameworkModulePkg. Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: raise the PCIEXBAR base to 2816 MB on Q35Laszlo Ersek2019-06-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is a replacement for commit 75136b29541b, "OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35", 2019-05-16). Commit 7b8fe63561b4 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35", 2016-03-10) claimed that, On Q35 machine types that QEMU intends to support in the long term, QEMU never lets the RAM below 4 GB exceed 2 GB. Alas, this statement came from a misunderstanding that occurred while we worked out the interface contract. In fact QEMU does allow the 32-bit RAM extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than 2048MB and smaller than 2816MB). In turn, such a RAM size (justifiedly) triggers ASSERT (TopOfLowRam <= PciExBarBase); in MemMapInitialization(), because we placed the 256MB PCIEXBAR at 0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the 32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000, 0xFC00_0000) range.) In order to fix this, place the PCIEXBAR at 2816MB (0xB000_0000), and start the 32-bit PCI window at 3 GB (0xC000_0000). This shrinks the 32-bit PCI window to 0xFC00_0000 - 0xC000_0000 = 0x3C00_0000 = 960 MB. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* Revert "OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR ↵Laszlo Ersek2019-06-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | on q35" This reverts commit 75136b29541b0e093a51d2e2c2af8d19855c2b60. The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814> triggered a bug / incorrect assumption in QEMU. QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above it. When the firmware doesn't satisfy this assumption, QEMU generates an \_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign 32-bit MMIO BARs. Working around the problem in the firmware looks less problematic than fixing QEMU. Revert the original changes first, before implementing an alternative fix. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35Laszlo Ersek2019-05-161-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7b8fe63561b4 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG / ECAM) on Q35", 2016-03-10) claimed that, On Q35 machine types that QEMU intends to support in the long term, QEMU never lets the RAM below 4 GB exceed 2 GB. Alas, this statement came from a misunderstanding that occurred while we worked out the interface contract. In fact QEMU does allow the 32-bit RAM extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than 2048MB and smaller than 2816MB). In turn, such a RAM size (justifiedly) triggers ASSERT (TopOfLowRam <= PciExBarBase); in MemMapInitialization(), because we placed the 256MB PCIEXBAR at 0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the 32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000, 0xFC00_0000) range.) In order to fix this, reorder the 32-bit PCI window against the PCIEXBAR, as follows: - start the 32-bit PCI window where it starts on i440fx as well, that is, at 2GB or TopOfLowRam, whichever is higher; - unlike on i440fx, where the 32-bit PCI window extends up to 0xFC00_0000, stop it at 0xE000_0000 on q35, - place the PCIEXBAR at 0xE000_0000. (We cannot place the PCIEXBAR at 0xF000_0000 because the 256MB MMIO area that starts there is not entirely free.) Before this patch, the 32-bit PCI window used to only *end* at the same spot (namely, 0xFC00_0000) between i440fx and q35; now it will only *start* at the same spot (namely, 2GB or TopOfLowRam, whichever is higher) between both boards. On q35, the maximal window shrinks from 0xFC00_0000 - 0x9000_0000 = 0x6C00_0000 == 1728 MB to 0xE000_0000 - 0x8000_0000 == 1536 MB. We lose 192 MB of the aperture; however, the aperture is now aligned at 1GB, rather than 256 MB, and so it could fit a 1GB BAR even. Regarding the minimal window (triggered by RAM size 2815MB), its size is 0xE000_0000 - 0xAFF0_0000 = 769 MB which is not great, but probably better than a failed ASSERT. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: Update DSC/FDF to use NetworkPkg's include fragment file.Fu Siyuan2019-05-161-45/+26
| | | | | | | | | | | | | | | | | | | | | | | | This patch updates the platform DSC/FDF files to use the include fragment files provided by NetworkPkg. The feature enabling flags in [Defines] section have been updated to use the NetworkPkg's terms, and the value has been overridden with the original default value on this platform. v2:1.Make the comments before Network definition align other parts. 2.Set NETWORK_ALLOW_HTTP_CONNECTIONS true. 3.Remove TcpIoLib in lib classes section. 4.Withdraw the removal of [PcdsFixedAtBuild.X64]. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Message-Id: <20190516081810.27840-2-shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293 [lersek@redhat.com: add TianoCore Bugzilla reference]
* OvmfPkg: Remove duplicated library classes in dxe drivers section in DSCZhang, Shenglei2019-05-151-4/+0
| | | | | | | | | | | | | | | | | NetLib,IpIoLib,UdpIoLib and DpcLib already exist in [LibraryClasses]. So the ones in [LibraryClasses.common.DXE_DRIVER] are duplicated, which should be removed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Message-Id: <20190515072419.23792-1-shenglei.zhang@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293 [lersek@redhat.com: add TianoCore BZ reference] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce EnrollDefaultKeys applicationLaszlo Ersek2019-04-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the OvmfPkg/EnrollDefaultKeys shell application source as it is at the "edk2-20190308git89910a39dcfd-2.el8" tag in RHEL8's downstream "edk2" package. Further patches in this series will replace Red Hat-specific bits in the application, with a conduit to pass in parameters directly from the host side, on both QEMU and Xen. (Note: at the moment, Xen doesn't support Secure Boot, due to lacking a standards-conformant variable driver stack. However, that could change soon <https://fosdem.org/2019/schedule/event/vai_implementing_uefi_variable_services_in_qemu/>, and then this facility will become useful on Xen too.) The use case for this application (including why it is only being added to the DSC files) is explained in detail in <https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c0>. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkgHao Wu2019-04-111-3/+0
| | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 This commit updates the OVMF DSC/FDF files to consume the copied 8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg. The unconsumed PCD: gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel is removed from DSC files as well. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/8254TimerDxe: Update to make it build for OVMFHao Wu2019-04-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 This commit will remove the IntelFrameworkPkg DEC file dependency in the driver INF file. A new GUID has been updated for the INF file. Corresponding changes have been made in OVMF DSC files as well in order to verify the build. Please note that a subsequent commit (final patch of the series) will: A) Add OvmfPkg/8254TimerDxe driver in OVMF FDF files; B) Remove the consumption of PcAtChipsetPkg/8254TimerDxe driver in OVMF DSC/FDF files. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMFHao Wu2019-04-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 Several updates have been made to the OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg: A) Update the driver INF file to consume PCDs defined within OvmfPkg; B) Remove the unnecessary dependency on the IntelFrameworkPkg header file 'FrameworkDxe.h'; C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in the driver INF file. A new GUID has been updated for the INF file. Corresponding changes have been made in OVMF DSC files as well in order to verify the build. Please note that a subsequent commit (final patch of the series) will: A) Add OvmfPkg/8259InterruptControllerDxe driver in OVMF FDF files; B) Remove the consumption of PcAtChipsetPkg/8259InterruptControllerDxe driver in OVMF DSC/FDF files; C) Remove the consumption of gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel in OVMF DSC files. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-091-7/+1
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add a build flag to select ISA driver stackHao Wu2019-03-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 This commit will add a static build flag 'USE_LEGACY_ISA_STACK' to select the ISA driver stack. If the flag is set to TRUE, the below driver stack will be used: PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf If the flag is set to FALSE, the below driver stack will be used: OvmfPkg/SioBusDxe/SioBusDxe.inf MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf The default value is set to FALSE in OVMF DSC files. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Add an Super IO bus driverHao Wu2019-03-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 There is a plan to remove the IntelFrameworkModulePkg: https://bugzilla.tianocore.org/show_bug.cgi?id=1605 This patch will a new OVMF Super I/O bus driver which will create the below child devices: * COM 1 UART * COM 2 UART * PS/2 Keyboard and installs the Super I/O Protocol on them. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Drop the ISA Floppy device supportHao Wu2019-03-271-2/+1
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 There is a plan to remove the IntelFrameworkModulePkg: https://bugzilla.tianocore.org/show_bug.cgi?id=1605 And for driver: IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe This patch proposes to drop the ISA Floppy device support in OVMF. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: add library to track boot option loading/starting on the consoleLaszlo Ersek2019-02-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the Platform Boot Manager Print Status Code Library (for short, PlatformBmPrintScLib) class for catching and printing the LoadImage() / StartImage() preparations, and return statuses, that are reported by UefiBootManagerLib. In the primary library instance, catch only such status codes that UefiBootManagerLib reports from the same module that contains PlatformBmPrintScLib. The intent is to establish a reporting-printing channel within BdsDxe, between UefiBootManagerLib and PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g. from UiApp's copy of UefiBootManagerLib. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/README: Remove UNIXGCCShenglei Zhang2019-02-141-1/+0
| | | | | | | | | | | | | | | | | | Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc and OvmfPkgX64.dsc. Remove content related to UNIXGCC in README. https://bugzilla.tianocore.org/show_bug.cgi?id=1377 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Add TCG2 Configuration menu to the Device Manager menuStefan Berger2019-02-111-0/+4
| | | | | | | | | | | | | | | | | This patch adds the TCG2 Configuration menu to the Device Manager menu. We can apparently reuse the sample Tcg2ConfigDxe from SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The added TCG2 Configuration menu now shows details about the attached TPM 2.0 and lets one for example configure the active PCR banks or issue commands, among other things. The code is added to Ovmf by building with -DTPM2_ENABLE and -DTPM2_CONFIG_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
* OvmfPkg: add MmServicesTableLib resolutionArd Biesheuvel2019-01-161-0/+1
| | | | | | | | | | | The SMM based FTW and variable drivers are going to depend on MmServicesTableLib after a subsequent patch, so add a resolution for it to various OvmfPkg .dsc files. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Remove PcdPeiCoreMaxXXX PCDs' statementStar Zeng2018-12-191-2/+0
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405 The codes have been updated to not use PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported, so their statement in platform DSC could be removed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chainLiming Gao2018-11-271-0/+2
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1355 XCODE doesn't support HII resource section. TftpDynamicCommand driver depends on HII resource section. To let OvmfPkg boot to shell on XCODE5 tool chain, don't include TftpDynamicCommand driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Remove EdkShellBinPkg in FDFshenglei2018-11-191-4/+0
| | | | | | | | | | | | | | | | Remove EdkShellBinPkg in OvmfPkgIa32.fdf, OvmfPkg/OvmfPkgIa32X64.fdf amd OvmfPkg/OvmfPkgX64.fdf. https://bugzilla.tianocore.org/show_bug.cgi?id=1108 v2: Remove USE_OLD_SHELL in DSC and FDF because it will be unnecessary to use it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace obsoleted network drivers from platform DSC/FDF.Fu Siyuan2018-11-061-9/+3
| | | | | | | | | | | | | | | | | | V2: Add missed library instance for NetworkPkg iSCSI driver. This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively maintained and will be removed from edk2 master soon. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei and Tcg2DxeGary Lin2018-08-161-0/+4
| | | | | | | | | | | | | | Sha384 and Sha512 were added to HashInstanceLib recently. To make them available in Tcg2Pei and Tcg2Dxe, we have to link both libraries. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Correct ResourcePublicationLib class name in DSC/INF filesLiming Gao2018-07-241-1/+1
| | | | | | | | | | | ResourcePublicationLib class name is ResourcePublicationLib. INF and DSC files are updated to use the correct one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Signed-off-by: Dongao Guo <dongao.guo@intel.com> [lersek@redhat.com: insert empty line between commit msg body and tags] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add QemuRamfbDxeGerd Hoffmann2018-06-141-0/+1
| | | | | | | | | | | Add a driver for the qemu ramfb display device. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> [lersek@redhat.com: fix INF banner typo] [lersek@redhat.com: make some local variable definitions more idiomatic] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: resolve PciCapLib, PciCapPciSegmentLib, PciCapPciIoLibLaszlo Ersek2018-05-241-0/+3
| | | | | | | | | | | | Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to their single respective instances. Later patches will use these lib classes in OvmfPkg drivers. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: add Tcg2PhysicalPresenceLibQemuMarc-André Lureau2018-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and: - removed all the functions that are unreachable from Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS], or SubmitRequestToPreOSFunction() and ReturnOperationResponseToOsFunction() [called from Tcg2Dxe]. - replaced everything that's related to the TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to the QEMU structures. This commit is based on initial experimental work from Stefan Berger. In particular, he wrote most of QEMU PPI support, and designed the qemu/firmware interaction. Initially, Stefan tried to reuse the existing SecurityPkg code, but we eventually decided to get rid of the variables and simplify the ovmf/qemu version. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: clean up non-idiomatic coding style] [lersek@redhat.com: null mPpi on invalid PPI address] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLEMarc-André Lureau2018-05-221-0/+2
| | | | | | | | | | | This NULL library will let us call Tcg2PhysicalPresenceLibProcessRequest() unconditionally from BdsPlatform when building without TPM2_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: replace MdeModulePkg.dec w/ MdePkg.dec] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxeLaszlo Ersek2018-04-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight years, no driver or application seems to have materialized that produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF includes) as RamDiskDxe. Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver, remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that now becomes unused too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926 Reported-by: Steven Shi <steven.shi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS bootLaszlo Ersek2018-03-301-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce TlsAuthConfigLib to read the list of trusted CA certificates from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE. The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust" utilities on the host side, so that the host settings take effect in guest HTTPS boot as well. QEMU forwards the file intact to the firmware. The contents are sanity-checked by NetworkPkg/HttpDxe code that was added in commit 0fd13678a681. Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user) and for NetworkPkg/HttpDxe (for the effective TLS configuration). The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the Mozilla CA root certificate bundle -- installed with the "ca-certificates" package -- is processed into a 182KB file. Thus, create EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable. Also, in TLS_ENABLE builds, set the cumulative limit for volatile variables (PcdVariableStoreSize) to 512KB, and the individual limit for the same (PcdMaxVolatileVariableSize) to 256KB. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: annotate "PcdVariableStoreSize := PcdFlashNvStorageVariableSize"Laszlo Ersek2018-03-301-0/+2
| | | | | | | | | | | | | | | | | As a continuation of the last patch, clarify in the DSC files that we set PcdVariableStoreSize to the same value as PcdFlashNvStorageVariableSize just for convenience; the equality is not a technical requirement. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxeMarc-André Lureau2018-03-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The library registers a security management handler, to measure images that are not measure in PEI phase. For example with the qemu PXE rom: Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi And the following binary_bios_measurements log entry seems to be added: PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4 The following order of operations ensures that 3rd party UEFI modules, such as PCI option ROMs and other modules possibly loaded from outside of firmware volumes, are measured into the TPM: (1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2 protocol sometime in the DXE phase (assuming a TPM2 chip is present, reported via PcdTpmInstanceGuid). (2) The DXE core finds that no more drivers are left to dispatch from DXEFV, and we enter the BDS phase. (3) OVMF's PlatformBootManagerLib connects all PCI root bridges non-recursively, producing PciIo instances and discovering PCI oproms. (4) The dispatching of images that don't originate from FVs is deferred at this point, by "MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c". (5) OVMF's PlatformBootManagerLib signals EndOfDxe. (6) OVMF's PlatformBootManagerLib calls EfiBootManagerDispatchDeferredImages() -- the images deferred in step (4) are now dispatched. (7) Image dispatch invokes the Security / Security2 Arch protocols (produced by SecurityStubDxe). In this patch, we hook DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch will try to locate the TCG2 protocol, and measure the image into the TPM2 chip with the protocol. Because of step (1), the TCG2 protocol will always be found and used (assuming a TPM2 chip is present). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include Tcg2Dxe moduleMarc-André Lureau2018-03-091-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This module measures and log the boot environment. It also produces the Tcg2 protocol, which allows for example to read the log from OS. The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2, which is required for crypto-agile log. In fact, only upcoming 4.16 adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2: [ 0.000000] efi: EFI v2.70 by EDK II [ 0.000000] efi: SMBIOS=0x3fa1f000 ACPI=0x3fbb6000 ACPI 2.0=0x3fbb6014 MEMATTR=0x3e7d4318 TPMEventLog=0x3db21018 $ python chipsec_util.py tpm parse_log binary_bios_measurements [CHIPSEC] Version 1.3.5.dev2 [CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module) [CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements'] PCR: 0 type: EV_S_CRTM_VERSION size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29 + version: PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc + base: 0x820000 length: 0xe0000 PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c + base: 0x900000 length: 0xa00000 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e PCR: 7 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c PCR: 4 type: EV_EFI_ACTION size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256 PCR: 0 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 1 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 2 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 3 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 4 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 5 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 $ tpm2_pcrlist sha1 : 0 : 35bd1786b6909daad610d7598b1d620352d33b8a 1 : ec0511e860206e0af13c31da2f9e943fb6ca353d 2 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 3 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 4 : 45a323382bd933f08e7f0e256bc8249e4095b1ec 5 : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b 6 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 7 : 518bd167271fbb64589c61e43d8c0165861431d8 8 : 0000000000000000000000000000000000000000 9 : 0000000000000000000000000000000000000000 10 : 0000000000000000000000000000000000000000 11 : 0000000000000000000000000000000000000000 12 : 0000000000000000000000000000000000000000 13 : 0000000000000000000000000000000000000000 14 : 0000000000000000000000000000000000000000 15 : 0000000000000000000000000000000000000000 16 : 0000000000000000000000000000000000000000 17 : ffffffffffffffffffffffffffffffffffffffff 18 : ffffffffffffffffffffffffffffffffffffffff 19 : ffffffffffffffffffffffffffffffffffffffff 20 : ffffffffffffffffffffffffffffffffffffffff 21 : ffffffffffffffffffffffffffffffffffffffff 22 : ffffffffffffffffffffffffffffffffffffffff 23 : 0000000000000000000000000000000000000000 sha256 : 0 : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c 1 : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8 2 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 3 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 4 : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35 5 : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0 6 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 7 : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068 8 : 0000000000000000000000000000000000000000000000000000000000000000 9 : 0000000000000000000000000000000000000000000000000000000000000000 10 : 0000000000000000000000000000000000000000000000000000000000000000 11 : 0000000000000000000000000000000000000000000000000000000000000000 12 : 0000000000000000000000000000000000000000000000000000000000000000 13 : 0000000000000000000000000000000000000000000000000000000000000000 14 : 0000000000000000000000000000000000000000000000000000000000000000 15 : 0000000000000000000000000000000000000000000000000000000000000000 16 : 0000000000000000000000000000000000000000000000000000000000000000 17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 23 : 0000000000000000000000000000000000000000000000000000000000000000 sha384 : The PhysicalPresenceLib is required, it sets some variables, but the firmware doesn't act on it yet. Laszlo Ersek explained on the list why Tpm2DeviceLib has to be resolved differently for DXE_DRIVER modules in general and for "Tcg2Dxe.inf" specifically: * We have a library class called Tpm2DeviceLib -- this is basically the set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h". Its leading comment says "This library abstract how to access TPM2 hardware device". There are two *sets* of APIs in "Tpm2DeviceLib.h": (a) functions that deal with the TPM2 device: - Tpm2RequestUseTpm(), - Tpm2SubmitCommand() This set of APIs is supposed to be used by clients that *consume* the TPM2 device abstraction. (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be used by *providers* of various TPM2 device abstractions. * Then, we have two implementations (instances) of the Tpm2DeviceLib class: (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the APIs listed under (a), and it does not implement (b) -- see EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for drivers that *consume* the TPM2 device abstraction. And, the (a) group of APIs is implemented by forwarding the requests to the TCG2 protocol. The idea here is that all the drivers that consume the TPM2 abstraction do not have to be statically linked with a large TPM2 device library instance; instead they are only linked (statically) with this "thin" library instance, and all the actual work is delegated to whichever driver that provides the singleton TCG2 protocol. (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant for the driver that offers (produces) the TCG2 protocol. This lib instance implements both (a) and (b) API groups. * Here's how things fit together: (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf" library instance (which has no lib class) is linked into "Tcg2Dxe.inf" via NULL class resolution. This simply means that before the "Tcg2Dxe.inf" entry point function is entered, the constructor function of "Tpm2InstanceLibDTpm.inf" will be called. (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and registers its own actual TPM2 command implementation with the "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe driver). This provides the back-end for the API set (a). TCG2 protocol provider (Tcg2Dxe.inf driver) launches | v NULL class: Tpm2InstanceLibDTpm instance construction | v Tpm2DeviceLib class: Tpm2DeviceLibRouter instance backend registration for API set (a) (iii) The Tcg2Dxe driver exposes the TCG2 protocol. (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls land in Tcg2Dxe, via the protocol. (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a) from lib instance (2). (vi) Those functions call the "backend" functions registered by Tpm2DeviceLibDTpm in step (ii). TPM 2 consumer driver | v Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance | v TCG2 protocol interface | v TCG2 protocol provider: Tcg2Dxe.inf driver | v Tpm2DeviceLib class: Tpm2DeviceLibRouter instance | v NULL class: Tpm2InstanceLibDTpm instance (via earlier registration) | v TPM2 chip (actual hardware) * So that is the "router" pattern in edk2. Namely, - Consumers of an abstraction use a thin library instance. - The thin library instance calls a firmware-global (singleton) service, i.e. a PPI (in the PEI phase) or protocol (in the DXE phase). - The PEIM providing the PPI, or the DXE driver providing the protocol, don't themselves implement the actual service either. Instead they offer a "registration" service too, and they only connect the incoming "consumer" calls to the earlier registered back-end(s). - The "registration service", for back-ends to use, may take various forms. It can be exposed globally to the rest of the firmware, as another member function of the PPI / protocol structure. Then backends can be provided by separate PEIMs / DXE drivers. Or else, the registration service can be exposed as just another library API. In this case, the backends are provided as NULL class library instances, and a platform DSC file links them into the PEIM / DXE driver via NULL class resolutions. The backend lib instances call the registration service in their own respective constructor functions. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include Tcg2Pei moduleMarc-André Lureau2018-03-091-0/+7
| | | | | | | | | | | | | This module will initialize TPM device, measure reported FVs and BIOS version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format compatibility, but the SHA-256 measurements and TCG 2 log format are now recommended. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-01 14:14:17 +0000