summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgX64.fdf
Commit message (Collapse)AuthorAgeFilesLines
* 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: raise DXEFV size to 11 MBLaszlo Ersek2018-05-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost exactly two years after commit 2f7b34b20842f, we've grown out the 10MB DXEFV: > build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \ > -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D E1000_ENABLE \ > -D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE > > [...] > > GenFv: ERROR 3000: Invalid > the required fv image size 0xa28d48 exceeds the set fv image size > 0xa00000 Raise the DXEFV size to 11MB. (For builds that don't need this DXEFV bump, I've checked the FVMAIN_COMPACT increase stemming from the additional 1MB padding, using NOOPT + GCC48 + FD_SIZE_2MB, and no other "-D" flags. In the IA32 build, FVMAIN_COMPACT grows by 232 bytes. In the IA32X64 build, FVMAIN_COMPACT shrinks by 64 bytes. In the X64 build, FVMAIN_COMPACT shrinks by 376 bytes.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary 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: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.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: include Tcg2Dxe moduleMarc-André Lureau2018-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | 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>
* OvmfPkg: add customized Tcg2ConfigPei cloneMarc-André Lureau2018-03-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Tcg2ConfigPei module informs the firmware globally about the TPM device type, by setting the PcdTpmInstanceGuid PCD to the appropriate GUID value. The original module under SecurityPkg can perform device detection, or read a cached value from a non-volatile UEFI variable. OvmfPkg's clone of the module only performs the TPM2 hardware detection. This is what the module does: - Check the QEMU hardware for TPM2 availability only - If found, set the dynamic PCD "PcdTpmInstanceGuid" to &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of the firmware about the TPM type. - Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD. In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting and the consumption of the "TPM type" PCD. - If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid. (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if no TPM2 is available. So in that case our Tcg2ConfigPei must do it.) 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: Add tftp dynamic commandRuiyu Ni2017-11-291-1/+2
| | | | | | | | | | | | | | | The TFTP command was converted from a NULL class library instance to a dynamic shell command in commit 0961002352e9. This patch complements commit f9bc2f876326, which only removed the old library, but didn't add the new dynamic command。 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: 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>
* OvmfPkg: restore temporary SEC/PEI RAM size to 64KBLaszlo Ersek2017-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) In the PEI phase, the PCD database is maintained in a GUID HOB. In OVMF, we load the PCD PEIM before any other PEIMs (using APRIORI PEI), so that all other PEIMs can use dynamic PCDs. Consequently, - the PCD GUID HOB is initially allocated from the temporary SEC/PEI heap, - whenever we introduce a dynamic PCD to a PEIM built into OVMF such that the PCD is new to OVMF's whole PEI phase, the PCD GUID HOB (and its temporary heap footprint) grow. I've noticed that, if we add just one more dynamic PCD to the PEI phase, then in the X64 build, - we get very close to the half of the temporary heap (i.e., 8192 bytes), - obscure PEI phase hangs or DXE core initialization failures (ASSERTs) occur. The symptoms vary between the FD_SIZE_2MB and FD_SIZE_4MB builds of X64 OVMF. (2) I've found that commit 2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings", 2017-09-27) introduced a large (16KB) stack allocation: > The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and > MtrrSetMemoryAttribute() to use the 4-page stack buffer for calculation. > ... > +#define SCRATCH_BUFFER_SIZE (4 * SIZE_4KB) > ... > @@ -2207,17 +2462,66 @@ MtrrSetMemoryAttributeInMtrrSettings ( > ... > + UINT8 Scratch[SCRATCH_BUFFER_SIZE]; (3) OVMF's temp SEC/PEI RAM size has been 32KB ever since commit 7cb6b0e06809 ("OvmfPkg: Move SEC/PEI Temporary RAM from 0x70000 to 0x810000", 2014-01-21) Of that, the upper 16KB half is stack (growing down), and the lower 16KB half is heap. Thus, OvmfPkg/PlatformPei's calls to "UefiCpuPkg/Library/MtrrLib", in QemuInitializeRam(), cause the Scratch array to overflow the entire stack (heading towards lower addresses), and corrupt the heap below the stack. It turns out that the total stack demand is about 24KB, so the overflow is able to corrupt the upper 8KB of the heap. If that part of the heap is actually used (for example because we grow the PCD GUID HOB sufficiently), mayhem ensues. (4) Right after commit 7cb6b0e06809 (see above), there would be no room left above the 32KB temp SEC/PEI RAM. However, given more recent commits 45d870815156 ("OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3", 2016-07-13) 6b04cca4d697 ("OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySize", 2016-07-12) we can now restore the temp SEC/PEI RAM size to the original (pre-7cb6b0e06809) 64KB. This will allow for a 32KB temp SEC/PEI stack, which accommodates the ~24KB demand mentioned in (3). (Prior patches in this series will let us monitor the stack usage in the future.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=747 Ref: http://mid.mail-archive.com/a49cc089-12ae-a887-a4d6-4dc509233a74@redhat.com Ref: http://mid.mail-archive.com/03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Enable UDF file system supportPaulo Alcantara2017-09-081-0/+1
| | | | | | | | | | | This patch enables UDF file system support by default. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg: Add IoMmuDxe driverBrijesh Singh2017-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IOMMU protocol driver provides capabilities to set a DMA access attribute and methods to allocate, free, map and unmap the DMA memory for the PCI Bus devices. Due to security reasons all DMA operations inside the SEV guest must be performed on shared (i.e unencrypted) pages. The IOMMU protocol driver for the SEV guest uses a bounce buffer to map guest DMA buffer to shared pages inorder to provide the support for DMA operations inside SEV guest. IoMmuDxe driver looks for SEV capabilities, if present then it installs the real IOMMU protocol otherwise it installs placeholder protocol. Currently, PciHostBridgeDxe and QemuFWCfgLib need to know the existance of IOMMU protocol. The modules needing to know the existance of IOMMU support should add gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid in their depex to ensure that platform IOMMU detection has been performed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Add AmdSevDxe driverBrijesh Singh2017-07-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When SEV is enabled, the MMIO memory range must be mapped as unencrypted (i.e C-bit cleared). We need to clear the C-bit for MMIO GCD entries in order to cover the ranges that were added during the PEI phase (through memory resource descriptor HOBs). Additionally, the NonExistent ranges are processed in order to cover, in advance, MMIO ranges added later in the DXE phase by various device drivers, via the appropriate DXE memory space services. The approach is not transparent for later addition of system memory ranges to the GCD memory space map. (Such ranges should be encrypted.) OVMF does not do such a thing at the moment, so this approach should be OK. The driver is being added to the APRIORI DXE file so that, we clear the C-bit from MMIO regions before any driver accesses it. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leo Duran <leo.duran@amd.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: update -D E1000_ENABLE from Intel PROEFI v.07 to BootUtil v.22Laszlo Ersek2017-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Jiaxin reports that the OvmfPkg/README instructions for downloading the Intel PROEFI drivers, and the filenames in OvmfPkg/OvmfPkg*.fdf for incorporating the same in the OVMF binaries, are no longer up to date; the download link has stopped working. Additionally, the IA32 driver binary is no more distributed by Intel. Update OvmfPkg/README with new download instructions, and adapt the OVMF FDF files. With this driver in use for QEMU's e1000 NIC, the DH shell command prints, as Controller Name, "Intel(R) PRO/1000 MT Network Connection". I successfully tested DHCP and ping from the UEFI shell. Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reported-by: Jiaxin Wu <jiaxin.wu@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: disable build-time relocation for DXEFV modulesLaszlo Ersek2017-07-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the GenFv utility from BaseTools composes a firmware volume, it checks whether modules in the firmware volume are subject to build-time relocation. The primary indication for relocation is whether the firmware volume has a nonzero base address, according to the [FD] section(s) in the FDF file that refer to the firmware volume. The idea behind build-time relocation is that XIP (execute in place) modules will not be relocated at boot-time: - Pre-DXE phase modules generally execute in place. (OVMF is no exception, despite the fact that we have writeable memory even in SEC: PEI_CORE and PEIMs run in-place from PEIFV, after SEC decompresses PEIFV and DXEFV from FVMAIN_COMPACT (flash) to RAM. PEI_CORE and the PEIMs are relocated at boot-time only after PlatformPei installs the permanent PEI RAM, and the RAM migration occurs.) - Modules dispatched by the DXE Core are generally relocated at boot-time. However, this is not necessarily so. Quoting Liming from <https://lists.01.org/pipermail/edk2-devel/2017-July/012053.html>: > PI spec has no limitation that XIP is for PEIM only. DXE driver may be > built as XIP for other purpose. For example, if DXE driver image address > is not zero, DxeCore will try allocating the preferred address and load > it. In another case, once DXE driver is relocated at build time, DxeCore > will dispatch it and start it directly without loading, it may save boot > performance. Therefore GenFv relocates even DXE and UEFI driver modules if the containing firmware volume has a nonzero base address. In OVMF, this is the case for both PEIV and DXEFV: > [FD.MEMFD] > BaseAddress = $(MEMFD_BASE_ADDRESS) > Size = 0xB00000 > ErasePolarity = 1 > BlockSize = 0x10000 > NumBlocks = 0xB0 > ... > 0x020000|0x0E0000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize > FV = PEIFV > > 0x100000|0xA00000 > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize > FV = DXEFV While the build-time relocation certainly makes sense for PEIFV (see above), the reasons for which we specify DXEFV under [FD.MEMFD] are weaker: - we set the PcdOvmfDxeMemFvBase and PcdOvmfDxeMemFvSize PCDs here, - and we ascertain that DXEFV, when decompressed by SEC from FVMAIN_COMPACT, will fit into the area allotted here, at build time. In other words, the build-time relocation of the modules in DXEFV is a waste of resources. But, it gets worse: Build-time relocation of an executable is only possible if the on-disk and in-memory layouts are identical, i.e., if the sections of the PE/COFF image adhere to the same alignment on disk and in memory. Put differently, the FileAlignment and SectionAlignment headers must be equal. For boot-time modules that we build as part of edk2, both alignment values are 0x20 bytes. For runtime modules that we build as part of edk2, both alignment values are 0x1000 bytes. This is why the DXEFV relocation, albeit wasteful, is also successful every time. Unfortunately, if we try to include a PE/COFF binary in DXEFV that originates from outside of edk2, the DXEFV relocation can fail due to the binary having unmatched FileAlignment and SectionAlignment headers. This is precisely the case with the E3522X2.EFI network driver for the e1000 NIC, from Intel's BootUtil / PREBOOT.EXE distribution. The solution is to use the FvForceRebase=FALSE override under [FV.DXEFV]. This tells GenFv not to perform build-time relocation on the firmware volume, despite the FV having a nonzero base address. In DXEFV we also have SMM drivers. Those are relocated at boot-time (into SMRAM) unconditionally; SMRAM is always discovered at boot-time. Kudos to Ard and Liming for the PE/COFF sections & relocations explanation, and for the FvForceRebase=FALSE tip. I regression-tested this change in the following configurations (all with normal boot and S3 suspend/resume): IA32, q35, SMM, Linux IA32X64, q35, SMM, Linux IA32X64, q35, SMM, Windows-8.1 X64, i440fx, no-SMM, Linux Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Liming Gao <liming.gao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=613 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=615 Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)Gary Lin2017-01-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | This commit introduces a new build option, TLS_ENABLE, to pull in the TLS-related modules. If HTTP_BOOT_ENABLE and TLS_ENABLE are enabled at the same time, the HTTP driver locates the TLS protocols automatically and thus HTTPS is enabled. To build OVMF with HTTP Boot: $ ./build.sh -D HTTP_BOOT_ENABLE To build OVMF with HTTPS Boot: $ ./build.sh -D HTTP_BOOT_ENABLE -D TLS_ENABLE Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: correct the IScsiDxe module included for the IPv6 stackGary Lin2017-01-171-4/+0
| | | | | | | | | | | | | | | | | | | | | Always use IScsiDxe from NetworkPkg when IPv6 is enabled since it provides the complete ISCSI support. NOTE: This makes OpenSSL a hard requirement when NETWORK_IP6_ENABLE is true. (Based on Jiaxin's suggestion) Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Wu Jiaxin <jiaxin.wu@intel.com> Cc: Long Qin <qin.long@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Install BGRT ACPI tableBhupesh Sharma2017-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While debugging OS for ACPI BGRT support (especially on VMs), it is very useful to have the EFI firmware (OVMF in most cases which use Tianocore) to export the ACPI BGRT table. This patch tries to add this support in OvmfPkg. Tested this patch in the following environments: 1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host: - Ensured that the BGRT logo is properly prepared and can be viewed with user-space tools (like 'Gwenview' on KDE, for example): $ file /sys/firmware/acpi/bgrt/image /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x 24 2. On a Windows-10 VM Guest running on a Fedora-24 Host: - Ensured that the BGRT ACPI table is properly prepared and can be read with freeware tool like FirmwareTablesView: ================================================== Signature : BGRT Firmware Provider : ACPI Length : 56 Revision : 1 Checksum : 129 OEM ID : INTEL OEM Table ID : EDK2 OEM Revision : 0x00000002 Creator ID : 0x20202020 Creator Revision : 0x01000013 Description : ================================================== Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table, Windows 8 and Windows 10 first clear the screen, then display a blue, slanted Windows picture above the rotating white boot animation. With the BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue Windows image is not displayed, and the rotating white boot animation is shown between the firmware's original TianoCore boot splash and (optional) "Start boot option" progress bar. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use the new LogoDxe driverRuiyu Ni2016-09-281-3/+1
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg: Use MdeModulePkg/ResetSystemRuntimeDxeRuiyu Ni2016-09-021-1/+1
| | | | | | | Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF filesLaszlo Ersek2016-09-011-0/+1
| | | | | | | | | | | | At this stage, the driver builds, and suffices for testing binding and unbinding. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: use StatusCode Router and Handler from MdeModulePkgCinnamon Shia2016-08-021-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com> Suggested-by: Liming Gao <liming.gao@intel.com> Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63 [jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include UefiCpuPkg/CpuMpPeiLaszlo Ersek2016-07-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use. CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those already used by CpuDxe: - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these control whether CpuMpPei performs microcode update. If the region size is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the region size to zero by default, which is appropriate for OVMF. - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait (with PAUSE). The latter PCD is only relevant if the former PCD is 2 (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself, we choose HLT. That's the default set by UefiCpuPkg.dec. Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib technically, it is supposed to consume PeiCpuExceptionHandlerLib. See: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703 - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module"), part of the series linked above. Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all PEIMs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477 Since at the moment we have no resolution in place that would cover this for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy to do. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySizeLaszlo Ersek2016-07-151-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | No module in OvmfPkg uses these PCDs any longer. The first PCD mentioned is declared by OvmfPkg, so we can remove even the declaration. The second PCD comes from IntelFrameworkModulePkg. The module that consumes PcdS3AcpiReservedMemorySize is called "IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built into OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it depends on the feature PCD called PcdFrameworkCompatibilitySupport, which we never enable in OVMF. The 32KB gap that used to be the S3 permanent PEI memory is left unused in MEMFD for now; it never hurts to have a few KB available there, for future features. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: add PciHotPlugInitDxeLaszlo Ersek2016-07-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation steers the PCI bus driver to reserve the following resources ("padding") for each PCI bus, in addition to the BARs of the devices on that PCI bus: - 2MB of 64-bit non-prefetchable MMIO aperture, - 512B of IO port space. The goal is to reserve room for devices hot-plugged at runtime even if the bridge receiving the device is empty at boot time. The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is actually only 1/8th of the PCI spec mandated reservation, but the specified size of 4096 has proved wasteful (given the limited size of our IO port space -- see commit bba734ab4c7c). Especially on Q35, where every PCIe root port and downstream port qualifies as a separate bridge (capable of accepting a single device). Test results for this patch: - regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit, - although we request 512B alignment for the IO port space reservation, the next upstream bridge rounds it up to 4096B. Cc: "Johnson, Brian J." <bjohnson@sgi.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
* OvmfPkg: add a Name GUID to each Firmware VolumeLaszlo Ersek2016-07-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but the detailed description can be found in Volume 3 of the Platform Init spec (which is at 1.4a currently). Adding an FvNameGuid statement to [FV.xxx] has the following effects (implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"): - The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not directly, see below). - An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to address. This object is not followed by any EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only specifies the Name GUID for the firmware volume. The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found in the Build directory as a separate file (20 bytes in size): Build/Ovmf*/*_GCC*/FV/*.ext - The new data consume 48 bytes in the following volumes: SECFV, FVMAIN_COMPACT, DXEFV. They comprise: - 16 padding bytes, - EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize fields, and Type=EFI_FV_FILETYPE_FFS_PAD), - EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above), - 4 padding bytes. (The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point immediately past EFI_FIRMWARE_VOLUME_HEADER.) The sizes of the firmware volumes don't change, only their internal usages grow by 48 bytes. I verified that the statements and calculations in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid. - The new data consume 0 bytes in PEIFV. This is because PEIFV has enough internal padding at the moment to accomodate the above structures without a growth in usage. In the future, firmware volumes can be identified by Name GUID (Fv(...) device path nodes), rather than memory location (MemoryMapped(...) device path nodes). This is supposed to improve stability for persistent device paths that refer to FFS files; for example, UEFI boot options. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Re-add the Driver Health ManagerBruce Cran2016-06-281-0/+1
| | | | | | | | | | | | | | | The Driver Health HII menu is not an integral part of the MdeModulePkg BDS driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now we have to get the same functionality explicitly from DriverHealthManagerDxe. Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: raise DXEFV size to 10 MBGary Lin2016-05-311-3/+3
| | | | | | | | | | | | | | | | | | | | | | | We reached the size limit again. Building OVMF with the following command $ ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D HTTP_BOOT_ENABLE and it ended up with GenFds.py... GenFv: ERROR 3000: Invalid : error 7000: Failed to generate FV the required fv image size 0x900450 exceeds the set fv image size 0x900000 Since the new UEFI features, such as HTTPS, are coming, we need a larger DEXFV eventually. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSMLaszlo Ersek2016-05-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to edk2 commit "MdeModulePkg/PciBus: do not improperly degrade resource" and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the Platform Init 1.4a specification, a platform can provide such a protocol in order to influence the PCI resource allocation performed by the PCI Bus driver. In particular it is possible instruct the PCI Bus driver, with a "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit address space, regardless of whether the device features an option ROM. (By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS binary from a combined option ROM could be dispatched, and fail to access MMIO BARs in 64-bit address space.) In platform code we can ascertain whether a CSM is present or not. If not, then legacy BIOS binaries in option ROMs can't be dispatched, hence the BAR degradation is detrimental, and we should prevent it. This is expected to conserve the 32-bit address space for 32-bit MMIO BARs. The driver added in this patch could be simplified based on the following facts: - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence the driver will exit immediately. Therefore the driver could be omitted from the Ia32 build. - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE was defined (because in that case the degradation would be justified). On the other hand, if CSM_ENABLE was undefined, then the driver could be included, and it could provide the hint unconditionally (without looking for the Legacy BIOS protocol). These short-cuts are not taken because they would increase the differences between the OVMF DSC/FDF files. If we can manage without extreme complexity, we should use dynamic logic (vs. build time configuration), plus keep conditional compilation to a minimum. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: remove USE_OLD_BDS build fallback macroLaszlo Ersek2016-05-251-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reasons: - USE_OLD_BDS requires duplicating updates between OVMF's library instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples: d5aee61bfaaa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 1da761664949 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 - The Xen community has embraced the new BDS. Examples: 14b2ebc30c8b OvmfPkg/PlatformBootManagerLib: Postpone the shell registration 49effaf26ec9 OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over Xen - OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as NetworkPkg/HttpBootDxe now requires UefiBootManagerLib: 50a65824c74a NetworkPkg: Use UefiBootManagerLib API to create load option. We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is TRUE. - The new BDS has been working well; for example it's the only BDS available in ArmVirtPkg: 1946faa710e6 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Modify FDF/DSC files for RamDiskDxe's adding NFIT report featureHao Wu2016-05-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | The RamDiskDxe driver in MdeModulePkg now will use EFI_ACPI_TABLE_PROTOCOL and EFI_ACPI_SDT_PROTOCOL during reporting RAM disks to NVDIMM Firmware Interface Table (NFIT). A Pcd 'PcdInstallAcpiSdtProtocol' controls whether the EFI_ACPI_SDT_PROTOCOL will be produced. Its default value is set to FALSE in MdeModulePkg. To make the NFIT reporting feature working properly under OVMF, the patch will set the Pcd to TRUE in OVMF DSC files. Also, the RamDiskDxe driver will sometimes report a NVDIMM Root Device using ASL code which is put in a Secondary System Description Table (SSDT) according to the ACPI 6.1 spec. Locating the SSDT requires modifying the [Rule.Common.DXE_DRIVER] field in OVMF FDF files. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
* OvmfPkg: Use MdeModulePkg/BDSRuiyu Ni2016-05-041-0/+5
| | | | | | | | | | | | By default the new MdeModulePkg/BDS is used. If USE_OLD_BDS is defined to TRUE, IntelFrameworkModulePkg/BDS is used. Fixes: https://github.com/tianocore/edk2/issues/62 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: remove USE_OLD_PCI_HOST build optionLaszlo Ersek2016-04-071-4/+0
| | | | | | | | | | | | | | | | | | It's been a month since the following commits appeared in the repo: 4014885ffdfa8 OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe c47ed6fcb5e60 OvmfPkg: match PCI config access to machine type (if not USE_OLD_PCI_HOST) in which we introduced the USE_OLD_PCI_HOST fallback, and made other work depend on it. I have not heard of any problems (primarily from the vfio-users group that uses Gerd's daily / hourly OVMF builds), so it's time to drop the fallback. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Convert to using FatPkg in the EDK II treeJordan Justen2016-04-071-1/+1
| | | | | | | | | | | | | Now that FatPkg is open source (and therefore can be included in the EDK II tree) we build and use it directly. Build tested with GCC 5.3 on IA32 and X64. Boot tested to UEFI Shell on IA32 and UEFI Linux on X64. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Retire AcpiS3SaveDxeStar Zeng2016-04-071-2/+1
| | | | | | | | | | | | | The same functional code has been in S3SaveStateDxe, OVMF AcpiS3SaveDxe can be retired now. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include Virtio10DxeLaszlo Ersek2016-04-061-0/+1
| | | | | | | | Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Add RAM disk supportAlcantara, Paulo2016-04-011-0/+1
| | | | | | | | | | | | | | | Currently booting off of a RAM disk is not supported by IntelFrameWorkModulePkg BDS, however on systems without writable disks, the RAM disk can be made useful when loading raw HDD images into it -- specially the ones with a FAT32 partition on which files can be natively accessed by system firmware. This patch adds RamDiskDxe driver by default in OVMF platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <paulo.alc.cavalcanti@hp.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxeLaszlo Ersek2016-03-031-0/+4
| | | | | | | | | | | | | | | | | | | | | The old driver is retained for now; it remains available with "-D USE_OLD_PCI_HOST". This is because I'd like to involve end users and downstreams in testing the new drier, but also allow them to switch back to the old driver at the first sight of trouble, while we debug the new driver in parallel. In a few weeks the ifdeffery and the "OvmfPkg/PciHostBridgeDxe/" driver should be removed. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: add driver for Virtio-RNG deviceArd Biesheuvel2016-02-241-0/+1
| | | | | | | | | | | This adds the new Virtio-RNG DXE module to all three builds of OvmfPkg. Note that QEMU needs to be invoked with the 'device virtio-rng-pci' option in order for this device to be exposed to the guest. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include NvmExpressDxe driverLaszlo Ersek2016-02-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | QEMU emulates NVMe. NvmExpressDxe seems to work well with it. The relevant QEMU options are -drive id=drive0,if=none,format=FORMAT,file=PATHNAME \ -device nvme,drive=drive0,serial=SERIAL where the required SERIAL value sets the Serial Number (SN) field of the "Identify Controller Data Structure". It is an ASCII string with up to 20 characters, which QEMU pads with spaces to maximum length. (Refer to "NVME_ADMIN_CONTROLLER_DATA.Sn" in "MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h".) Cc: Vladislav Vovchenko <vladislav.vovchenko@sk.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Reference: https://github.com/tianocore/edk2/issues/48 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Vladislav Vovchenko <vladislav.vovchenko@sk.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19791 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Increase default RELEASE build image size to 2MBJordan Justen2016-01-291-12/+0
| | | | | | | | | | | | Fixes: https://github.com/tianocore/edk2/issues/47 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Bruce Cran <bruce@cran.org.uk> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19775 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in SMM-based variable driver stackLaszlo Ersek2015-11-301-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | When -D SMM_REQUIRE is given, replace both - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and - OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf with - OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf. The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and the rest: - the privileged half of the variable driver, VariableSmm, - the fault tolerant write driver, FaultTolerantWriteSmm, - and the FVB driver, FvbServicesSmm, work in SMM purely. We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the authenticated VariableSmm driver's sake. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19065 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: consolidate variable driver stack in DSC and FDF filesLaszlo Ersek2015-11-301-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | The following modules constitute the variable driver stack: - QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime alternatives for providing the Firmware Volume Block(2) Protocol, dependent on qemu pflash presence, - FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol, - MdeModulePkg/Universal/Variable/RuntimeDxe, independently of -D SECURE_BOOT_ENABLE, providing the Variable and Variable Write Architectural Protocols. Let's move these drivers closer to each other in the DSC and FDF files, so that we can switch the variable driver stack to SMM with more local changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19064 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build PiSmmCpuDxeSmm for -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | At this point we can enable building PiSmmCpuDxeSmm. CPU specific features, like SMRR detection, and functions that are used to initialize SMM and process SMIs, are abstracted through the SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with QEMU's and KVM's 64-bit state save map format, which follows the definition from AMD's programmer manual. SmmCpuPlatformHookLib provides platform specific functions that are used to initialize SMM and process SMIs. Resolve it to the one Null instance provided by UefiCpuPkg, which is expected to work for most platforms. Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own instance] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: build CpuS3DataDxe for -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA structure -- created by a platform- and CPU-specific driver -- in order to support ACPI S3. The address of this structure is communicated through the dynamic PCD PcdCpuS3DataAddress. The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of this structure in detail. The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates the structure in a conformant way, and it co-operates well with PiSmmCpuDxeSmm, for OVMF's purposes. PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei (DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM) -------------- --------------- ---------------- -------------- normal collects data boot except MTRR settings into ACPI_CPU_DATA sets PcdCpuS3Da... signals End-of-Dxe | +----------> collects MTRR settings into ACPI_CPU_DATA installs [Dxe]Smm ReadyToLock | +---------------------------> fetches PcdCpuS3Dat... copies ACPI_CPU_DATA into SMRAM runtime S3 suspend S3 transfers resume control to PiSmmCpuDxe... | uses <----+ ACPI_CPU_DATA from SMRAM Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19060 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: LockBox: use SMM stack with -D SMM_REQUIRELaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During DXE, drivers save data in the LockBox. A save operation is layered as follows: - The unprivileged driver wishing to store data in the LockBox links against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf" library instance. The library allows the unprivileged driver to format requests for the privileged SMM LockBox driver (see below), and to parse responses. We apply this resolution for DXE_DRIVER modules. - The privileged SMM LockBox driver is built from "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver has module type DXE_SMM_DRIVER and can access SMRAM. The driver delegates command parsing and response formatting to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf". Therefore we include this DXE_SMM_DRIVER in the build, and apply said resolution specifically to it. (Including the driver requires us to resolve a few of other library classes for DXE_SMM_DRIVER modules.) - In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei) retrieves data from the LockBox. It is capable of searching SMRAM itself. We resolve LockBoxLib to "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically for this one PEIM. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19048 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in CpuIo2Smm driverLaszlo Ersek2015-11-301-0/+9
| | | | | | | | | | | | | | | This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends on in its gEfiDxeSmmReadyToLockProtocolGuid callback (SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c"). Approached on a higher level, this driver provides the SmmIo member of the EFI_SMM_SYSTEM_TABLE2 (SMST). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19044 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: pull in the SMM IPL and SMM coreLaszlo Ersek2015-11-301-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER) implements the SMM Initial Program Loader. It produces EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on: - EFI_SMM_ACCESS2_PROTOCOL (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf), - EFI_SMM_CONTROL2_PROTOCOL (provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf). (The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this dependency is not enforced in the entry point. A protocol notify callback is registered instead, hence we can delay providing that protocol via the PiSmmCpuDxeSmm driver that is (to be) imported from UefiCpuPkg/.) The SMM IPL loads the SMM core into SMRAM and executes it from there. Therefore we add the SMM core to the build as well. For the SMM core, a number of library classes need to be resolved. Furthermore, each FDF file must provide the GenFds.py BaseTools utility with a build rule for SMM_CORE; we copy the DXE_CORE's rule. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19043 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVERLaszlo Ersek2015-11-301-0/+1
| | | | | | | | | | | | | The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the mSmmControl2->Trigger() call in the SmmCommunicationCommunicate() function [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19042 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: add DXE_DRIVER for providing TSEG-as-SMRAM during boot-time DXELaszlo Ersek2015-11-301-0/+4
| | | | | | | | | | | | | | | The SMM core depends on EFI_SMM_ACCESS2_PROTOCOL. This small driver (which is a thin wrapper around "OvmfPkg/SmmAccess/SmramInternal.c" that was added in the previous patch) provides that protocol. Notably, EFI_SMM_ACCESS2_PROTOCOL is for boot time only, therefore our MODULE_TYPE is not DXE_RUNTIME_DRIVER. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19041 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEILaszlo Ersek2015-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the LockBoxLib instance with SMRAM access for the PEI phase. Said library instance must, and can, access the LockBox data in SMRAM directly if it is invoked before SMBASE relocation / SMI handler installation. In that case, it only needs PEI_SMM_ACCESS_PPI from the platform, and it doesn't depend on EFI_PEI_SMM_COMMUNICATION_PPI. OVMF satisfies the description in SVN r18823 ("MdeModulePkg: SmmLockBoxPeiLib: work without EFI_PEI_SMM_COMMUNICATION_PPI"): in OVMF, only S3Resume2Pei links against SmmLockBoxPeiLib. Therefore, introduce a PEIM that produces the PEI_SMM_ACCESS_PPI interface, enabling SmmLockBoxPeiLib to work; we can omit including "UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf". The load / installation order of S3Resume2Pei and SmmAccessPei is indifferent. SmmAccessPei produces the gEfiAcpiVariableGuid HOB during its installation (which happens during PEI), but S3Resume2Pei accesses the HOB only when the DXE IPL calls its S3RestoreConfig2 PPI member, as last act of PEI. MCH_SMRAM_D_LCK and MCH_ESMRAMC_T_EN are masked out the way they are, in SmmAccessPeiEntryPoint() and SmramAccessOpen() respectively, in order to prevent VS20xx from warning about the (otherwise fully intentional) truncation in the UINT8 casts. (Warnings reported by Michael Kinney.) Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19040 6f19259b-4bc3-4df7-8a09-765794883524
* OvmfPkg: Sec: assert the build-time calculated end of the scratch bufferLaszlo Ersek2015-11-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more memory, temporarily, than what PEIFV and DXEFV will ultimately need. First, it uses an output buffer for decompression, second, the decompression itself needs a scratch buffer (and this scratch buffer is the highest area that SEC uses). DecompressMemFvs() used to be called on normal boots only (ie. not on S3 resume), which is why the decompression output buffer and the scratch buffer were allowed to scribble over RAM. However, we'll soon start to worry during S3 resume that the runtime OS might tamper with the pre-decompressed PEIFV, and we'll decompress the firmware volumes on S3 resume too, from pristine flash. For this we'll need to know the end of the scratch buffer in advance, so we can prepare a non-malicious OS for it. Calculate the end of the scratch buffer statically in the FDF files, and assert in DecompressMemFvs() that the runtime decompression will match it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19036 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-15 22:19:16 +0000