This is the UEFI counterpart to my Linux series which generalizes mixed mode support into a feature that requires very little internal knowledge about the architecture specifics of booting Linux on

EDK2's implementation of the LoadImage() boot service permits non-native binaries to be loaded (i.e., X64 images on IA32 firmware), but any attempts to start such an image using StartImage() will

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

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

Add a new 'initrd' command to the UEFI Shell that allows any file that is accessible to the shell to be registered as the initrd that is returned when Linux's EFI stub loader invokes the LoadFile2

Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions, it can be used in a media device path to specify a Linux style initrd that can be loaded by the OS using the LoadFile2

This is tagged as a v2 since it is a followup to a couple of patches [0][1] that have already been sent to the list. This series is part of my effort to define a generic EFI boot protocol for Linux,

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. Signed-off-by: Ard Biesheuvel

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. Signed-off-by: Ard Biesheuvel

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

Incorporate the PEI components and the associated library class resolutions and PCD declarations to enable TPM2 support in the PEI phase. Signed-off-by: Ard Biesheuvel

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

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

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

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

On ARM systems, the TPM does not live at a fixed address, and so we need the platform to discover it first. So introduce a PPI that signals that the TPM address has been discovered and recorded in the

Wire up the various existing pieces so that we can implement measured boot on ArmVirtQemu based on the TPM support in QEMU, just like it has been implemented for x86 in OvmfPkg. The main difference

The controller supports up to 8 targets (Not reported by the controller, but based on the implementation of the virtual device), report them in GetNextTarget and GetNextTargetLun. The firmware

Reset and send the IO controller initialization request. The reply is read back to complete the doorbell function but it isn't useful to us because it doesn't contain relevant data or status

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Nikita Leshenko <nikita.leshchenko@...> Reviewed-by: Konrad