Include the VirtioFsDxe driver in the ArmVirtPkg platforms that include
Virtio10Dxe. (The virtio-fs device is virtio-1.0-only.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3097
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201216211125.19496-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
"vm_image: 'ubuntu-latest'" now refers to Ubuntu Focal (20.04LTS), not
Ubuntu Bionic (18.04LTS), according to
<https://github.com/actions/virtual-environments/issues/1816>.
In Focal, the "qemu" package is a dummy package with no dependencies, and
so the actual emulators are not pulled in. Compare:
https://packages.ubuntu.com/bionic/qemuhttps://packages.ubuntu.com/focal/qemu
This causes CI runs to fail.
It would be best to switch to the "qemu-system" package name, which
continues to depend on the emulators:
https://packages.ubuntu.com/bionic/qemu-systemhttps://packages.ubuntu.com/focal/qemu-system
However, while that package does make the emulators available, the
emulators crash. So for now, stick with the previous Ubuntu environment,
which continues to be supported, per
<https://github.com/actions/virtual-environments/issues/1816>.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201217204049.26817-2-lersek@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-7-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
Enable iSCSI.
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Message-Id: <20201112055558.2348-6-zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool is a virtual machine manager that can be used
to launch guest VMs. Support for Kvmtool virtual
platform has been added to ArmVirtPkg.
Add kvmtool to the ArmVirtPkg dictionary to prevent
the CI Spell check plugin from failing.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool emulates a MC146818 RTC controller in the
MMIO space. To support this the MC146818 RTC driver
PcatRealTimeClockRuntimeDxe has been updated to
support MMIO accesses. PCDs for RTC Index and
Target register base addresses in the MMIO space
have been introduced. The KvmtoolRtcFdtClientLib
reads the MC146818 RTC MMIO base address region
from the Kvmtool device tree and updates the
Index and Target register PCDs.
As these PCDs are defined in PcAtChipsetPkg.dec,
this patch updates the CI script to add this
dependency.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool is a virtual machine manager that enables hosting
KVM guests. Kvmtool emulates certain devices like serial
port, RTC, etc. essentially providing a virtual platform.
This patch adds support for kvmtool virtual platform.
Following is a brief description of the firmware
implementation choices:
- Serial Port: 16550 UART
On some platforms the 16550 UART is interfaced using
PCI. Therefore, the 16550 Serial port library is
dependent on the PCI library. The 16550 UART driver
checks the Device ID represented using the PCD
gEfiMdeModulePkgTokenSpaceGuid.PcdSerialPciDeviceInfo
to determine if the UART is behind PCI.
If the Device ID is 0xFF then the serial 16550 UART
is not behind PCI.
On Kvmtool the Serial 16550 UART is not behind PCI,
and therefore a combination of BasePciLibPciExpress
and BasePciExpressLib is used to satisfy the PCI
library dependency.
The PcdSerialPciDeviceInfo is also set to 0xFF to
indicate that the Serial 16550 UART is not behind
PCI. The PCD PcdSerialUseMmio is also set to TRUE
to indicate MMIO accesses are required for the
UART registers.
Additionally two instances of PlatformHookLibs are
provided EarlyFdt16550SerialPortHookLib and
Fdt16550SerialPortHookLib to patch the
PcdSerialRegisterBase so that BaseSerialPortLib16550
and retrieve the base address of the 16550 UART.
- Dependency order for Flash
FaultTolerantWriteDxe makes use of PCDs (e.g.
PcdFlashNvStorageFtwSpareBase64 etc.), which in
case of kvmtool will be evaluated based on the CFI
flash base address read from the DT. These variables
are populated in the NorFlashPlatformLib loaded by
ArmVeNorFlashDxe.
This results in a dependency issue with
FaultTolerantWriteDxe. To resolve this make the
NorFlashPlatformLib as a library dependency for
FaultTolerantWriteDxe.
- RTC Controller
A separate patch updates the MC146818 RTC controller
driver to support MMIO accesses.
A KvmtoolRtcFdtClientLib has been introduced to
extract the base addresses of the RTC controller
from the platform device tree and map the RTC
register space as Runtime Memory.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The PlatformPeim() in the PlatformPeiLib is invoked
by the PrePiMain() and provides the platform an
opportunity to setup the plaform specific HOBs.
This PlatfromPeiLib initialises the Kvmtool platform
HOBs like the Fdt, 16550BaseAddress, etc.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The BaseSerialPort16550 library invokes the
PlatformHookSerialPortInitialize() implemented as
part of the PlatformHook library, to perform platform
specific initialization required to enable use of the
16550 device. The BaseSerialPort16550 library uses
the PcdSerialRegisterBase to obtain the base address
of the UART for MMIO operations.
Some VMMs like Kvmtool provide the base address of
the console serial port in the platform device tree.
This patch introduces two instances of the Platform
Hook library:
1. EarlyFdt16550SerialPortHookLib - parses the
platform device tree to extract the base
address of the 16550 UART and update the PCD
PcdSerialRegisterBase.
2. Fdt16550SerialPortHookLib - reads the GUID
Hob gEarly16550UartBaseAddressGuid (that caches
the base address of the 16550 UART discovered
during early stages) and updates the PCD
PcdSerialRegisterBase.
Note:
a. The PCD PcdSerialRegisterBase is configured
as PatchableInModule.
b. A separate patch introduces a PlatformPeiLib
that trampolines the 16550 UART base address
from the Pcd PcdSerialRegisterBase to the
GUID Hob gEarly16550UartBaseAddressGuid.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Introduce a new GUID Hob gEarly16550UartBaseAddressGuid
to cache the base address of the 16550 UART, for when
PCD access is not available.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool places the base address of the CFI flash in
the device tree it passes to UEFI. This library
parses the kvmtool device tree to read the CFI base
address and initialise the PCDs use by the NOR flash
driver and the variable storage.
UEFI takes ownership of the CFI flash hardware, and
exposes its functionality through the UEFI Runtime
Variable Service. Therefore, disable the device tree
node for the CFI flash used for storing the UEFI
variables, to prevent the OS from attaching its device
driver as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Kvmtool is a virtual machine manager that enables
hosting KVM guests. Kvmtool allows to vary the
hardware configuration of the virtual platform
it provides to the guest partition. It provides
the current hardware configuration to the firmware
by handing off a device tree containing the hardware
information.
This library parses the kvmtool provided device
tree and populates the system memory map for the
kvmtool virtual platform.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool is a virtual machine manager that enables
hosting KVM guests. It essentially provides a
virtual hardware platform for guest operating
systems.
Kvmtool hands of a device tree containing the
current hardware configuration to the firmware.
A standards-based operating system would use
ACPI to consume the platform hardware
information, while some operating systems may
prefer to use Device Tree.
The KvmtoolPlatformDxe performs the platform
actions like determining if the firmware should
expose ACPI or the Device Tree based hardware
description to the operating system.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Add library that parses the Kvmtool device tree and updates
the dynamic PCDs describing the RTC Memory map.
It also maps the MMIO region used by the RTC as runtime memory
so that the RTC registers are accessible post ExitBootServices.
Since UEFI takes ownership of the RTC hardware disable the RTC
node in the DT to prevent the OS from attaching its device
driver as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Updates the DSC for the ArmVirtPkg platform to add a RngLib that uses the
TimerLib. This is due to a later change that adds TimerLib as a dependency
for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL
previously and it is recommended to switch to a better source of
entropy than the system's performance counter.
Ref: https://github.com/tianocore/edk2/pull/845
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
Our UEFI guest firmware takes ownership of the emulated NOR flash in
order to support the variable runtime services, and it does not expect
the OS to interfere with the underlying storage directly. So disable
the NOR flash DT nodes as we discover them, in a way similar to how we
disable the PL031 RTC in the device tree when we attach our RTC runtime
driver to it.
Note that this also hides the NOR flash bank that carries the UEFI
executable code, but this is not intended to be updatable from inside
the guest anyway, and if it was, we should use capsule update to do so.
Also, the first -pflash argument that defines the backing for this flash
bank is often issued with the 'readonly' modifier, in order to prevent
any changes whatsoever to be made to the executable firmware image by
the guest.
This issue has become relevant due to the following Linux changes,
which enable the flash driver stack for default build configurations
targetting arm64 and 32-bit ARM.
ce693fc2a877
("arm64: defconfig: Enable flash device drivers for QorIQ boards", 2020-03-16).
5f068190cc10
("ARM: multi_v7_defconfig: Enable support for CFI NOR FLASH", 2019-04-03)
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
We no longer use ELF PIE executables to implement the self-relocating
PrePi so drop the custom linker script and visibility override header
file.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
Instead of having a GCC specific routine to perform self-relocation
based on ELF metadata, use the PE/COFF metadata and the existing
PeCoff library routines. This reduces the amount of bespoke assembler
code that is a burden to maintain, and is not portable across the set
of toolchains we support.
This does require some special care, as we have no control over how
the C code references global symbols, so we need to emit these
references from the calling assembler code. Otherwise, they may be
emitted as absolute references, in which case they need to be fixed
up themselves, leading to a circular dependency.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
In preparation for making the self-relocating PrePi use the ordinary
BasePeCoffLib routines for relocating the image in place in memory
at start, add a special FDF rule that builds SEC modules as PE32
images with the relocation metadata preserved.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
Port the DSC file changes from the similarly titled OvmfPkg patch in this
series to ArmVirtPkg.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-8-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
We don't distribute UEFI_DRIVER modules stand-alone that were built as
part of an ArmVirtQemu* platform. ArmVirtQemu* UEFI_DRIVERs are allowed to
inherit platform dependencies.
By enabling UEFI_DRIVERs to consume QemuFwCfgLib, we can hook fw_cfg-based
NULL class libraries into UEFI drivers, e.g. in order to set dynamic PCDs.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-7-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This reverts commit e069278905.
The default value for PcdAcpiExposedTableVersions is now set to 0x20
for Aarch64 systems. Setting this PCD in ArmVirtPkg/ArmVirtQemu.dsc
is no longer necessary.
Signed-off-by: Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Enable support for NVMe storage in ArmVirtQemu/QemVirtQemuKernel in order
to simplify booting/installing operating systems that don't support
virtio.
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Older GCC (<= 4.9) fail to infer that Parent is never used unless it
has been assigned before, and may throw an error like
/work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:
In function ‘PlatformPeim’:
/work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:132:24:
error: ‘Parent’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
RangesProp = fdt_getprop (Base, Parent, "ranges", &RangesLen);
Set Parent to 0 at the start of the sequence to work around this.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2601
Fixes: 82662a3b5f ("ArmVirtPkg/PlatformPeiLib: discover the TPM base ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtGicArchLib was originally implemented before virtualization
emulation was implemented in QEMU, and the GICv2 model implemented only
the physical copy of control registers.
Enabling virtualization emulation to QEMU adds also the virtual copy,
doubling the RegSize returned by FindCompatibleNodeReg () in
ArmVirtGicArchLibConstructor (). This triggered an ASSERT when running
QEMU with -M virt,virtualization=on. Address this by testing for both
possible valid values of RegSize.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2588
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Drop the QEMU loader file system implementation inside this library,
and switch to the separate QemuLoadImageLib library and the associated
driver to expose the kernel and initrd passed via the QEMU command line.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add the QEMU loader DXE driver and client library to the build for
our QEMU targeted implementations in ArmVirtPkg.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Set the Timeout global variable to the same value as
PcdPlatformBootTimeOut. This way the "setvar" command in the UEFI shell,
and the "efibootmgr" command in a Linux guest, can report the front page
timeout that was requested on the QEMU command line (see
GetFrontPageTimeoutFromQemu()).
A DEBUG_VERBOSE message is logged on success too, for our QE team's sake.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200304094413.19462-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
We're going to switch the internal line terminators globally to LF at some
point, but until then, let's use CRLF consistently. Convert source files
with LFs in them to CRLF, using "unix2dos".
"git show -b" prints no code changes for this patch.
(I collected all the file name suffixes in this package, with:
$ git ls-files -- $PACKAGE | rev | cut -f 1 -d . | sort -u | rev
I eliminated those suffixes that didn't stand for text files, then
blanket-converted the rest with unix2dos. Finally, picked up the actual
changes with git-add.)
The CRLF conversion is motivated by "PatchCheck.py".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1659
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200227213903.13884-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Now that all the TPM2 related plumbing is in place, we can add the
final piece that performs the measurements of loaded images into
the appropriate PCRs.
This patch ports commit d5a002aba0 ("OvmfPkg: plug
DxeTpm2MeasureBootLib into SecurityStubDxe", 2018-03-09) to ArmVirtQemu.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Enable the DXE phase component that publishes the HII pages and
associated logic to enable TPM2 parameters to be configured by
the user via the setup menu.
This patch ports (parts of) the following commits to ArmVirtQemu:
- 3103389043 ("OvmfPkg: Add TCG2 Configuration menu to the Device
Manager menu", 2019-02-11)
- cf3ad972a2 ("OvmfPkg: reorganize TPM2 support in DSC/FDF files",
2020-01-09)
- f55477fe2d ("OvmfPkg: use HII type PCDs for TPM2 config related
variables", 2020-01-09)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Enable the TPM2 support module in the DXE phase, and the associated
libraries and PCDs that it requires. This will be wired into the
measured boot support code in a subsequent patch.
Note that Tcg2Dxe.inf is added to ArmVirtQemuFvMain.fdf.inc, which
is shared with other platforms in ArmVirtPkg, but as those will not
set the TPM2_ENABLE define, this change does not affect them.
This patch ports (parts of) the following OvmfPkg commits to
ArmVirtQemu:
- 0c0a50d6b3 ("OvmfPkg: include Tcg2Dxe module", 2018-03-09)
- b9777bb42e ("OvmfPkg: add Tcg2PhysicalPresenceLibQemu", 2018-05-22)
-- only to match OVMF's current lib class resolutions
- 1ec05b81e5 ("OvmfPkg: use DxeTpmMeasurementLib if and only if
TPM2_ENABLE", 2019-07-04)
- b9130c866d ("OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei
and Tcg2Dxe", 2018-08-16)
- 5d3ef15da7 ("OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe",
2019-07-19)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In preparation of conditializing the choice of resolution based on
TPM2_ENABLE for ArmVirtQemu, move the TpmMeasurementLib out of the
shared .DSC include and into the individual DSCs.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
DxeTpmMeasurementLib should only be used on platforms that implement
measured boot, which we will do in a future patch, but only for
ArmVirtQemu, as the remaining ones are fundamentally incompatible,
given that they do not implement a PEI phase.
So use TpmMeasurementLibNull as the default resolution for all
ArmVirtPkg platforms, regardless of how they are built.
This mirrors commit 1ec05b81e5 ("OvmfPkg: use DxeTpmMeasurementLib
if and only if TPM2_ENABLE", 2019-07-04).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Incorporate the PEI components and the associated library class
resolutions and PCD declarations to enable TPM2 support in the
PEI phase.
This patch ports (parts of) the following OvmfPkg commits to
ArmVirtQemu:
- 6cf1880fb5 ("OvmfPkg: add customized Tcg2ConfigPei clone",
2018-03-09)
- 4672a48928 ("OvmfPkg: include Tcg2Pei module", 2018-03-09)
- b9130c866d ("OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei
and Tcg2Dxe", 2018-08-16)
- 5d3ef15da7 ("OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe",
2019-07-19)
gEfiSecurityPkgTokenSpaceGuid.PcdTpm2HashMask defaults to 0x0 so
that the TPM init code adopts the currently active PCR banks as
the ones that are enabled by default.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
As a first step in gradually adding TPM2 support to ArmVirtQemu, add
the TPM2_ENABLE configurable to the [Defines] section, and if it is
set, add the ResetSystem PEIM to the build, along with the library
class references that we will need to support it:
- wire ArmVirtPsciResetSystemPeiLib into the ResetSystem PEIM itself,
which will be in charge of performing the actual reset
- add PeiResetSystemLib as the common ResetSystemLib resolution for
PEIM class modules, so that other PEIMs will invoke the PPI
published by the ResetSystem PEIM.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Implement a ArmVirtPkg specific version of the PSCI ResetSystemLib that
is usable in the PEI phase, as the existing one relies on the FDT client
protocol, making it unsuitable.
Note that accessing the device tree passed by QEMU via its initial base
address is guaranteed to be safe at any time during the PEI phase, so we
can defer discovery of the PSCI method until the time the reset library
is actually invoked (which is rarely)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Introduce a boolean PCD that tells us whether TPM support is enabled
in the build, and if it is, record the TPM base address in the existing
routine that traverses the device tree in the platform PEIM.
If a TPM is found, install the gOvmfTpmDiscoveredPpiGuid signalling PPI
that will unlock the dispatch of OvmfPkg's Tcg2ConfigPei. If TPM2
support is enabled in the build but no TPM2 device is found, install the
gPeiTpmInitializationDonePpiGuid PPI, which is normally installed by
Tcg2ConfigPei if no TPM2 is found, but in our case Tcg2ConfigPei will
never run so let's do it here instead.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
We currently include PcdLib.h in PlatformPeiLib, without declaring
this dependency in its .INF description. Since all the PCDs we use
resolve to fixed type in practice, this does not really matter at
the moment, but since we will be adding dynamic PCD references in
a subsequent patch, let's make the PcdLib dependency explicit, so
that its dispatch is guaranteed to be ordered correctly with respect
to the provider of the dynamic PCD PPI.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266
Similar to what we now do for OVMF, we need to consider the possibility
that PlatformBootManagerWaitCallback () may be called with a
PcdPlatformBootTimeOut that was set to zero, in which case the call should
simply return.
We also change the initial timeout variable name to make the code explicit.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-3-pete@akeo.ie>
After upgrading the CI system we use for building the ArmVirtPkg
targets, we started seeing failures due to the NOOPT build running
out of space when using the CLANG38 toolchain definition combined
with clang 7.
We really don't want to increase the FD/FV sizes in general to
accommodate this, so parameterize the relevant quantities and
increase them by 50% for NOOPT builds.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The LoadImage() boot service is a bit unusual in that it allocates
resources in a particular failure case; namely, it produces a valid
"ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
happen e.g. when Secure Boot verification fails for the image, but the
platform policy for the particular image origin (such as "fixed media" or
"removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
allows platform logic to selectively override the verification failure,
and launch the image nonetheless.
ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
for the kernel image loaded from fw_cfg -- any LoadImage() error is
considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
other LoadImage() error, we leak the resources associated with
"KernelImageHandle". From a resource usage perspective,
EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
Implement this rollback, without breaking the proper "nesting" of error
handling jumps and labels.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e2
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Michael D Kinney
Laszlo Ersek
Gao, Zhichao
Bret Barkelew
Sami Mujawar
Vladimir Olovyannikov
Matthew Carlson
Shenglei Zhang
Ard Biesheuvel
Sean Brogan
Samer El-Haj-Mahmoud
Leendert van Doorn
Ard Biesheuvel
Leif Lindholm
Pete Batard