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>
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>
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>
The TFTP command was converted from a NULL class library instance
to a dynamic shell command in commit 0961002352.
This patch complements commit f9bc2f8763, 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>
(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
2bbd7e2fbd ("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
7cb6b0e068 ("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 7cb6b0e068 (see above), there would be no room
left above the 32KB temp SEC/PEI RAM. However, given more recent
commits
45d8708151 ("OvmfPkg/PlatformPei: rebase and resize the permanent
PEI memory for S3", 2016-07-13)
6b04cca4d6 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 a81abf1616 ("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>
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>
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 bba734ab4c). 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>
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>
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>
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>
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>
Reasons:
- USE_OLD_BDS requires duplicating updates between OVMF's library
instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples:
d5aee61bfa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI
spec Mantis 1353
1da7616649 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec
Mantis 1353
- The Xen community has embraced the new BDS. Examples:
14b2ebc30c OvmfPkg/PlatformBootManagerLib: Postpone the shell
registration
49effaf26e 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:
50a65824c7 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:
1946faa710 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>
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>
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>
It's been a month since the following commits appeared in the repo:
4014885ffd OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe
c47ed6fcb5 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>
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>
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>
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>
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>
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>
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
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
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
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
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
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
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
"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
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
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
"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
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
With gcc5 and enabling SECURE_BOOT and NETWORK_IP6, the build
failed with this error:
GenFv: ERROR 3000: Invalid
the required fv image size 0x814c18 exceeds the set fv image size 0x800000
Raise the DXEFV size to 9 MB to fix the build error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18577 6f19259b-4bc3-4df7-8a09-765794883524
In this patch, we replace the traditional IDE driver stack that comes from
PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers
from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible
with the previous one, but provides more protocols, on more kinds of
virtual hardware.
Remove:
- PcAtChipsetPkg/Bus/Pci/IdeControllerDxe/IdeControllerDxe.inf
(removing EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
Remove the dependent:
- IntelFrameworkModulePkg/Bus/Pci/IdeBusDxe/IdeBusDxe.inf
(removing EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3])
As replacement, add:
- OvmfPkg/SataControllerDxe/SataControllerDxe.inf
(supplying EFI_IDE_CONTROLLER_INIT_PROTOCOL [1])
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
(providing EFI_ATA_PASS_THRU_PROTOCOL,
EFI_EXT_SCSI_PASS_THRU_PROTOCOL)
On top of which, add the dependent:
- MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
(supplying EFI_DISK_INFO_PROTOCOL [2],
EFI_BLOCK_IO_PROTOCOL [3],
providing EFI_BLOCK_IO2PROTOCOL,
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL)
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh <reza.jelveh@tuhh.de>
[lersek@redhat.com: rewrote commit message]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18532 6f19259b-4bc3-4df7-8a09-765794883524
Since SVN r18316 / git 5ca29abe52, the HTTP driver needs the HTTP
utilities driver to parse the headers of HTTP requests. Add the driver
into OVMF so that the HTTP driver can work properly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18359 6f19259b-4bc3-4df7-8a09-765794883524
Marc-André Lureau
Ruiyu Ni
Laszlo Ersek
Paulo Alcantara
Brijesh Singh
Gary Lin
Bhupesh Sharma
Cinnamon Shia
Bruce Cran
Hao Wu
Jordan Justen
Star Zeng
Alcantara, Paulo
Ard Biesheuvel
Reza Jelveh