summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* Revert "OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe"Laszlo Ersek2019-07-043-6/+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-043-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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-033-0/+6
| | | | | | | | | | | | | | | | | | | 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/XenBusDxe: Don't call DisconnectController in Stop()Anthony PERARD2019-07-011-6/+0
| | | | | | | | | | | | Calling DisconnectController() on children isn't part of the job of EFI_DRIVER_BINDING_PROTOCOL.Stop() as it only needs to deallocate resources allocated in Start(). The disconnection will happen when both DevicePath and XenBus protocols gets uninstalled. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190701111403.7007-1-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/XenBusDxe: Close XenIoProtocol openned by childrenAnthony PERARD2019-07-011-0/+4
| | | | | | | | | | | | In XenBusDxe, the XenBusAddDevice() opens the gXenIoProtocolGuid on behalf of child controllers. It is never closed and prevents us from uninstalling the protocol. Close it where we stop all the children in XenBusDxe->Stop(). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190701105012.25758-1-anthony.perard@citrix.com>
* OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabledDavid Woodhouse2019-06-262-0/+8
| | | | | | | | | | | | | | | | | | | | 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-266-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/LegacyBbs: Add boot entries for VirtIO and NVME devicesDavid Woodhouse2019-06-261-5/+152
| | | | | | | | | | | | | Iterate over the available block devices in much the same way as BdsLibEnumerateAllBootOption() does, but limiting to those devices which are PCI-backed, which can be represented in the BbsTable. One day we might need to extend the BbsTable to allow us to distinguish between different NVMe namespaces on a device. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-3-dwmw2@infradead.org>
* OvmfPkg/LegacyBios: set NumberBbsEntries to the size of BbsTableDavid Woodhouse2019-06-261-3/+4
| | | | | | | | | | This is hard-coded in the IntThunk structure, and the additional entries will be needed for other devices like VirtIO and NVMe disks. So admit that they exist. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-2-dwmw2@infradead.org>
* OvmfPkg: Refer to Shell app via its declared GUIDHao A Wu2019-06-175-11/+5
| | | | | | | | | | | | | | | | | | 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/Csm/CsmSupportLib: Drop IntelFrameworkPkg dependencyHao A Wu2019-06-171-2/+1
| | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843 This commit will update the INF file of the CsmSupportLib to drop its dependency on IntelFrameworkPkg: gEfiLegacyBiosPlatformProtocolGuid gEfiLegacyBiosProtocolGuid gEfiLegacyInterruptProtocolGuid The above dependencies have already been addressed by the duplication of these definitions from IntelFrameworkPkg to OvmfPkg. Cc: Ray Ni <ray.ni@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> 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/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependencyHao A Wu2019-06-171-1/+0
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843 This commit will drop the driver's dependency on the IntelFrameworkPkg: gEfiLegacyBiosProtocolGuid Such dependency has already been addressed by the duplication of the above definition from IntelFrameworkPkg into the OvmfPkg. Cc: Ray Ni <ray.ni@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> 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/PlatformPei: Remove redundant reference of framework pkg DECHao A Wu2019-06-171-2/+1
| | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843 For the driver's INF file, this commit will remove the redundant reference to 'IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec'. 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/Csm/LegacyBiosDxe: Fix Legacy16GetTableAddress call for E820 dataDavid Woodhouse2019-06-141-0/+3
| | | | | | | | | | | | | | | | | | The DX register is supposed to contain the required alignment for the allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well with that. Set it appropriately. Also set BX to indicate the regions it's OK to allocate in too. That wasn't being initialised and was just using whatever the previous user of the structure had left there. Finally, actually return an error if the allocation fails. Instead of going all the way through into the CSM and just letting it have a bogus pointer to the E820 data. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkgHao A Wu2019-06-146-21/+21
| | | | | | | | | | | | | | 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/Csm/LegacyBootManagerLib: Update to make it build for OVMFHao A Wu2019-06-141-4/+3
| | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will update the library's INF file to: A) Assign a new file GUID; B) Remove the IntelFramework[Module]Pkg DEC file dependency. Please note that a subsequent commit (final patch of the series) will: Replace the use of LegacyBootManagerLib in IntelFrameworkModulePkg with the one copied in OvmfPkg within DSC files. 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/Csm/LegacyBootMaintUiLib: Update to make it build for OVMFHao A Wu2019-06-141-4/+3
| | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will update the library's INF file to: A) Assign a new file GUID; B) Remove the IntelFramework[Module]Pkg DEC file dependency. Please note that a subsequent commit (final patch of the series) will: Replace the use of LegacyBootMaintUiLib in IntelFrameworkModulePkg with the one copied in OvmfPkg within DSC files. 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/Csm/LegacyBiosDxe: Update to make it build for OVMFHao A Wu2019-06-141-12/+10
| | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will update the driver's INF file to: A) Assign a new file GUID; B) Consume the PCDs duplicated in OvmfPkg DEC file; C) Remove the IntelFramework[Module]Pkg DEC file dependency. Please note that a subsequent commit (final patch of the series) will: Replace the use of LegacyBiosDxe in IntelFrameworkModulePkg with the one copied in OvmfPkg within DSC/FDF files. 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/Csm/VideoDxe: Update to make it build for OVMFHao A Wu2019-06-141-8/+6
| | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will update the driver's INF file to: A) Assign a new file GUID; B) Consume the PCDs duplicated in OvmfPkg DEC file; C) Remove the IntelFramework[Module]Pkg DEC file dependency. Please note that a subsequent commit (final patch of the series) will: Replace the use of VideoDxe in IntelFrameworkModulePkg with the one copied in OvmfPkg within DSC/FDF files. 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/OvmfPkg.dec: Add PCD definitions used by copied CSM modulesHao A Wu2019-06-141-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will add the PCD definitions consumed by the duplicated drivers: * VideoDxe * LegacyBiosDxe into the OvmfPkg DEC file. Please note that, instead of adding these PCDs under section: [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule] as in IntelFrameworkModulePkg.dec file, they are added in section: [PcdsFixedAtBuild] in OvmfPkg.dec instead. 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/OvmfPkg.dec: Add the new include folder for CSM header filesHao A Wu2019-06-141-0/+1
| | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 The previous file-duplication commit has put all the CSM related header files within folder: OvmfPkg/Csm/Inclue. This commit will update the DEC file to add that folder under the '[Include]' section. 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/OvmfPkg.dec: Add definitions for CSM-related Guid & ProtocolHao A Wu2019-06-141-0/+9
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit will add the Guid definitions of the duplicated CSM-related Guids and Protocols from IntelFramework[Module]Pkg. 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: Copy the required CSM components from framework packagesHao A Wu2019-06-1450-0/+22879
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811 This commit copies the exact: Drivers: * VideoDxe * LegacyBiosDxe Libraries: * LegacyBootMaintUiLib * LegacyBootManagerLib Guid header files: * Legacy Bios Guid * LegacyDevOrder Guid Protocol header files: * Firmware Volume Protocol * ISA ACPI Protocol * ISA I/O Protocol * Legacy BIOS Protocol * Legacy BIOS Platform Protocol * Legacy Interrupt Protocol * VGA Mini Port Protocol Framework header files (within IntelFrameworkPkg): * FrameworkDxe.h * Framework/BootScript.h * Framework/DxeCis.h * Framework/FirmwareVolumeHeader.h * Framework/FirmwareVolumeImageFormat.h * Framework/FrameworkInternalFormRepresentation.h * Framework/Hob.h * Framework/StatusCode.h from IntelFramework[Module]Pkg to OvmfPkg/Csm/ folder. 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/README: Update the network build flagsGary Lin2019-06-111-3/+8
| | | | | | | | | | | | | | | | | | | The following network build flags changed due to the inclusion of NetworkPkg/Network.fdf.inc. HTTP_BOOT_ENABLE -> NETWORK_HTTP_BOOT_ENABLE TLS_ENABLE -> NETWORK_TLS_ENABLE This commit also adds NETWORK_ALLOW_HTTP_CONNECTIONS to reflect the change in OvmfPkg/OvmfPkg*.dsc. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1884 Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20190610065509.19573-1-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Drop build flag USE_LEGACY_ISA_STACK and legacy ISA stackHao A Wu2019-06-116-60/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/QemuVideoDxe: Shouldn't assume system in VGA alias mode.Marc W Chen2019-06-061-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Query the supported attributes firstly, then bitwise AND (&) both VGA_IO and VGA_IO_16. Since the supported attributes should only have one of VGA_IO or VGA_IO_16 set, the result of bitwise AND (&) is either VGA_IO or IO_16. Then the result can be passed to PciIo->Attributes() to set the attributes. Device driver should consider both since the mReserveVgaAliases in PciBusDxe driver is default FALSE(implies that device driver can only set VGA_IO_16 to PCI_ROOT_BRIDGE), and Platform code may not return EFI_RESERVE_VGA_IO_ALIAS in GetPlatformPolicy of PciPlatformProtocol to make mReserveVgaAliases become TRUE(implies that device driver can only set VGA_IO to PCI_ROOT_BRIDGE), Currently OvmfPkg doesn't have problem due to it has hard code value for PCI_ROOT_BRIDGE's attributes field, so an IO access by PciIoProtocol will be successed due to RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get pass result for legacy IO access. Usually the attributes field of PCI_ROOT_BRIDGE should be 0, in that case it will have issue since the VGA_IO may not be able to be enabled, then IO access by PciIoProtocol will be failed, hence the QemuVideoDxe driver will not work fine. Signed-off-by: Marc Chen <marc.w.chen@intel.com> 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@arm.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190606074237.81492-1-marc.w.chen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase (pc/q35)Laszlo Ersek2019-06-033-5/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This is a replacement for commit 39b9a5ffe661 ("OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clear", 2019-05-16).) Reintroduce the same logic as seen in commit 39b9a5ffe661 for the pc (i440fx) board type. For q35, the same approach doesn't work any longer, given that (a) we'd like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and (b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit PCI MMIO aperture. Therefore, introduce a helper function for determining the 32-bit "uncacheable" (MMIO) area base address: - On q35, this function behaves statically. Furthermore, the MTRR setup exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at 0xC000_0000 (size 1GB)). - On pc (i440fx), the function behaves dynamically, implementing the same logic as commit 39b9a5ffe661 did. The PciBase value is adjusted to the value calculated, similarly to commit 39b9a5ffe661. A further simplification is that we show that the UC32 area size truncation to a whole power of two automatically guarantees a >=2GB base address. 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: raise the PCIEXBAR base to 2816 MB on Q35Laszlo Ersek2019-06-033-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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: assign PciSize on both i440fx/q35 branches ↵Laszlo Ersek2019-06-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | explicitly" This reverts commit 60e95bf5094fbb9b728729ccfaf32184b3662317. 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> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* Revert "OvmfPkg/PlatformPei: hoist PciBase assignment above the i440fx/q35 ↵Laszlo Ersek2019-06-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | branching" This reverts commit 9a2e8d7c65ef7f39c6754d27e52954b616bc6628. 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>
* Revert "OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR ↵Laszlo Ersek2019-06-034-7/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Revert "OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits ↵Laszlo Ersek2019-06-033-24/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | clear" This reverts commit 39b9a5ffe6618b7870be2a54fe7725000249c33a. 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> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformPei: fix MTRR for low-RAM sizes that have many bits clearLaszlo Ersek2019-05-163-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assume that we boot OVMF in a QEMU guest with 1025 MB of RAM. The following assertion will fire: > ASSERT_EFI_ERROR (Status = Out of Resources) > ASSERT OvmfPkg/PlatformPei/MemDetect.c(696): !EFI_ERROR (Status) That's because the range [1025 MB, 4 GB) that we try to mark as uncacheable with MTRRs has size 3071 MB: 0x1_0000_0000 -0x0_4010_0000 -------------- 0x0_BFF0_0000 The integer that stands for the uncacheable area size has 11 (eleven) bits set to 1. As a result, covering this size requires 11 variable MTRRs (each MTRR must cover a naturally aligned, power-of-two sized area). But, if we need more variable MTRRs than the CPU can muster (such as 8), then MtrrSetMemoryAttribute() fails, and we refuse to continue booting (which is justified, in itself). Unfortunately, this is not difficult to trigger, and the error message is well-hidden from end-users, in the OVMF debug log. The following mitigation is inspired by SeaBIOS: Truncate the uncacheable area size to a power-of-two, while keeping the end fixed at 4 GB. Such an interval can be covered by just one variable MTRR. This may leave such an MMIO gap, between the end of low-RAM and the start of the uncacheable area, that is marked as WB (through the MTRR default). Raise the base of the 32-bit PCI MMIO aperture accordingly -- the gap will not be used for anything. On Q35, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 2815 MB) shrinks from 0xE000_0000 - 0xAFF0_0000 = 769 MB to 0xE000_0000 - 0xC000_0000 = 512 MB On i440fx, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 3583 MB) shrinks from 0xFC00_0000 - 0xDFF0_0000 = 449 MB to 0xFC00_0000 - 0xE000_0000 = 448 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=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: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35Laszlo Ersek2019-05-164-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/PlatformPei: hoist PciBase assignment above the i440fx/q35 branchingLaszlo Ersek2019-05-161-1/+1
| | | | | | | | | | | | | | | | | | | | In the MemMapInitialization() function, we currently assign PciBase different values, on both branches of the board type check. Hoist the PciBase assignment from the i440fx branch in front of the "if". This is a no-op for the i440fx branch. On the q35 branch, we overwrite this value, hence the change is a no-op on q35 as well. This is another refactoring for simplifying the rest of this series. 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: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/PlatformPei: assign PciSize on both i440fx/q35 branches explicitlyLaszlo Ersek2019-05-161-1/+2
| | | | | | | | | | | | | | | | | In the MemMapInitialization() function, we currently have a common PciSize assignment, shared between i440fx and q35. In order to simplify the rest of this series, lift and duplicate the assignment identically to both board-specific branches. 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: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: Update DSC/FDF to use NetworkPkg's include fragment file.Fu Siyuan2019-05-166-219/+81
| | | | | | | | | | | | | | | | | | | | | | | | 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/EnrollDefaultKeys: import the non-default key into dbGary Lin2019-05-161-14/+39
| | | | | | | | | | | | | | | | | | For QA test and development, we may need to test Secure Boot with a devel key instead of UEFI CA. This commit adds an argument, "--no-default", to EnrollDefaultKeys.efi. With the argument, the key from SMBIOS Type 11 will also be enrolled into db. Besides, the keys in AuthData.c, i.e. Microsoft KEK CA, Microsoft PCA, and Microsoft UEFI CA will be excluded, so the developer can easily create a varstore template for a specific key. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20190516030834.12203-1-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Remove duplicated library classes in dxe drivers section in DSCZhang, Shenglei2019-05-153-12/+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/QemuVideoDxe: Remove dependency on OptionRomPkgMichael D Kinney2019-05-094-36/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Update the QemuVideoDxe driver to not depend on the OptionRomPkg to support moving OptionRomPkg to the edk2-platforms repository. The only dependency on the OptionRomPkg is the use of PcdDriverSupportedEfiVersion to set the version value in the EFI Driver Supported EFI Version Protocol. Quoting the UEFI-2.8 spec, "This protocol is required for EFI drivers that are *on* PCI and other plug in cards" (emphasis ours). However, QemuVideoDxe is always part of the OVMF platform firmware, and is never read by PciBusDxe from the PCI ROM BAR of QEMU's emulated graphics cards. Since this protocol does not apply to QEMU environment, remove both the PCD and the installation of the EFI Driver Supported EFI Version Protocol. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/EnrollDefaultKeys: suppress incorrect compiler warningLaszlo Ersek2019-05-011-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | When building OvmfPkg/EnrollDefaultKeys for IA32 with gcc-4.8 for the DEBUG target (and possibly under other build configurations too), the compiler incorrectly reports, > OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c: In function > 'ShellAppMain': > OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c:631:10: error: > 'SizeOfPkKek1' may be used uninitialized in this function > [-Werror=maybe-uninitialized] > Status = EnrollListOfCerts ( > ^ > OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c:703:12: error: 'PkKek1' > may be used uninitialized in this function [-Werror=maybe-uninitialized] > FreePool (PkKek1); > ^ > cc1: all warnings being treated as errors Suppress this warning, in the style suggested under <https://bugzilla.tianocore.org/show_bug.cgi?id=607>. Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Fixes: be9470b3c91fc50436c15a76c85cdde940355b9f Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/XenSupport: turn off address decoding before BAR sizingIgor Druzhinin2019-04-301-0/+21
| | | | | | | | | | | | | | | On Xen, hvmloader firmware leaves address decoding enabled for enumerated PCI device before jumping into OVMF. OVMF seems to expect it to be disabled and tries to size PCI BARs in several places without disabling it which causes BAR64, for example, being incorrectly placed by QEMU. Fix it by disabling PCI address decoding explicitly before the first attempt to size BARs on Xen. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64Igor Druzhinin2019-04-301-1/+5
| | | | | | | | In case BAR64 is placed below 4G choose the correct aperture. This fixes a failed assertion down the code path. Acked-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
* OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge apertureIgor Druzhinin2019-04-301-22/+12
| | | | | | | | | | | | | | | | | | This aperture doesn't exist in QEMU-XEN and hvmloader places BARs in arbitrary order disregarding prefetchable bit. This makes prefetchable and non-prefetchable BARs to follow each other that's quite likely with PCI passthrough devices. In that case, the existing code, that tries to work out aperture boundaries by reading hvmloader BAR placement, will report a bogus prefetchable aperture which overlaps with the regular one. It will eventually trigger an assertion in DXE PCI initialization code. Do the same thing as OVMF on QEMU-KVM and pass a non-existing aperture there. It's not necessary to pass additional allocation flags as we set ResourceAssigned flag on the root bridge which means they will be ignored. Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
* OvmfPkg/EnrollDefaultKeys: remove Red Hat's hard-coded PK/KEK1Laszlo Ersek2019-04-302-88/+0
| | | | | | | | | | | | | | | | | | | The certificate "Red Hat Secure Boot (PK/KEK key 1)/emailAddress=secalert@redhat.com" SHA1: fd:fc:7f:3c:7e:f3:e0:57:76:ad:d7:98:78:21:6c:9b:e0:e1:95:97 is no longer referenced; remove it. 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/EnrollDefaultKeys: enroll PK/KEK1 from the Type 11 SMBIOS tableLaszlo Ersek2019-04-302-13/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disconnect the certificate that is enrolled as both Platform Key and first Key Exchange Key from Red Hat: expect the hypervisor to specify it, as part of SMBIOS. Example usage with QEMU: * Generate self-signed X509 certificate: openssl req \ -x509 \ -newkey rsa:2048 \ -outform PEM \ -keyout PkKek1.private.key \ -out PkKek1.pem (where "PEM" simply means "DER + base64 + header + footer"). * Strip the header, footer, and newline characters; prepend the application prefix: sed \ -e 's/^-----BEGIN CERTIFICATE-----$/4e32566d-8e9e-4f52-81d3-5bb9715f9727:/' \ -e '/^-----END CERTIFICATE-----$/d' \ PkKek1.pem \ | tr -d '\n' \ > PkKek1.oemstr * Pass the certificate to EnrollDefaultKeys with the following QEMU option: -smbios type=11,value="$(< PkKek1.oemstr)" (Note: for the above option to work correctly, a QEMU version is needed that includes commit 950c4e6c94b1 ("opts: don't silently truncate long option values", 2018-05-09). The first upstream release with that commit was v3.0.0. Once <https://bugs.launchpad.net/qemu/+bug/1826200> is fixed, QEMU will learn to read the file directly; passing the blob on the command will be necessary no more.) 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: introduce OVMF_PK_KEK1_APP_PREFIX_GUIDLaszlo Ersek2019-04-302-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | For the EnrollDefaultKeys application, the hypervisor is expected to add a string entry to the "OEM Strings" (Type 11) SMBIOS table, with the following format: 4e32566d-8e9e-4f52-81d3-5bb9715f9727:<Base64 X509 cert for PK and first KEK> The string representation of the GUID at the front is the "application prefix", in terms of QEMU commit <https://git.qemu.org/?p=qemu.git;a=commit;h=2d6dcbf93fb0>. Introduce this GUID in the usual manner. 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/EnrollDefaultKeys: document the steps of the entry point functionLaszlo Ersek2019-04-301-0/+54
| | | | | | | | | | | | | | | | | | The entry point function of EnrollDefaultKeys finishes with a sanity check, verifying the values of the Secure Boot-related "control" variables. Add a diagram to explain why we expect the values we do. While at it, write comments on the rest of the entry point function. 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/EnrollDefaultKeys: describe functions with leading comment blocksLaszlo Ersek2019-04-301-0/+73
| | | | | | | | | | | | | | | | | | The GetExact(), GetSettings(), PrintSettings(), and ShellAppMain() functions lack leading comment blocks. Supply those. While at it, make sure that every such comment block is preceded by two blank lines. 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/EnrollDefaultKeys: extract MICROSOFT_VENDOR_GUIDLaszlo Ersek2019-04-306-33/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | The GUID 77FA9ABD-0359-4D32-BD60-28F4E78F784B is specified in MSDN, at <https://msdn.microsoft.com/en-us/ie/dn932805(v=vs.94)>, therefore it deserves an entry in the package DEC file, and a header file under "Include/Guid". (Arguably, this GUID declaration / definition could even live under SecurityPkg, but the edk2 tradition has been to hoist GUIDs, protocols/PPIs, and lib classes from OvmfPkg to a core package only when dependent C code is added to the core package.) 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-06 21:39:25 +0000