summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfPkgX64.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Correct ResourcePublicationLib class name in DSC/INF filesLiming Gao2018-07-241-1/+1
| | | | | | | | | | | ResourcePublicationLib class name is ResourcePublicationLib. INF and DSC files are updated to use the correct one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Signed-off-by: Dongao Guo <dongao.guo@intel.com> [lersek@redhat.com: insert empty line between commit msg body and tags] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add QemuRamfbDxeGerd Hoffmann2018-06-141-0/+1
| | | | | | | | | | | Add a driver for the qemu ramfb display device. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> [lersek@redhat.com: fix INF banner typo] [lersek@redhat.com: make some local variable definitions more idiomatic] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: resolve PciCapLib, PciCapPciSegmentLib, PciCapPciIoLibLaszlo Ersek2018-05-241-0/+3
| | | | | | | | | | | | Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to their single respective instances. Later patches will use these lib classes in OvmfPkg drivers. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: add Tcg2PhysicalPresenceLibQemuMarc-André Lureau2018-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and: - removed all the functions that are unreachable from Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS], or SubmitRequestToPreOSFunction() and ReturnOperationResponseToOsFunction() [called from Tcg2Dxe]. - replaced everything that's related to the TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to the QEMU structures. This commit is based on initial experimental work from Stefan Berger. In particular, he wrote most of QEMU PPI support, and designed the qemu/firmware interaction. Initially, Stefan tried to reuse the existing SecurityPkg code, but we eventually decided to get rid of the variables and simplify the ovmf/qemu version. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: clean up non-idiomatic coding style] [lersek@redhat.com: null mPpi on invalid PPI address] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLEMarc-André Lureau2018-05-221-0/+2
| | | | | | | | | | | This NULL library will let us call Tcg2PhysicalPresenceLibProcessRequest() unconditionally from BdsPlatform when building without TPM2_ENABLE. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> [lersek@redhat.com: replace MdeModulePkg.dec w/ MdePkg.dec] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxeLaszlo Ersek2018-04-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight years, no driver or application seems to have materialized that produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF includes) as RamDiskDxe. Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver, remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that now becomes unused too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926 Reported-by: Steven Shi <steven.shi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS bootLaszlo Ersek2018-03-301-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce TlsAuthConfigLib to read the list of trusted CA certificates from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE. The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust" utilities on the host side, so that the host settings take effect in guest HTTPS boot as well. QEMU forwards the file intact to the firmware. The contents are sanity-checked by NetworkPkg/HttpDxe code that was added in commit 0fd13678a681. Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user) and for NetworkPkg/HttpDxe (for the effective TLS configuration). The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the Mozilla CA root certificate bundle -- installed with the "ca-certificates" package -- is processed into a 182KB file. Thus, create EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable. Also, in TLS_ENABLE builds, set the cumulative limit for volatile variables (PcdVariableStoreSize) to 512KB, and the individual limit for the same (PcdMaxVolatileVariableSize) to 256KB. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: annotate "PcdVariableStoreSize := PcdFlashNvStorageVariableSize"Laszlo Ersek2018-03-301-0/+2
| | | | | | | | | | | | | | | | | As a continuation of the last patch, clarify in the DSC files that we set PcdVariableStoreSize to the same value as PcdFlashNvStorageVariableSize just for convenience; the equality is not a technical requirement. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxeMarc-André Lureau2018-03-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The library registers a security management handler, to measure images that are not measure in PEI phase. For example with the qemu PXE rom: Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi And the following binary_bios_measurements log entry seems to be added: PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4 The following order of operations ensures that 3rd party UEFI modules, such as PCI option ROMs and other modules possibly loaded from outside of firmware volumes, are measured into the TPM: (1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2 protocol sometime in the DXE phase (assuming a TPM2 chip is present, reported via PcdTpmInstanceGuid). (2) The DXE core finds that no more drivers are left to dispatch from DXEFV, and we enter the BDS phase. (3) OVMF's PlatformBootManagerLib connects all PCI root bridges non-recursively, producing PciIo instances and discovering PCI oproms. (4) The dispatching of images that don't originate from FVs is deferred at this point, by "MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c". (5) OVMF's PlatformBootManagerLib signals EndOfDxe. (6) OVMF's PlatformBootManagerLib calls EfiBootManagerDispatchDeferredImages() -- the images deferred in step (4) are now dispatched. (7) Image dispatch invokes the Security / Security2 Arch protocols (produced by SecurityStubDxe). In this patch, we hook DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch will try to locate the TCG2 protocol, and measure the image into the TPM2 chip with the protocol. Because of step (1), the TCG2 protocol will always be found and used (assuming a TPM2 chip is present). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include Tcg2Dxe moduleMarc-André Lureau2018-03-091-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This module measures and log the boot environment. It also produces the Tcg2 protocol, which allows for example to read the log from OS. The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2, which is required for crypto-agile log. In fact, only upcoming 4.16 adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2: [ 0.000000] efi: EFI v2.70 by EDK II [ 0.000000] efi: SMBIOS=0x3fa1f000 ACPI=0x3fbb6000 ACPI 2.0=0x3fbb6014 MEMATTR=0x3e7d4318 TPMEventLog=0x3db21018 $ python chipsec_util.py tpm parse_log binary_bios_measurements [CHIPSEC] Version 1.3.5.dev2 [CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module) [CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements'] PCR: 0 type: EV_S_CRTM_VERSION size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29 + version: PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc + base: 0x820000 length: 0xe0000 PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c + base: 0x900000 length: 0xa00000 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0 PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e PCR: 7 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74 PCR: 1 type: EV_EFI_VARIABLE_BOOT size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c PCR: 4 type: EV_EFI_ACTION size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256 PCR: 0 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 1 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 2 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 3 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 4 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 PCR: 5 type: EV_SEPARATOR size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473 $ tpm2_pcrlist sha1 : 0 : 35bd1786b6909daad610d7598b1d620352d33b8a 1 : ec0511e860206e0af13c31da2f9e943fb6ca353d 2 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 3 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 4 : 45a323382bd933f08e7f0e256bc8249e4095b1ec 5 : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b 6 : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236 7 : 518bd167271fbb64589c61e43d8c0165861431d8 8 : 0000000000000000000000000000000000000000 9 : 0000000000000000000000000000000000000000 10 : 0000000000000000000000000000000000000000 11 : 0000000000000000000000000000000000000000 12 : 0000000000000000000000000000000000000000 13 : 0000000000000000000000000000000000000000 14 : 0000000000000000000000000000000000000000 15 : 0000000000000000000000000000000000000000 16 : 0000000000000000000000000000000000000000 17 : ffffffffffffffffffffffffffffffffffffffff 18 : ffffffffffffffffffffffffffffffffffffffff 19 : ffffffffffffffffffffffffffffffffffffffff 20 : ffffffffffffffffffffffffffffffffffffffff 21 : ffffffffffffffffffffffffffffffffffffffff 22 : ffffffffffffffffffffffffffffffffffffffff 23 : 0000000000000000000000000000000000000000 sha256 : 0 : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c 1 : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8 2 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 3 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 4 : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35 5 : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0 6 : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969 7 : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068 8 : 0000000000000000000000000000000000000000000000000000000000000000 9 : 0000000000000000000000000000000000000000000000000000000000000000 10 : 0000000000000000000000000000000000000000000000000000000000000000 11 : 0000000000000000000000000000000000000000000000000000000000000000 12 : 0000000000000000000000000000000000000000000000000000000000000000 13 : 0000000000000000000000000000000000000000000000000000000000000000 14 : 0000000000000000000000000000000000000000000000000000000000000000 15 : 0000000000000000000000000000000000000000000000000000000000000000 16 : 0000000000000000000000000000000000000000000000000000000000000000 17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 23 : 0000000000000000000000000000000000000000000000000000000000000000 sha384 : The PhysicalPresenceLib is required, it sets some variables, but the firmware doesn't act on it yet. Laszlo Ersek explained on the list why Tpm2DeviceLib has to be resolved differently for DXE_DRIVER modules in general and for "Tcg2Dxe.inf" specifically: * We have a library class called Tpm2DeviceLib -- this is basically the set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h". Its leading comment says "This library abstract how to access TPM2 hardware device". There are two *sets* of APIs in "Tpm2DeviceLib.h": (a) functions that deal with the TPM2 device: - Tpm2RequestUseTpm(), - Tpm2SubmitCommand() This set of APIs is supposed to be used by clients that *consume* the TPM2 device abstraction. (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be used by *providers* of various TPM2 device abstractions. * Then, we have two implementations (instances) of the Tpm2DeviceLib class: (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the APIs listed under (a), and it does not implement (b) -- see EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for drivers that *consume* the TPM2 device abstraction. And, the (a) group of APIs is implemented by forwarding the requests to the TCG2 protocol. The idea here is that all the drivers that consume the TPM2 abstraction do not have to be statically linked with a large TPM2 device library instance; instead they are only linked (statically) with this "thin" library instance, and all the actual work is delegated to whichever driver that provides the singleton TCG2 protocol. (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant for the driver that offers (produces) the TCG2 protocol. This lib instance implements both (a) and (b) API groups. * Here's how things fit together: (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf" library instance (which has no lib class) is linked into "Tcg2Dxe.inf" via NULL class resolution. This simply means that before the "Tcg2Dxe.inf" entry point function is entered, the constructor function of "Tpm2InstanceLibDTpm.inf" will be called. (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and registers its own actual TPM2 command implementation with the "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe driver). This provides the back-end for the API set (a). TCG2 protocol provider (Tcg2Dxe.inf driver) launches | v NULL class: Tpm2InstanceLibDTpm instance construction | v Tpm2DeviceLib class: Tpm2DeviceLibRouter instance backend registration for API set (a) (iii) The Tcg2Dxe driver exposes the TCG2 protocol. (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls land in Tcg2Dxe, via the protocol. (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a) from lib instance (2). (vi) Those functions call the "backend" functions registered by Tpm2DeviceLibDTpm in step (ii). TPM 2 consumer driver | v Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance | v TCG2 protocol interface | v TCG2 protocol provider: Tcg2Dxe.inf driver | v Tpm2DeviceLib class: Tpm2DeviceLibRouter instance | v NULL class: Tpm2InstanceLibDTpm instance (via earlier registration) | v TPM2 chip (actual hardware) * So that is the "router" pattern in edk2. Namely, - Consumers of an abstraction use a thin library instance. - The thin library instance calls a firmware-global (singleton) service, i.e. a PPI (in the PEI phase) or protocol (in the DXE phase). - The PEIM providing the PPI, or the DXE driver providing the protocol, don't themselves implement the actual service either. Instead they offer a "registration" service too, and they only connect the incoming "consumer" calls to the earlier registered back-end(s). - The "registration service", for back-ends to use, may take various forms. It can be exposed globally to the rest of the firmware, as another member function of the PPI / protocol structure. Then backends can be provided by separate PEIMs / DXE drivers. Or else, the registration service can be exposed as just another library API. In this case, the backends are provided as NULL class library instances, and a platform DSC file links them into the PEIM / DXE driver via NULL class resolutions. The backend lib instances call the registration service in their own respective constructor functions. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: include Tcg2Pei moduleMarc-André Lureau2018-03-091-0/+7
| | | | | | | | | | | | | This module will initialize TPM device, measure reported FVs and BIOS version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format compatibility, but the SHA-256 measurements and TCG 2 log format are now recommended. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add customized Tcg2ConfigPei cloneMarc-André Lureau2018-03-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: simplify SecurityStubDxe.inf inclusionMarc-André Lureau2018-03-091-4/+2
| | | | | | | | | SecurityStubDxe.inf should be included unconditionally. Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: drop stale SafeBlockIoLib and SafeOpenProtocolLib resolutionsLaszlo Ersek2018-02-131-2/+0
| | | | | | | | | | | | | These are listed under "ShellPkg/Application/Shell/Shell.inf", but they have been commented out ever since commit 345a0c8fce38 ("OvmfPkg: Add support for UEFI shell", 2011-06-26). No such lib classes exist in edk2. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
* OvmfPkg: Add SafeIntLib and BmpSupportLib to DSC filesMichael D Kinney2018-02-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=800 Based on content from the following branch/commits: https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport https://github.com/Microsoft/MS_UEFI/commit/33bab4031a417d7d5a7d356c15a14c2e60302b2d https://github.com/Microsoft/MS_UEFI/commit/ca516b1a61315c2d823f453e12d2135098f53d61 https://github.com/Microsoft/MS_UEFI/commit/2b9f111f2e74a4c2ef4c4e32379e111f016dbd9b The BootGraphicsResourceTableDxe module uses the BmpSupportLib and SafeIntLib to convert a GOP BLT buffer to a BMP graphics image. Add library mappings for these new library classes. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
* OvmfPkg: Don't add -mno-mmx -mno-sse option for XCODE5 tool chainLiming Gao2018-01-161-1/+3
| | | | | | | | | | | | | | Ovmf appended option -mno-mmx -mno-sse, but these two options were enabled in Openssl. The compiler option becomes -mmmx ?msse -mno-mmx -mno-sse. It trig mac clang compiler hang when compile one source file in openssl. This issue is found when SECURE_BOOT_ENABLE is TRUE. This may be the compiler issue. To work around it, don't add these two options for XCODE5 tool chain. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add tftp dynamic commandRuiyu Ni2017-11-291-2/+5
| | | | | | | | | | | | | | | 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: Fix build failure due to Tftp library removalRuiyu Ni2017-11-281-1/+0
| | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
* OvmfPkg: create a separate PlatformDebugLibIoPort instance for SECPaolo Bonzini2017-11-171-1/+1
| | | | | | | | | | | | | | | | | | The next patch will want to add a global variable to PlatformDebugLibIoPort, but this is not suitable for the SEC phase, because SEC runs from read-only flash. The solution is to have two library instances, one for SEC and another for all other firmware phases. This patch adds the "plumbing" for the SEC library instance, separating the INF files and moving the constructor to a separate C source file. Contributed-under: TianoCore Contribution Agreement 1.1 Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: fix dynamic default for oprom verification policy PCD without SBLaszlo Ersek2017-10-191-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I missed the following, both while reviewing and while testing commit 6041ac65ae87 ("OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is active", 2017-10-05): If "-D SECURE_BOOT_ENABLE" is not passed on the "build" command line, then OVMF has no dynamic default at all for "PcdOptionRomImageVerificationPolicy". This means that the PcdSet32S() call added in the subject commit doesn't even compile: > OvmfPkg/PlatformPei/AmdSev.c: In function 'AmdSevInitialize': > OvmfPkg/PlatformPei/AmdSev.c:67:3: error: implicit declaration of > function '_PCD_SET_MODE_32_S_PcdOptionRomImageVerificationPolicy' > [-Werror=implicit-function-declaration] > PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4); > ^ > cc1: all warnings being treated as errors Make the current, SB-only, 0x00 dynamic default unconditional. This is the simplest approach, and it reflects the intent of original commit 1fea9ddb4e3f ("OvmfPkg: execute option ROM images regardless of Secure Boot", 2016-01-07). Without SECURE_BOOT_ENABLE, "SecurityPkg/Library/DxeImageVerificationLib" is not used anyway, so the PCD is never read. This issue was first caught and reported by Gerd Hoffmann <kraxel@redhat.com>'s Jenkins CI. Later it was also reported in <https://bugzilla.tianocore.org/show_bug.cgi?id=737>. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: 6041ac65ae879389f3ab5c0699f916d3e71c97fe Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: trim commit message as suggested by Jordan] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: add reference to TianoCore BZ#737]
* OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is activeBrijesh Singh2017-10-171-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | The following commit: 1fea9ddb4e3f OvmfPkg: execute option ROM images regardless of Secure Boot sets the OptionRomImageVerificationPolicy to ALWAYS_EXECUTE the expansion ROMs attached to the emulated PCI devices. A expansion ROM constitute another channel through which a cloud provider (i.e hypervisor) can inject a code in guest boot flow to compromise it. When SEV is enabled, the bios code has been verified by the guest owner via the SEV guest launch sequence before its executed. When secure boot, is enabled, lets make sure that we do not allow guest bios to execute a code which is not signed by the guest owner. Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728 Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.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: update PciHostBridgeDxe to use PlatformHasIoMmuLibBrijesh Singh2017-07-101-0/+1
| | | | | | | | | | | | | | This patch enables PciHostBridgeDxe driver to use Platform IoMMU detection library to ensure that PciHostBridgeDxe is run after platform IoMmuDxe driver has checked whether platform need to install IOMMU protocol provider. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific libraryBrijesh Singh2017-07-101-1/+2
| | | | | | | | | | | | | Current QemuFwCfgLib.inf is used in both Pei and Dxe phases. Add Pei and Dxe inf file to provide a seperate QemuFwCfgLib instances for Pei and Dxe phases. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@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/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/PlatformPei: Set memory encryption PCD when SEV is enabledBrijesh Singh2017-07-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Secure Encrypted Virtualization (SEV) guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit. When building the initial page table we mark all the memory as private. The patch sets the memory encryption PCD. The PCD is consumed by the following edk2 modules, which manipulate page tables: - PEI phase modules: CapsulePei, DxeIplPeim, S3Resume2Pei. CapsulePei is not used by OVMF. DxeIplPeim consumes the PCD at the end of the PEI phase, when it builds the initial page tables for the DXE core / DXE phase. S3Resume2Pei does not consume the PCD in its entry point function, only when DxeIplPeim branches to the S3 resume path at the end of the PEI phase, and calls S3Resume2Pei's EFI_PEI_S3_RESUME2_PPI.S3RestoreConfig2() member function. Therefore it is safe to set the PCD for these modules in PlatformPei. - DXE phase modules: BootScriptExecutorDxe, CpuDxe, PiSmmCpuDxeSmm. They are all dispatched after the PEI phase, so setting the PCD for them in PlatformPei is safe. (BootScriptExecutorDxe is launched "for real" in the PEI phase during S3 resume, but it caches the PCD into a static variable when its entry point is originally invoked in DXE.) Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/BaseMemcryptSevLib: Add SEV helper libraryBrijesh Singh2017-07-101-0/+1
| | | | | | | | | | | | | | Add Secure Encrypted Virtualization (SEV) helper library. The library provides the routines to: - set or clear memory encryption bit for a given memory region. - query whether SEV is enabled. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.infBrijesh Singh2017-07-101-1/+1
| | | | | | | | | | | | | | | | | When SEV is enabled then we must unroll the rep String I/O instructions. The patch updates dsc file to use SEV version of IoLib inf. The main difference between BaseIoLibIntrinsic.inf and BaseIoLibIntrinsicSev.inf is, SEV version checks if its running under SEV enabled guest, If so then it unroll the String I/O (REP INS/OUTS) otherwise fallbacks to rep ins/outs. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: make PcdQ35TsegMbytes dynamicLaszlo Ersek2017-07-051-0/+1
| | | | | | | | | | | | | | We can now make PcdQ35TsegMbytes dynamic, in preparation for the extended TSEG size feature. At the moment we only move the declaration in OvmfPkg.dec from [PcdsFixedAtBuild] to [PcdsDynamic, PcdsDynamicEx], and provide the dynamic defaults (with the same value, 8) in the DSC files if SMM_REQUIRE is TRUE. Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: 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: make the 4MB flash size the default (again)Laszlo Ersek2017-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Xen gained support for the 4MB flash image in Xen commit 0d6968635ce5 ("hvmloader: avoid tests when they would clobber used memory", 2017-05-19), which is part of Xen 4.9.0-rc6. The previously default 2MB can be explicitly selected with -D FD_SIZE_2MB or -D FD_SIZE_IN_KB=2048 Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit bba8dfbec3bbc4fba7fa6398ba3cf76593e0725e) Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: reference Xen commit in commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add XCODE5 statements to fix build breakMichael Kinney2017-05-191-0/+2
| | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=559 The XCODE5 tool chain has a FAMILY of GCC. The GCC statements in the [BuildOptions] section add flags that are not compatible with XCODE5. Add empty XCODE5 statements in [BuildOptions] sections to prevent the use of the GCC flags in XCODE5 builds. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: resolve PcdLib for PEIMs to PeiPcdLib by defaultLaszlo Ersek2017-05-181-17/+5
| | | | | | | | | | In the previous patch we had to add two explicit Null resolutions, but here we can remove five PeiPcdLib ones, after setting the default to it. 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: resolve PcdLib for all PEIMs individuallyLaszlo Ersek2017-05-181-2/+8
| | | | | | | | | | | | | | | Currently the default (module type independent) PcdLib resolution is to BasePcdLibNull.inf, which is inherited by all PEIMs. In the next patch, we'll flip the PEIM default resolution to PeiPcdLib.inf, but in order to keep that patch both correct and simple to review, we should spell out the Null resolution for those two PEIMs (ReportStatusCodeRouterPei and StatusCodeHandlerPei) that are now the only ones that don't specify an explicit resolution. 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/PlatformPei: don't allocate reserved mem varstore if SMM_REQUIRELaszlo Ersek2017-05-181-0/+3
| | | | | | | | | | | | | | | | | | | | For the emulated variable store, PlatformPei allocates reserved memory (as early as possible, so that the address remains the same during reboot), and PcdEmuVariableNvStoreReserved carries the address to EmuVariableFvbRuntimeDxe. However, EmuVariableFvbRuntimeDxe is excluded from the SMM_REQUIRE build, and then noone consumes PcdEmuVariableNvStoreReserved. Don't waste reserved memory whenever that's the case. (Even a dynamic default for PcdEmuVariableNvStoreReserved would be unnecessary; but that way the PcdSet64S() call in the ReserveEmuVariableNvStore() function doesn't compile.) 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: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSizeLaszlo Ersek2017-05-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "MdeModulePkg/MdeModulePkg.dec" declares PcdVariableStoreSize like this: > The size of volatile buffer. This buffer is used to store VOLATILE > attribute variables. There is no inherent reason why the size of the volatile variable store should match the same of the non-volatile variable store. Indeed flash variables in the 4MB build work fine without this equality. However, OvmfPkg/EmuVariableFvbRuntimeDxe uses PcdVariableStoreSize to initialize the non-volatile VARIABLE_STORE_HEADER too. (Presumably based on the fact that ultimately that storage will not be permanent.) When using EmuVariableFvbRuntimeDxe in the 4MB build, the mismatch between the two mentioned PCDs (which is apparent through EmuVariableFvbRuntimeDxe's VARIABLE_STORE_HEADER) triggers an assertion in the variable driver: > ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3772): > mNvVariableCache->Size == VariableStoreLength Bringing PcdVariableStoreSize in sync with PcdFlashNvStorageVariableSize fixes this. It also happens to ensure a volatile store size in the 4MB build that equals the non-volatile store size, which likely doesn't hurt for symmetry. Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: b24fca05751f8222acf264853709012e0ab7bf49 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: remove gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnableLaszlo Ersek2017-05-181-3/+0
| | | | | | | | | This PCD is no longer used. 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>
* Revert "OvmfPkg: make the 4MB flash size the default"Laszlo Ersek2017-05-051-1/+1
| | | | | | | | | | | | | | This reverts commit bba8dfbec3bbc4fba7fa6398ba3cf76593e0725e. The 264KB size introduced for the NV spare area in commit b24fca05751f ("OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK", 2017-04-29) breaks the "-bios" (emulated varstore) use case. Until we sort that out, revert the default build to the 2MB image. Suggested-by: 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: make the 4MB flash size the defaultLaszlo Ersek2017-05-051-1/+1
| | | | | | | | | | | | | | | | | The previously default 2MB can be explicitly selected with -D FD_SIZE_2MB or -D FD_SIZE_IN_KB=2048 Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: 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: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MBLaszlo Ersek2017-05-051-0/+6
| | | | | | | | | | | | | | | | | The "ConfirmSetOfLargeVariable" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit sets a 32 KB large non-authenticated variable. In the FD_SIZE_4MB build, our live varstore is now 256 KB big, so we can accommodate this. Set both PcdMaxVariableSize and PcdMaxAuthVariableSize to 0x8400 -- beyond DataSize=0x8000 from the HCK test, we need some room for the variable name and attributes as well. Cc: Gary Ching-Pang Lin <glin@suse.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: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: introduce 4MB flash image (mainly) for Windows HCKLaszlo Ersek2017-05-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware Certification Kit expects to be able to populate the variable store up to roughly 64 KB, with a series of 1 KB sized, unauthenticated variables. OVMF's current live varstore area is too small for this: 56 KB. Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096), which - enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --, - inside that, grows the varstore area / pflash chip to 528 KB, and within it, the live area from 56 KB to 256 KB. Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be compatible with a variable store that originates from a variable store template built *without* -D FD_SIZE_4MB. This is the reason for the large increase, as every such change breaks compatibility between a new firmware binary and old varstore files. Enlarging the varstore does not impact the performance of normal operations, as we keep the varstore block size 4KB. The performance of reclaim is affected, but that is expected (since reclaim has to rework the full live area). And, reclaim occurs proportionally less frequently. While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in it) is also enlarged significantly, so that we have plenty of room for future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing steadily, and that increase shows through compression too. Right now the PEIFV and DXEFV volumes need no resizing. Here's a summary: Description Compression type Size [KB] ------------------------- ----------------- ---------------------- Non-volatile data storage open-coded binary 128 -> 528 ( +400) data Variable store 56 -> 256 ( +200) Event log 4 -> 4 ( +0) Working block 4 -> 4 ( +0) Spare area 64 -> 264 ( +200) FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648) FV FFS file LZMA compressed PEIFV uncompressed 896 -> 896 ( +0) individual PEI uncompressed modules DXEFV uncompressed 10240 -> 10240 ( +0) individual DXE uncompressed modules SECFV uncompressed 208 -> 208 ( +0) SEC driver reset vector code For now, the 2MB flash image remains the default. Cc: Gary Ching-Pang Lin <glin@suse.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: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flagLaszlo Ersek2017-05-051-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FD_SIZE_xMB defines have existed for flash size selection. They can be passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them at the same time has never been supported; earlier settings on the command line cannot be overridden. Introduce the integer valued FD_SIZE_IN_KB macro, which provides the following improvements: - several instances of it are permitted on the command line, with the last one taking effect, - conditional statements in the DSC and FDF files need only check a single macro, and multiple values can be checked in a single !if with the || operator, - nested !ifdef / !else ladders can be replaced with flat equality tests, - in the future, flash sizes can be expressed with a finer than MB granularity, if necessary. For now, we're going to preserve the FD_SIZE_xMB defines as convenience wrappers for FD_SIZE_IN_KB. FD_SIZE_IN_KB is being added to the DSC files because this way we can depend on it in both the DSC and FDF files. Cc: Gary Ching-Pang Lin <glin@suse.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: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: resolve QemuFwCfgS3LibLaszlo Ersek2017-03-141-0/+3
| | | | | | | | | | | | | | | | | | QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c" queries the "etc/system-states" fw_cfg file. The same implementation is now available factored-out in "OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance. Resolve QemuFwCfgS3Lib accordingly. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394 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: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSELaszlo Ersek2017-02-251-0/+4
| | | | | | | | | | | | | | | The OpensslLibCrypto library instance (which does not contain libssl functions) is sufficient for the Secure Boot feature. Ease security analysis by excluding libssl functionality from the OpensslLib instance we use with TLS_ENABLE=FALSE. Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tomas Hoger <thoger@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg: dynamic defaults for PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncModeLaszlo Ersek2017-02-071-2/+5
| | | | | | | | | | | | Move the platform-specific default values for these PCDs from the [PcdsFixedAtBuild] / [PcdsFixedAtBuild.X64] sections to the [PcdsDynamicDefault] section. Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230 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: Allow HTTP connections if HTTP Boot enabledJiaxin Wu2017-01-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | v2 * Move the setting above the "!ifndef $(USE_OLD_SHELL)" part. * Un-indent the setting to column zero. (Comments from Laszlo) Overwrite the value of PcdAllowHttpConnections to allow HTTP connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE). Cc: Laszlo Ersek <lersek@redhat.com> Cc: Justen Jordan L <jordan.l.justen@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Kinney Michael D <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Gary Lin <glin@suse.com> Tested-by: Gary Lin <glin@suse.com>
* OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)Gary Lin2017-01-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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-7/+4
| | | | | | | | | | | | | | | | | | | | | 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: always resolve OpenSslLib, IntrinsicLib and BaseCryptLibGary Lin2017-01-171-6/+3
| | | | | | | | | | | | | | | | | | | | | This commit provides unconditional library resolutions for the OpenSslLib, IntrinsicLib and BaseCryptLib classes, regardless of whether those classes are actually used by any module. Although those libraries depends on OpenSSL, they won't be built unless a module really uses them. Thus, missing OpenSSL from the tree won't cause any build failure as long as SECURE_BOOT_ENABLE is false. (Based on Jiaxin's patch and Laszlo'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>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 05:07:14 +0000