]> git.proxmox.com Git - mirror_edk2.git/log
mirror_edk2.git
4 years agoOvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmm
Laszlo Ersek [Wed, 26 Feb 2020 22:11:45 +0000 (23:11 +0100)]
OvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmm

Set "PcdCpuHotPlugSupport" to TRUE, when OVMF is built with SMM_REQUIRE.
Consequences:

(1) In PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c],
    resources are allocated and populated in advance for all possible
    (i.e., potentially hot-added) processors, rather than only the
    processors present at boot.

    The possible count (called "mMaxNumberOfCpus") is set from
    "PcdCpuMaxLogicalProcessorNumber"; we set the latter in
    OvmfPkg/PlatformPei. (Refer to commit 83357313dd67,
    "OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU
    hotplug", 2020-01-29).

(2) The AddProcessor() and RemoveProcessor() member functions of
    EFI_SMM_CPU_SERVICE_PROTOCOL, implemented in
    "UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c", are no longer
    short-circuited to EFI_UNSUPPORTED.

    We'll rely on these functions in the CPU hotplug SMI handler, in a
    subsequent patch.

(3) In PiCpuSmmEntry(), the address of the CPU_HOT_PLUG_DATA structure (in
    SMRAM) is exposed via the dynamic-only "PcdCpuHotPlugDataAddress".

    This structure is an information channel between the CPU hotplug SMI
    handler, and EFI_SMM_CPU_SERVICE_PROTOCOL. Namely, at the first
    "Index" where the following equality holds:

      CPU_HOT_PLUG_DATA.ApicId[Index] == INVALID_APIC_ID

    a hot-plugged CPU can be accepted, with the steps below:

(3.1) The hotplug SMI handler has to overwrite INVALID_APIC_ID with the
      new CPU's APIC ID.

(3.2) The new CPU's SMBASE has to be relocated to:

        CPU_HOT_PLUG_DATA.SmBase[Index]

      (which was precomputed in step (1) above).

(3.3) The hotplug SMI handler is supposed to call
      EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor().

Note: we need not spell out "PcdCpuHotPlugDataAddress" in the
[PcdsDynamicDefault] sections of the OVMF DSC files, just so the PCD
become dynamically settable. That's because "UefiCpuPkg.dec" declares this
PCD with [PcdsDynamic, PcdsDynamicEx] access methods *only*.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
4 years agoOvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmm
Laszlo Ersek [Wed, 26 Feb 2020 22:11:44 +0000 (23:11 +0100)]
OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmm

With "PcdCpuSmmEnableBspElection" set to FALSE, PiSmmCpuDxeSmm always
considers the processor with index 0 to be the SMM Monarch (a.k.a. the SMM
BSP). The SMM Monarch handles the SMI for real, while the other CPUs wait
in their SMM loops.

In a subsequent patch, we want to set "PcdCpuHotPlugSupport" to TRUE. For
that, PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c] forces
us with an ASSERT() to set "PcdCpuSmmEnableBspElection" to TRUE as well.
To satisfy that expectation, we can simply remove our current
"PcdCpuSmmEnableBspElection|FALSE" setting, and inherit the default TRUE
value from "UefiCpuPkg.dec".

This causes "mSmmMpSyncData->BspIndex" in PiSmmCpuDxeSmm to lose its
static zero value (standing for CPU#0); instead it becomes (-1) in
general, and the SMM Monarch is elected anew on every SMI.

The default SMM Monarch Election is basically a race -- whichever CPU can
flip "mSmmMpSyncData->BspIndex" from (-1) to its own index, becomes king,
for handling that SMI. Refer to SmiRendezvous()
[UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c].

I consider this non-determinism less than ideal on QEMU/KVM; it would be
nice to stick with a "mostly permanent" SMM Monarch even with the Election
enabled. We can do that by implementing the PlatformSmmBspElection() API
in the SmmCpuPlatformHookLibQemu instance:

The IA32 APIC Base MSR can be read on each CPU concurrently, and it will
report the BSP bit as set only on the current Boot Service Processor. QEMU
marks CPU#0 as the BSP, by default.

Elect the current BSP, as reported by QEMU, for the SMM Monarch role.

(Note that the QEMU commit history is not entirely consistent on whether
QEMU/KVM may mark a CPU with nonzero index as the BSP:

- At tag v4.2.0, "target/i386/cpu.c" has a comment saying "We hard-wire
  the BSP to the first CPU". This comment goes back to commit 6cb2996cef5e
  ("x86: Extend validity of bsp_to_cpu", 2010-03-04).

- Compare commit 9cb11fd7539b ("target-i386: clear bsp bit when
  designating bsp", 2015-04-02) though, especially considering KVM.

Either way, this OvmfPkg patch is *not* dependent on CPU index 0; it just
takes the race on every SMI out of the game.)

One benefit of using a "mostly permanent" SMM Monarch / BSP is that we can
continue testing the SMM CPU synchronization by deterministically entering
the firmware on the BSP, vs. on an AP, from Linux guests:

$ time taskset -c 0 efibootmgr
$ time taskset -c 1 efibootmgr

(See
<https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#uefi-variable-access-test>.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c5
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
4 years agoOvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkg
Laszlo Ersek [Wed, 26 Feb 2020 22:11:43 +0000 (23:11 +0100)]
OvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkg

Clone the Null instance of SmmCpuPlatformHookLib from UefiCpuPkg to
OvmfPkg. In this patch, customize the lib instance only with the following
no-op steps:

- Replace Null/NULL references in filenames and comments with Qemu/QEMU
  references.
- Update copyright notices.
- Clean up and rewrap comment blocks.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI file.

This patch is best reviewed with:

$ git show --find-copies=43 --find-copies-harder

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
4 years agoUefiCpuPkg/PiSmmCpuDxeSmm: fix S3 Resume for CPU hotplug
Laszlo Ersek [Wed, 26 Feb 2020 22:11:42 +0000 (23:11 +0100)]
UefiCpuPkg/PiSmmCpuDxeSmm: fix S3 Resume for CPU hotplug

The "ACPI_CPU_DATA.NumberOfCpus" field is specified as follows, in
"UefiCpuPkg/Include/AcpiCpuData.h" (rewrapped for this commit message):

  //
  // The number of CPUs.  If a platform does not support hot plug CPUs,
  // then this is the number of CPUs detected when the platform is booted,
  // regardless of being enabled or disabled.  If a platform does support
  // hot plug CPUs, then this is the maximum number of CPUs that the
  // platform supports.
  //

The InitializeCpuBeforeRebase() and InitializeCpuAfterRebase() functions
in "UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c" try to restore CPU configuration on
the S3 Resume path for *all* CPUs accounted for in
"ACPI_CPU_DATA.NumberOfCpus". This is wrong, as with CPU hotplug, not all
of the possible CPUs may be present at the time of S3 Suspend / Resume.
The symptom is an infinite wait.

Instead, the "mNumberOfCpus" variable should be used, which is properly
maintained through the EFI_SMM_CPU_SERVICE_PROTOCOL implementation (see
SmmAddProcessor(), SmmRemoveProcessor(), SmmCpuUpdate() in
"UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c").

When CPU hotplug is disabled, "mNumberOfCpus" is constant, and equals
"ACPI_CPU_DATA.NumberOfCpus" at all times.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
[lersek@redhat.com: shut up UINTN->UINT32 warning from Windows VS2019 PR]

4 years agoMdeModulePkg/PiSmmCore: log SMM image start failure
Laszlo Ersek [Wed, 26 Feb 2020 22:11:41 +0000 (23:11 +0100)]
MdeModulePkg/PiSmmCore: log SMM image start failure

In the CoreStartImage() function [MdeModulePkg/Core/Dxe/Image/Image.c], if
the image entry point returns a failure code, then the DXE Core logs a
helpful DEBUG_ERROR message, with the following format string:

  "Error: Image at %11p start failed: %r\n"

Do similarly in the SMM Core (update the message slightly).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
4 years agoOvmfPkg: plug DxeTpmMeasureBootLib into SecurityStubDxe
Marc-André Lureau [Wed, 26 Feb 2020 15:24:33 +0000 (16:24 +0100)]
OvmfPkg: plug DxeTpmMeasureBootLib into SecurityStubDxe

Mirrors TPM 2.0 commit d5a002aba0aa ("OvmfPkg: plug
DxeTpm2MeasureBootLib into SecurityStubDxe", 2018-03-09)

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-6-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
4 years agoOvmfPkg: include TcgDxe module
Marc-André Lureau [Wed, 26 Feb 2020 15:24:32 +0000 (16:24 +0100)]
OvmfPkg: include TcgDxe module

Mirrors TPM 2.0 commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe
module", 2018-03-09).

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-5-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
4 years agoOvmfPkg: include TcgPei module
Marc-André Lureau [Wed, 26 Feb 2020 15:24:31 +0000 (16:24 +0100)]
OvmfPkg: include TcgPei module

Mirrors TPM 2.0 commit 4672a4892867 ("OvmfPkg: include Tcg2Pei
module", 2018-03-09).

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-4-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
4 years agoOvmfPkg: detect TPM 1.2 in Tcg2ConfigPei
Marc-André Lureau [Wed, 26 Feb 2020 15:24:30 +0000 (16:24 +0100)]
OvmfPkg: detect TPM 1.2 in Tcg2ConfigPei

Complement commit 6cf1880fb5b ("OvmfPkg: add customized Tcg2ConfigPei
clone", 2018-03-09) by detecting TPM 1.2 devices.

Since Tpm12RequestUseTpm() returns success on any TPM interface,
(including FIFO & CRB which are TPM 2.0), try to send a GetTicks TPM
1.2 command to probe the version. In case of failure, fallback on TPM
2.0 path.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Message-Id: <20200226152433.1295789-3-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
4 years agoOvmfPkg: rename TPM2 config prefix to TPM
Marc-André Lureau [Wed, 26 Feb 2020 15:24:29 +0000 (16:24 +0100)]
OvmfPkg: rename TPM2 config prefix to TPM

A following patch is going to use the same configuration for TPM1.2
and TPM2.0, and it's simpler to support both than variable
configurations.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-2-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
4 years agoOvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists
Ard Biesheuvel [Tue, 3 Mar 2020 13:37:49 +0000 (14:37 +0100)]
OvmfPkg/LinuxInitrdDynamicShellCommand: bail if initrd already exists

Before taking any actions, check if an instance of the LoadFile2 exists
already on the Linux initrd media GUID device path, and whether it was
provided by this command. If so, abort, since no duplicate instances of
the device path should exist.

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>
4 years agoOvmfPkg IA32: add support for loading X64 images
Ard Biesheuvel [Wed, 26 Feb 2020 19:43:43 +0000 (20:43 +0100)]
OvmfPkg IA32: add support for loading X64 images

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 the
part of the bootloader or firmware.

Instead, we add a .compat PE/COFF header containing an array of
PE_COMPAT nodes containing <machine type, entrypoint> tuples that
describe alternate entrypoints into the image for different native
machine types, e.g., IA-32 in a 64-bit image so it can be booted
from IA-32 firmware.

This patch implements the PE/COFF emulator protocol to take this new
section into account, so that such images can simply be loaded via
LoadImage/StartImage, e.g., straight from the shell.

This feature is based on the EDK2 specific PE/COFF emulator protocol
that was introduced in commit 57df17fe26cd ("MdeModulePkg/DxeCore:
invoke the emulator protocol for foreign images", 2019-04-14).

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
4 years agoMdeModulePkg/DxeCore: defer PE/COFF emulator registration to StartImage
Ard Biesheuvel [Wed, 26 Feb 2020 19:43:42 +0000 (20:43 +0100)]
MdeModulePkg/DxeCore: defer PE/COFF emulator registration to StartImage

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 return
EFI_UNSUPPORTED.

The integration of the PE/COFF emulator protocol into the DXE core
deviates slightly from this paradigm, given that its IsImageSupported
hook as well as its RegisterImage hook are invoked from LoadImage,
and by the time StartImage is called, no opportunity is given to the
provider of the PE/COFF emulator protocol to prevent an image from
being started if it only supports loading it.

To address this disparity, let's move the invocation of RegisterImage()
to the implementation of the StartImage() boot service, allowing the
emulator to permit LoadImage() but reject StartImage() on images that
turn out not to meet the requirements of the emulator as it is being
started.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Liming Gao <liming.gao@intel.com>
4 years agoOvmfPkg: add the 'initrd' dynamic shell command
Ard Biesheuvel [Wed, 26 Feb 2020 19:43:41 +0000 (20:43 +0100)]
OvmfPkg: add the 'initrd' dynamic shell 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 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>
4 years agoArmVirtPkg: add the 'initrd' dynamic shell command
Ard Biesheuvel [Wed, 26 Feb 2020 19:43:40 +0000 (20:43 +0100)]
ArmVirtPkg: add the 'initrd' dynamic shell 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 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>
4 years agoOvmfPkg: add 'initrd' shell command to expose Linux initrd via device path
Ard Biesheuvel [Wed, 26 Feb 2020 19:43:39 +0000 (20:43 +0100)]
OvmfPkg: add 'initrd' shell command to expose Linux initrd via device path

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 protocol on its special
vendor media device path.

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>
4 years agoOvmfPkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID
Ard Biesheuvel [Wed, 26 Feb 2020 19:43:38 +0000 (20:43 +0100)]
OvmfPkg: add definition of LINUX_EFI_INITRD_MEDIA_GUID

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 protocol.

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>
4 years agoArmVirtPkg/ArmVirtQemu: enable TPM2 based measured boot
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:14 +0000 (20:05 +0100)]
ArmVirtPkg/ArmVirtQemu: enable TPM2 based measured boot

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 d5a002aba0aa ("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>
4 years agoArmVirtPkg/ArmVirtQemu: enable the TPM2 configuration module
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:13 +0000 (20:05 +0100)]
ArmVirtPkg/ArmVirtQemu: enable the TPM2 configuration module

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:

3103389043bd ("OvmfPkg: Add TCG2 Configuration menu to the Device
                Manager menu", 2019-02-11)

cf3ad972a210 ("OvmfPkg: reorganize TPM2 support in DSC/FDF files",
                2020-01-09)

f55477fe2d62 ("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>
4 years agoArmVirtPkg/ArmVirtQemu: enable the DXE phase TPM2 support module
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:12 +0000 (20:05 +0100)]
ArmVirtPkg/ArmVirtQemu: enable the DXE phase TPM2 support module

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:

0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module", 2018-03-09)

b9777bb42e4f ("OvmfPkg: add Tcg2PhysicalPresenceLibQemu", 2018-05-22)
               -- only to match OVMF's current lib class resolutions

1ec05b81e59f ("OvmfPkg: use DxeTpmMeasurementLib if and only if
                TPM2_ENABLE", 2019-07-04)

b9130c866dc0 ("OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei
                and Tcg2Dxe", 2018-08-16)

5d3ef15da7c3 ("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>
4 years agoArmVirtPkg: unshare TpmMeasurementLib resolution between platforms
Ard Biesheuvel [Thu, 27 Feb 2020 14:24:21 +0000 (15:24 +0100)]
ArmVirtPkg: unshare TpmMeasurementLib resolution between platforms

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>
4 years agoArmVirtPkg; avoid DxeTpmMeasurementLib in shared .DSC
Ard Biesheuvel [Thu, 27 Feb 2020 14:12:32 +0000 (15:12 +0100)]
ArmVirtPkg; avoid DxeTpmMeasurementLib in shared .DSC

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 1ec05b81e59f ("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>
4 years agoArmVirtPkg/ArmVirtQemu: enable TPM2 support in the PEI phase
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:11 +0000 (20:05 +0100)]
ArmVirtPkg/ArmVirtQemu: enable TPM2 support in the PEI phase

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:
6cf1880fb5b6 ("OvmfPkg: add customized Tcg2ConfigPei clone",
                2018-03-09)
4672a4892867 ("OvmfPkg: include Tcg2Pei module", 2018-03-09)
b9130c866dc0 ("OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei
                and Tcg2Dxe", 2018-08-16)
5d3ef15da7c3 ("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>
4 years agoArmVirtPkg/ArmVirtQemu: add ResetSystem PEIM for upcoming TPM2 support
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:10 +0000 (20:05 +0100)]
ArmVirtPkg/ArmVirtQemu: add ResetSystem PEIM for upcoming TPM2 support

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>
4 years agoArmVirtPkg: implement ArmVirtPsciResetSystemPeiLib
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:09 +0000 (20:05 +0100)]
ArmVirtPkg: implement ArmVirtPsciResetSystemPeiLib

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>
4 years agoArmVirtPkg/PlatformPeiLib: discover the TPM base address from the DT
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:08 +0000 (20:05 +0100)]
ArmVirtPkg/PlatformPeiLib: discover the TPM base address from the DT

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>
4 years agoArmVirtPkg/PlatformPeiLib: make PcdLib dependency explicit in .INF
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:07 +0000 (20:05 +0100)]
ArmVirtPkg/PlatformPeiLib: make PcdLib dependency explicit in .INF

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>
4 years agoOvmfPkg/Tcg2ConfigPei: introduce a signalling PPI to depex on
Ard Biesheuvel [Wed, 26 Feb 2020 19:05:06 +0000 (20:05 +0100)]
OvmfPkg/Tcg2ConfigPei: introduce a signalling PPI to depex on

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 appropriate
PCD, and make Tcg2ConfigPei depex on it when built for ARM or AARCH64.

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>
4 years agoUefiCpuPkg/MpInitLib: Skip reading PlatformId on AMD processors. edk2-stable202002
Leo Duran [Sat, 29 Feb 2020 15:05:45 +0000 (23:05 +0800)]
UefiCpuPkg/MpInitLib: Skip reading PlatformId on AMD processors.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556

This patch uses CPUID signature check to skip reading the PlatformId MSR,
which is not implemented on AMD processors.

The PlatformId is used for loading microcode patches, which is also not
supported and AMD-based platforms. To mitigate the PlatformId dependency,
PcdCpuMicrocodePatchAddress and PcdCpuMicrodePatchRegionSize must be set
to 0 (default value), in order to bypass microcode loading code paths.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
4 years agoBaseTools: Remove invalid leading space before !INCLUDE in Makefile
Bob Feng [Thu, 27 Feb 2020 14:25:24 +0000 (22:25 +0800)]
BaseTools: Remove invalid leading space before !INCLUDE in Makefile

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2563

This patch is to fix a incremental build regression bug
which happen when using nmake. That's introduced by 818283de3f6d.

If there is white space before !INCLUDE instruction, nmake will not
process it. Source code's dependent header files are listed in
${deps_file} file, if it's not included successfully, nmake will
not detect the change of those header file.

This patch has been verified in Windows with VS2015 and Linux with GCC5.
The header file add/modify/delete can trig the incremental build with this fix.
There is no impact on the clean build.

Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Tested-by: Liming Gao <liming.gao@intel.com>
4 years agoOvmfPkg/QemuVideoDxe: unbreak "secondary-vga" and "bochs-display" support
Laszlo Ersek [Mon, 24 Feb 2020 16:35:39 +0000 (17:35 +0100)]
OvmfPkg/QemuVideoDxe: unbreak "secondary-vga" and "bochs-display" support

In edk2 commit 333f32ec23dd, QemuVideoDxe gained support for QEMU's
"secondary-vga" device model (originally introduced in QEMU commit
63e3e24db2e9).

In QEMU commit 765c94290863, the "bochs-display" device was introduced,
which would work with QemuVideoDxe out of the box, reusing the
"secondary-vga" logic.

Support for both models has been broken since edk2 commit 662bd0da7fd7.
Said patch ended up requiring VGA IO Ports -- i.e., at least one of
EFI_PCI_IO_ATTRIBUTE_VGA_IO and EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 -- even if
the device wasn't actually VGA compatible.

Restrict the IO Ports requirement to VGA compatible devices.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc W Chen <marc.w.chen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 662bd0da7fd77e4d2cf9ef4a78015af5cad7d9db
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2555
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200224171741.7494-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
4 years agoNetworkPkg/ArpDxe: Recycle invalid ARP packets (CVE-2019-14559)
Siyuan Fu [Fri, 21 Feb 2020 02:14:18 +0000 (10:14 +0800)]
NetworkPkg/ArpDxe: Recycle invalid ARP packets (CVE-2019-14559)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2031

This patch triggers the RecycleEvent for invalid ARP packets.
Prior to this, we would just ignore invalid ARP packets,
and never free them.

Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Nicholas Armour <nicholas.armour@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
4 years agoShellPkg: acpiview: Prevent infinite loop if structure length is 0
Krzysztof Koch [Wed, 19 Feb 2020 10:23:38 +0000 (18:23 +0800)]
ShellPkg: acpiview: Prevent infinite loop if structure length is 0

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2534

Extend validation of ACPI structure lengths which are read from the
ACPI table being parsed. Additionally check if the structure 'Length'
field value is positive. If not, stop parsing the faulting table.

Some ACPI tables define internal structures of variable size. The
'Length' field inside the substructure is used to update a pointer used
for table traversal. If the byte-length of the structure is equal to 0,
acpiview can enter an infinite loop. This condition can occur if, for
example, the zero-allocated ACPI table buffer is not fully populated.
This is typically a bug on the ACPI table writer side.

In short, this method helps acpiview recover gracefully from a
zero-valued ACPI structure length.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
4 years agoCryptoPkg/BaseHashApiLib: Change PcdHashApiLibPolicy type to FixedAtBuild
Amol N Sukerkar [Sun, 16 Feb 2020 03:51:03 +0000 (03:51 +0000)]
CryptoPkg/BaseHashApiLib: Change PcdHashApiLibPolicy type to FixedAtBuild

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2511

This commit changes the PCD PcdHashApiLibPolicy to the type
PcdsFixedAtBuild so as to be able to optimize away the unused hashing
algorithms in HashApiLib instance used by a driver.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Amol N Sukerkar <amol.n.sukerkar@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
4 years agoCryptoPkg/BaseHashApiLib: Align BaseHashApiLib with TPM 2.0 Implementation
Amol N Sukerkar [Sun, 16 Feb 2020 03:51:02 +0000 (03:51 +0000)]
CryptoPkg/BaseHashApiLib: Align BaseHashApiLib with TPM 2.0 Implementation

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2511

This commit aligns the baseHashApiLib with TPM 2.0 Implementation
as follows:
- Remove reference to MD4 and MD5 algorithms as they are deprecated
- Align the enumerations for hashing algoerithms with the one used
  in TPM 2.0 implementation defined in IndustryStandard/Tpm20.h.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Amol N Sukerkar <amol.n.sukerkar@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
4 years agoMdeModulePkg: Make retval in UninstallMultipleProtocol follow Spec
Heinrich Schuchardt [Thu, 12 Sep 2019 06:34:06 +0000 (14:34 +0800)]
MdeModulePkg: Make retval in UninstallMultipleProtocol follow Spec

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1869

The UEFI spec requires that if any error occurs in
UninstallMultipleProtocolInterfaces(), EFI_INVALID_PARAMETER is returned
and not the return code of UninstallProtocolInterface().

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: change IsCertHashFoundInDatabase name (CVE-2019...
Jian J Wang [Fri, 14 Feb 2020 05:50:32 +0000 (13:50 +0800)]
SecurityPkg/DxeImageVerificationLib: change IsCertHashFoundInDatabase name (CVE-2019-14575)

IsCertHashFoundInDatabase() is actually used only for searching dbx,
according to the function logic, its comments and its use cases. Changing
it to IsCertHashFoundInDbx to avoid confusion.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: Differentiate error/search result (2) (CVE-2019...
Jian J Wang [Thu, 10 Oct 2019 07:02:17 +0000 (15:02 +0800)]
SecurityPkg/DxeImageVerificationLib: Differentiate error/search result (2) (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

To avoid false-negative issue in check hash against dbx, both error
condition (as return value) and check result (as out parameter) of
IsSignatureFoundInDatabase() are added. So the caller of this function
will know exactly if a failure is caused by a black list hit or
other error happening, and enforce a more secure operation to prevent
secure boot from being bypassed. For a white list check (db), there's
no such necessity.

All intermediate results inside this function will be checked and
returned immediately upon any failure or error, like out-of-resource,
hash calculation error or certificate retrieval failure.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: plug Data leak in IsForbiddenByDbx() (CVE-2019...
Laszlo Ersek [Wed, 25 Sep 2019 11:41:57 +0000 (13:41 +0200)]
SecurityPkg/DxeImageVerificationLib: plug Data leak in IsForbiddenByDbx() (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

If the second GetVariable() call for "dbx" fails, in IsForbiddenByDbx(),
we have to free Data. Jump to "Done" for that.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: tighten default result (CVE-2019-14575)
Jian J Wang [Tue, 17 Sep 2019 03:04:33 +0000 (11:04 +0800)]
SecurityPkg/DxeImageVerificationLib: tighten default result (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

All intermediate results inside this function will be checked and
returned immediately upon any failure or error, like out-of-resource,
hash calculation error or certificate retrieval failure.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: Differentiate error/search result (1) (CVE-2019...
Jian J Wang [Mon, 16 Sep 2019 08:52:58 +0000 (16:52 +0800)]
SecurityPkg/DxeImageVerificationLib: Differentiate error/search result (1) (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

To avoid false-negative issue in check hash against dbx, both error
condition (as return value) and check result (as out parameter) of
IsCertHashFoundInDatabase() are added. So the caller of this function
will know exactly if a failure is caused by a black list hit or
other error happening, and enforce a more secure operation to prevent
secure boot from being bypassed. For a white list check (db), there's
no such necessity.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: refactor db/dbx fetching code (CVE-2019-14575)
Jian J Wang [Thu, 10 Oct 2019 07:49:55 +0000 (15:49 +0800)]
SecurityPkg/DxeImageVerificationLib: refactor db/dbx fetching code (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

The dbx fetching code inside the while/for-loop causes code hard to
understand. Since there's no need to get dbx more than once, this patch
simplify the code logic by moving related code to be outside the while-
loop. db fetching code is also refined accordingly to reduce the indent
level of code.

More comments are also added or refined to explain more details.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: avoid bypass in fetching dbx (CVE-2019-14575)
Jian J Wang [Thu, 10 Oct 2019 06:28:36 +0000 (14:28 +0800)]
SecurityPkg/DxeImageVerificationLib: avoid bypass in fetching dbx (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

In timestamp check after the cert is found in db, the original code jumps
to 'Done' if any error happens in fetching dbx variable. At any of the
jump, VerifyStatus equals to TRUE, which means allowed-by-db. This should
not be allowed except to EFI_NOT_FOUND case (meaning dbx doesn't exist),
because it could be used to bypass timestamp check.

This patch add code to change VerifyStatus to FALSE in the case of memory
allocation failure and dbx fetching failure to avoid potential bypass
issue.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: fix wrong fetch dbx in IsAllowedByDb (CVE-2019...
Jian J Wang [Thu, 10 Oct 2019 03:46:16 +0000 (11:46 +0800)]
SecurityPkg/DxeImageVerificationLib: fix wrong fetch dbx in IsAllowedByDb (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

Normally two times of calling gRT->GetVariable() are needed to get
the data of a variable: get the variable size by passing zero variable
size, and then allocate enough memory and pass the correct variable size
and buffer.

But in the inner loop in IsAllowedByDb(), the DbxDataSize was not
initialized to zero before calling gRT->GetVariable(). It won't cause
problem if dbx does not exist. But it will give wrong result if dbx
exists and the DbxDataSize happens to be a small enough value. In this
situation, EFI_BUFFER_TOO_SMALL will be returned. Then the result check
code followed will jump to 'Done', which is not correct because it's
actually the value expected.

            if (Status == EFI_BUFFER_TOO_SMALL) {
              goto Done;
            }

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: reject CertStack.CertNumber==0 per DBX (CVE...
Jian J Wang [Thu, 10 Oct 2019 03:14:47 +0000 (11:14 +0800)]
SecurityPkg/DxeImageVerificationLib: reject CertStack.CertNumber==0 per DBX (CVE-2019-14575)

In case the signers' certificate stack, retrieved from the PE/COFF image's
Authenticode blob, has zero elements (=there are zero signer certificates),
then we should consider the image forbidden by DBX, not accepted by DBX.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoSecurityPkg/DxeImageVerificationLib: Fix memory leaks (CVE-2019-14575)
Jian J Wang [Thu, 10 Oct 2019 03:06:53 +0000 (11:06 +0800)]
SecurityPkg/DxeImageVerificationLib: Fix memory leaks (CVE-2019-14575)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1608

Pointer HashCtx used in IsCertHashFoundInDatabase() is not freed inside
the while-loop, if it will run more than once.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoNetworkPkg/Ip4Dxe: Check the received package length (CVE-2019-14559).
Jiaxin Wu [Mon, 29 Apr 2019 01:51:53 +0000 (09:51 +0800)]
NetworkPkg/Ip4Dxe: Check the received package length (CVE-2019-14559).

v3: correct the coding style.
v2: correct the commit message & add BZ number.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1610

This patch is to check the received package length to make sure the package
has a valid length field.

Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
4 years agoShellPkg: acpiview: Validate ACPI table 'Length' field
Krzysztof Koch [Tue, 11 Feb 2020 10:01:17 +0000 (18:01 +0800)]
ShellPkg: acpiview: Validate ACPI table 'Length' field

Check if the ACPI table length, as reported in the ACPI table header, is
big enough to fit at least the header itself.

If not, report an error to the user and stop parsing the table in order
to prevent buffer overruns.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
4 years agoShellPkg: acpiview: Remove duplicate ACPI structure size definitions
Krzysztof Koch [Thu, 30 Jan 2020 11:42:55 +0000 (19:42 +0800)]
ShellPkg: acpiview: Remove duplicate ACPI structure size definitions

Remove duplicate Generic Address Structure (GAS) and ACPI table header
size definitions. Replace any dependencies with the definitions from
Acpi63.h.

AcpiParser.h redefines the size of Generic Address Structure (GAS) and
the ACPI table header. The motivation is to 'minimise any reference to
the EDK2 ACPI headers in an attempt to provide cross checking'. While
the redefined values are unlikely to change, redefinition causes
unnecessary maintenance overhead for acpiview.

In addition to this, EDK2 ACPI headers are referenced throughout the
entire project, so the assumption should be that the definitions in
these header files are correct.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
4 years agoUefiCpuPkg RegisterCpuFeaturesLib: Match data type and format specifier
Zeng, Star [Tue, 4 Feb 2020 07:02:04 +0000 (15:02 +0800)]
UefiCpuPkg RegisterCpuFeaturesLib: Match data type and format specifier

Match data type and format specifier for printing.
1. Type cast ProcessorNumber and FeatureIndex to UINT32
  as %d only expects a UINT32.
2. Use %08x instead of %08lx for CacheControl to print Index
  as it is UINT32 type.
3. Use %016lx instead of %08lx for MemoryMapped to print
  (Index | LShiftU64 (HighIndex, 32)) as it is UINT64 type.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
4 years agoMaintainers.txt: Change NetworkPkg maintainer role.
Jiaxin Wu [Thu, 6 Feb 2020 05:39:41 +0000 (13:39 +0800)]
Maintainers.txt: Change NetworkPkg maintainer role.

Change Jiaxin Wu from Maintainer to Reviewer.

Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
4 years agoMdeModulePkg/SdMmcPciHcDxe: Fix double PciIo Unmap in TRB creation (CVE-2019-14587)
Hao A Wu [Wed, 26 Jun 2019 07:23:29 +0000 (15:23 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Fix double PciIo Unmap in TRB creation (CVE-2019-14587)

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1989

The commit will avoid unmapping the same resource in error handling logic
for function BuildAdmaDescTable() and SdMmcCreateTrb().

For the error handling in BuildAdmaDescTable():
The error is directly related with the corresponding Map() operation
(mapped address beyond 4G, which is not supported in ADMA), so the Unmap()
operation is done in the error handling logic, and then setting
'Trb->AdmaMap' to NULL to avoid double Unmap.

For the error handling in SdMmcCreateTrb():
The error is not directly related with the corresponding Map() operation,
so the commit will update the code to left SdMmcFreeTrb() for the Unmap
operation to avoid double Unmap.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
4 years agoMdeModulePkg/DisplayEngine: Zero memory before free (CVE-2019-14558)
Dandan Bi [Mon, 6 May 2019 08:43:34 +0000 (16:43 +0800)]
MdeModulePkg/DisplayEngine: Zero memory before free (CVE-2019-14558)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1611

Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
4 years agoMdeModulePkg/String.c: Zero memory before free (CVE-2019-14558)
Dandan Bi [Fri, 22 Feb 2019 07:45:24 +0000 (15:45 +0800)]
MdeModulePkg/String.c: Zero memory before free (CVE-2019-14558)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1611

Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
4 years agoMdeModulePkg/HiiDB: Remove configuration table when it's freed (CVE-2019-14586)
Dandan Bi [Tue, 24 Sep 2019 03:17:52 +0000 (11:17 +0800)]
MdeModulePkg/HiiDB: Remove configuration table when it's freed (CVE-2019-14586)

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1995

Fix the corner case issue that the original configuration runtime
memory is freed, but it is still exposed to the OS runtime.
So this patch is to remove the configuration table to avoid being
used in OS runtime when the configuration runtime memory is freed.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
4 years agoSecurityPkg: Issues reported by ECC in EDK2.
GuoMinJ [Thu, 13 Feb 2020 08:33:48 +0000 (16:33 +0800)]
SecurityPkg: Issues reported by ECC in EDK2.

https://bugzilla.tianocore.org/show_bug.cgi?id=2515

Change the SecurityPkg to match the ECC check rule

Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
4 years agoMdeModulePkg: Issues reported by ECC in EDK2.
GuoMinJ [Thu, 13 Feb 2020 08:33:47 +0000 (16:33 +0800)]
MdeModulePkg: Issues reported by ECC in EDK2.

https://bugzilla.tianocore.org/show_bug.cgi?id=2515

Change the MdeModulePkg to match the ECC check rule

Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
4 years agoFmpDevicePkg/FmpDxe: Issues reported by ECC in EDK2.
GuoMinJ [Thu, 13 Feb 2020 08:33:46 +0000 (16:33 +0800)]
FmpDevicePkg/FmpDxe: Issues reported by ECC in EDK2.

https://bugzilla.tianocore.org/show_bug.cgi?id=2515

Change the FmpDevicePkg to match the ECC check rule

Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoMdePkg: Remove FIT table industry standard header file.
Siyuan Fu [Tue, 11 Feb 2020 13:32:31 +0000 (21:32 +0800)]
MdePkg: Remove FIT table industry standard header file.

Commit c7c964b and dd01704 add header file for FIT table and update
MpInitLib to support FIT based microcode shadow operation. There are
comments that FIT is Intel specific specification instead of industry
standard, which should not be placed in EDK2 MdePkg and UefiCpuPkg.
This patch removes the header file added by c7c964b.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
4 years agoUefiCpuPkg: Remove FIT based microcode shadow logic from MpInitLib.
Siyuan Fu [Tue, 11 Feb 2020 13:30:48 +0000 (21:30 +0800)]
UefiCpuPkg: Remove FIT based microcode shadow logic from MpInitLib.

Commit c7c964b and dd01704 add header file for FIT table and update
MpInitLib to support FIT based microcode shadow operation. There are
comments that FIT is Intel specific specification instead of industry
standard, which should not be placed in EDK2 MdePkg and UefiCpuPkg.
So this patch adds a platform PPI for the microcode shadow logic, and
remove the FIT related code from EDK2.
The FIT based microcode shadow support will be implemented as a new
platform PEIM in IntelSiliconPkg in edk2-platforms.
This patch doesn't provide a DXE version shadow microcode protocol,
a platform which only uses DxeMpInitLib instance only supports PCD
based microcode shadowing.

A detailed design doc can be found here:
https://edk2.groups.io/g/devel/files/Designs/2020/0214/Support%20
the%202nd%20Microcode%20FV%20Flash%20Region.pdf

TEST: Tested on FIT enabled platform.
BZ: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
4 years agoUefiCpuPkg/CpuFeature: Introduce First to indicate 1st unit.
Ray Ni [Fri, 5 Jul 2019 03:49:15 +0000 (11:49 +0800)]
UefiCpuPkg/CpuFeature: Introduce First to indicate 1st unit.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1584

The flow of CPU feature initialization logic is:
1. BSP calls GetConfigDataFunc() for each thread/AP;
2. Each thread/AP calls SupportFunc() to detect its own capability;
3. BSP calls InitializeFunc() for each thread/AP.

There is a design gap in step #3. For a package scope feature that only
requires one thread of each package does the initialization operation,
what InitializeFunc() currently does is to do the initialization
operation only CPU physical location Core# is 0.
But in certain platform, Core#0 might be disabled in hardware level
which results the certain package scope feature isn't initialized at
all.

The patch adds a new field First to indicate the CPU's location in
its parent scope.
First.Package is set for all APs/threads under first package;
First.Core is set for all APs/threads under first core of each
package;
First.Thread is set for the AP/thread of each core.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
4 years agoUefiCpuPkg/RegisterCpuFeaturesLib: Rename [Before|After]FeatureBitMask
Ray Ni [Tue, 2 Jul 2019 09:21:02 +0000 (17:21 +0800)]
UefiCpuPkg/RegisterCpuFeaturesLib: Rename [Before|After]FeatureBitMask

The patch doesn't have any functionality impact.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
4 years agoUefiCpuPkg/RegisterCpuFeaturesLib: Delete CPU_FEATURE_[BEFORE|AFTER]
Ray Ni [Tue, 2 Jul 2019 07:15:45 +0000 (15:15 +0800)]
UefiCpuPkg/RegisterCpuFeaturesLib: Delete CPU_FEATURE_[BEFORE|AFTER]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1366

Commit b3c71b472dff2c02f0cc38d7a1959cfb2ba8420d supported MSR setting
in different scopes. It added below macro:
 CPU_FEATURE_THREAD_BEFORE
 CPU_FEATURE_THREAD_AFTER
 CPU_FEATURE_CORE_BEFORE
 CPU_FEATURE_CORE_AFTER
 CPU_FEATURE_PACKAGE_BEFORE
 CPU_FEATURE_PACKAGE_AFTER

And it re-interpreted CPU_FEATURE_BEFORE as CPU_FEATURE_THREAD_BEFORE
and CPU_FEATURE_AFTER as CPU_FEATURE_THREAD_AFTER.

This patch retires CPU_FEATURE_BEFORE and CPU_FEATURE_AFTER
completely.

Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
4 years agoIntelFsp2Pkg/SplitFspBin.py: Coverity scan flags issues.
Chasel Chiu [Fri, 7 Feb 2020 08:54:18 +0000 (16:54 +0800)]
IntelFsp2Pkg/SplitFspBin.py: Coverity scan flags issues.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1706

Issues were:
1. copy_paste_error: PeOptHdr vs PePlusOptHdr.
2. invalid_operation: Invalid operation on
null-like value "roffset".
3. invalid_operation: Invalid operation on
null-like value "rsize".

Fixed them by initializing roffset and rsize as PE32
image type and overriding them when PE32+ header found.

Test:
Compared script output before and after this patch and
the result is identical.

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
4 years agoIntelFsp2Pkg/GenCfgOpt.py: Coverity scan flags issues.
Chasel Chiu [Fri, 7 Feb 2020 08:33:36 +0000 (16:33 +0800)]
IntelFsp2Pkg/GenCfgOpt.py: Coverity scan flags issues.

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1706

Issue was: invalid_operation: Invalid operation on
null-like value "Base".
Fixed it by initializing Base to 0 before entering
while loop.

Test:
Compared script output before and after this patch and
the result is identical.

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
4 years agoMdePkg: Add PCCT table signature definition
Krzysztof Koch [Wed, 12 Feb 2020 17:27:39 +0000 (01:27 +0800)]
MdePkg: Add PCCT table signature definition

The Platform Communications Channel Table (PCCT) was defined in:
ACPI Specification Version 5.0, Errata A - Published Nov. 13, 2013.

Starting from the Acpi50.h header file, there are definitions
describing the table but a macro with the table's signature is missing.

This patch adds the definition of Platform Communications Channel
Table's signature to the relevant ACPI header files.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
4 years agoBaseTools: remove -DNO_MSABI_VA_FUNCS option in CLANGPDB tool chain
Liu, Zhiguang [Wed, 12 Feb 2020 01:40:21 +0000 (09:40 +0800)]
BaseTools: remove -DNO_MSABI_VA_FUNCS option in CLANGPDB tool chain

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2524

remove -DNO_MSABI_VA_FUNCS option in CLANGPDB tool chain After CLANGPDB is
switched to GNU mode, to use MS ABI version of GCC built-in macros for
variable argument lists as same as CLANG38 tool chain.

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoBaseTools:build failure in CLANGPDB tool chain
Fan, ZhijuX [Wed, 12 Feb 2020 09:59:05 +0000 (17:59 +0800)]
BaseTools:build failure in CLANGPDB tool chain

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2520

Incremental build failure in CLANGPDB tool chain on Windows host
The build failure is like below when do incremental build.
The root cause is in generated deps_target file. It has one line ":".

Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
4 years agoMdePkg/BaseSafeIntLib: Fix VS20xx IA32 link failures
Michael D Kinney [Wed, 12 Feb 2020 21:17:24 +0000 (13:17 -0800)]
MdePkg/BaseSafeIntLib: Fix VS20xx IA32 link failures

https://bugzilla.tianocore.org/show_bug.cgi?id=2525

SafeUint64Mult() looks for 64-bit overflows and performs
several 32-bit multiples with 64-bit results to check for
all possible overflow conditions.  IA32 builds using VS20xx
with optimizations enabled are producing a reference to
the _allmull intrinsic.

The fix is to use MultU64x64() instead of '*' for
these operations.  These are safe because the inputs
are guaranteed to have the upper 32-bits clear, which
means MultU64x64() can never overflow with those inputs.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoBaseTools: Fixed build failure when using python38
Fan, ZhijuX [Wed, 12 Feb 2020 07:14:11 +0000 (15:14 +0800)]
BaseTools: Fixed build failure when using python38

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2304

SyntaxWarning: "is" with a literal. Did you mean "=="?
Using "is" instead of "==" is an irregular syntax

Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Bob C Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
4 years agoBaseTools:fix Ecc tool issue for check StructPcd
Fan, ZhijuX [Fri, 17 Jan 2020 01:09:53 +0000 (09:09 +0800)]
BaseTools:fix Ecc tool issue for check StructPcd

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2142

gAdvancedFeaturePkgTokenSpaceGuid.PcdSmbiosType0BiosInformation|
{0x0}|SMBIOS_TABLE_TYPE0|0x80010000 {
    <HeaderFiles>
      IndustryStandard/SmBios.h
    <Packages>
      MdePkg/MdePkg.dec
      AdvancedFeaturePkg/AdvancedFeaturePkg.dec
  }

If there's a PcdStructHF or PcdStructPKGs in StructPcd,
EccTool report error,IndexError: list index out of range

This patch is going to fix this issue

Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
4 years agoBaseTools: Remove caret in NASM_INC macro
Pierre Gondois [Mon, 10 Feb 2020 10:49:08 +0000 (18:49 +0800)]
BaseTools: Remove caret in NASM_INC macro

NASM_INC contains the list of directory to include when using
the nasm assembler.

In nmake makefiles, a trailing backslash escapes the newline char
and replaces it with a space ' '. To have a literal trailing
backslash, it must be escaped with a caret '^'. This is not
necessary for GNU makefiles.

On windows platforms, for the NASM_INC macro, a caret escaping
a trailing a backslash was appended to the last included
folder regardless of the makefile type.
For instance, "/Include/" was replaced by "/Include/^\".

This is causing a build failure on windows platforms using
GNU makefiles since the caret '^' doesn't escape any chars in
GNU makefiles and is thus conserved.
"/Include^\" was replaced by "/Include\/" in nmake makefiles,
but remained "/Include/^\" in GNU makefiles.

This patch removes the caret '^' on the build using GNU makefiles.

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
4 years agoBaseTools: Rationalise makefile generation
Pierre Gondois [Mon, 10 Feb 2020 10:49:07 +0000 (18:49 +0800)]
BaseTools: Rationalise makefile generation

The GenMake.py script tests the platform environment
to determine the type of makefile that needs to be
generated. If a Windows build host is detected, the
makefile generated is of Nmake type. Otherwise a
GNUmake type is generated.

Furthermore, the <TARGET>_<TAGNAME>_<ARCH>_MAKE_PATH
option in tools_def.template defines the make tool
to use.
E.g.: for VS2017 this is configured to use Nmake, cf.
*_VS2017_*_MAKE_PATH = DEF(VS2017_BIN_HOST)\nmake.exe
while for GCC5 it is setup to use GNU make.
*_GCC5_*_MAKE_PATH = DEF(GCC_HOST_PREFIX)make

This prevents using the GCC compiler toolchain on a
Windows build host.

To address this issue this patch introduces 2 factors
to determine the generated makefile output.
  1. Platform -> to determine shell commands used
                 in makefile.
  2. MakeTool -> to determine the type of makefile
                 that needs to be generated.

Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
4 years agoMdePkg: Add PCI Express 5.0 Header File
Felix Polyudov [Tue, 4 Feb 2020 21:30:12 +0000 (05:30 +0800)]
MdePkg: Add PCI Express 5.0 Header File

The header includes Physical Layer PCI Express Extended Capability
definitions based on section 7.7.6 of PCI Express Base Specification 5.0.

Signed-off-by: Felix Polyudov <felixp@ami.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoMdePkg: Disable EBC for unit tests in MdePkg.dsc
Michael D Kinney [Mon, 10 Feb 2020 20:18:41 +0000 (12:18 -0800)]
MdePkg: Disable EBC for unit tests in MdePkg.dsc

https://bugzilla.tianocore.org/show_bug.cgi?id=2514

Update the target unit tests in MdePkg.dsc to only
build for IA32, X64, ARM, AARCH64.  This disables
EBC for these components.  The UnitTestLib class
uses vararg macros that the EBC compiler does not
support.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
4 years agoUnitTestFrameworkPkg: Disable EBC in DSC file
Michael D Kinney [Mon, 10 Feb 2020 20:16:45 +0000 (12:16 -0800)]
UnitTestFrameworkPkg: Disable EBC in DSC file

https://bugzilla.tianocore.org/show_bug.cgi?id=2514

Remove EBC as one of the supported architectures
in the UnitTestFrameworkPkg DSC file.  The EBC
compiler does not support vararg macros and the
UnitTestLib class uses this feature.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
4 years agoUnitTestFrameworkPkg/UnitTestLib: Fix XCODE parenthesis issues
Michael D Kinney [Mon, 10 Feb 2020 18:30:19 +0000 (10:30 -0800)]
UnitTestFrameworkPkg/UnitTestLib: Fix XCODE parenthesis issues

https://bugzilla.tianocore.org/show_bug.cgi?id=2512

Remove extra sets of parenthesis that generate warnings on XCODE5
builds.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sean Brogan <sean.brogan@microsoft.com>
4 years agoBaseTools: Switch to GNU mode for CLANGPDB
Vitaly Cheptsov [Tue, 11 Feb 2020 06:52:59 +0000 (14:52 +0800)]
BaseTools: Switch to GNU mode for CLANGPDB

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2397

Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoMdePkg/SmBios.h: Add two additional DWORD for smbios 3.3.0 type17
Matthew Carlson [Fri, 7 Feb 2020 08:37:25 +0000 (16:37 +0800)]
MdePkg/SmBios.h: Add two additional DWORD for smbios 3.3.0 type17

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2482

Refer to DSP0134_3.3.0.pdf, there are two additional DWORD added
for type 17. One is "Extended Speed", the other is "Extended
Configured Memory Speed". The lack of these field may cause strange
error in some operating systems.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoUefiCpuPkg/MpInitLib: Not pass microcode info between archs in CPU_MP_DATA
Hao A Wu [Wed, 22 Jan 2020 06:02:05 +0000 (14:02 +0800)]
UefiCpuPkg/MpInitLib: Not pass microcode info between archs in CPU_MP_DATA

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465

Commit 89164babec:
UefiCpuPkg/MpInitLib: don't shadow the microcode patch twice.

attempted to use 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
fields to avoid loading the microcode patches data into memory again in
the DXE phase.

However, the CPU_MP_DATA structure has members with type 'UINTN' or
pointer before the microcode patch related fields. This may cause issues
when PEI and DXE are of different archs (e.g. PEI - IA32, DXE - x64),
since the microcode patch related fields will have different offsets in
the CPU_MP_DATA structure.

Commit 88bd066166:
UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA

tried to resolve the above-mentioned issue by relocating the fields
'MicrocodePatchRegionSize' and 'MicrocodePatchAddress' before members with
different size between different archs. But it failed to take the case of
pre-built binaries (e.g. FSP) into consideration.

Binaries can be built when the code base had a different version of the
CPU_MP_DATA structure definition. This may cause issues when accessing
these microcode patch related fields, since their offsets are different
(between PEI phase in the binaries and DXE phase in current code
implementation).

This commit will use the newly introduced EDKII microcode patch HOB
instead for the DXE phase to get the information of the loaded microcode
patches data done in the PEI phase. And the 'MicrocodePatchRegionSize' and
'MicrocodePatchAddress' fields in CPU_MP_DATA will not be used to pass
information between phases.

For pre-built binaries, they can be classified into 3 types with regard to
the time when they are being built:

A. Before commit 89164babec
   (In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
    were not being used to skip microcode load in DXE)

For this case, the EDKII microcode patch HOB will not be produced. This
commit will load the microcode patches data again in DXE. Such behavior is
the same with the code base back then.

B. After commit 89164babec, before commit e1ed55738e
   (In other words, 'MicrocodePatchRegionSize' and 'MicrocodePatchAddress'
    being used to skip microcode load in DXE, but failed to work properly
    between differnt archs.)

For this case, the EDKII microcode patch HOB will not be produced as well.
This commit will also load the microcode patches data again in DXE.

But since commit 89164babec failed to keep the detection and application
of microcode patches working properly in DXE after skipping the load, we
fall back to the origin behavior (that is to load the microcode patches
data again in DXE).

C. After commit e1ed55738e
   (In other words, EDKII microcode patch HOB will be produced.)

For this case, it will have the same behavior with the BIOS built from
the current source codes.

Cc: Michael Kubacki <michael.a.kubacki@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
4 years agoRevert UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA
Hao A Wu [Thu, 16 Jan 2020 01:30:12 +0000 (09:30 +0800)]
Revert UefiCpuPkg/MpInitLib: Relocate microcode patch fields in CPU_MP_DATA

This reverts commit 88bd06616617ef2569f093f7b51893c11ad78e26.

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2465

Commit 88bd0661661 relocates the 'MicrocodePatchAddress' and
'MicrocodePatchRegionSize' fields in structure CPU_MP_DATA to ensure that
they can be properly passed between different architectures.

However, such change is not backward compatible with the scenario like
pre-existing binaries such as FSP. These binaries are built when the code
base has a different version of the CPU_MP_DATA structure definition. This
may cause issues when accessing the 'MicrocodePatchAddress' and
'MicrocodePatchRegionSize' fields, since their offsets are different
(between PEI phase in the FSP binaries and DXE phase in current code
implementation).

Cc: Michael Kubacki <michael.a.kubacki@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
4 years agoShellPkg: acpiview: DBG2: Validate global pointers before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:51 +0000 (19:13 +0800)]
ShellPkg: acpiview: DBG2: Validate global pointers before use

Check if global (in the scope of the DBG2 parser) pointers have been
successfully updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: GTDT: Validate global pointers before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:50 +0000 (19:13 +0800)]
ShellPkg: acpiview: GTDT: Validate global pointers before use

Check if global (in the scope of the GTDT parser) pointers have been
successfully updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: IORT: Validate global pointers before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:49 +0000 (19:13 +0800)]
ShellPkg: acpiview: IORT: Validate global pointers before use

Check if global (in the scope of the IORT parser) pointers have been
successfully updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: PPTT: Validate global pointers before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:48 +0000 (19:13 +0800)]
ShellPkg: acpiview: PPTT: Validate global pointers before use

Check if the NumberOfPrivateResources, ProcessorTopologyStructureType
and ProcessorTopologyStructureLength pointers have been successfully
updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: MADT: Validate global pointers before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:47 +0000 (19:13 +0800)]
ShellPkg: acpiview: MADT: Validate global pointers before use

Check if the MadtInterruptControllerType and
MadtInterruptControllerLength pointers have been successfully updated
before they are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: SRAT: Validate global pointers before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:46 +0000 (19:13 +0800)]
ShellPkg: acpiview: SRAT: Validate global pointers before use

Check if SratRAType and SratRALength pointers have been successfully
updated before they are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: SLIT: Validate System Locality count
Krzysztof Koch [Mon, 20 Jan 2020 11:13:45 +0000 (19:13 +0800)]
ShellPkg: acpiview: SLIT: Validate System Locality count

1. Check if the 'Number of System Localities' provided can be
represented in the SLIT table. The table 'Length' field is a 32-bit
value while the 'Number of System Localities' field is 64-bit long.

2. Check if the SLIT matrix fits in the table buffer. If N is the SLIT
locality count, then the matrix used to represent the localities is
N*N bytes long. The ACPI table length must be big enough to fit the
matrix.

3. Remove (now) redundant 64x64 bit multiplication.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: SLIT: Validate global pointer before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:44 +0000 (19:13 +0800)]
ShellPkg: acpiview: SLIT: Validate global pointer before use

Check if SlitSystemLocalityCount pointer has been successfully updated
before it is used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: FADT: Validate global pointer before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:43 +0000 (19:13 +0800)]
ShellPkg: acpiview: FADT: Validate global pointer before use

Check if global pointers have been successfully updated before they
are used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: RSDP: Validate global pointer before use
Krzysztof Koch [Mon, 20 Jan 2020 11:13:42 +0000 (19:13 +0800)]
ShellPkg: acpiview: RSDP: Validate global pointer before use

Check if XsdtAddress pointer has been successfully updated before it
is used for further table parsing.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields
Krzysztof Koch [Mon, 20 Jan 2020 11:13:41 +0000 (19:13 +0800)]
ShellPkg: acpiview: Set ItemPtr to NULL for unprocessed table fields

For fields outside the buffer length provided, reset any pointers,
which were supposed to be updated by a ParseAcpi() function call to
NULL. This way one can easily validate if a pointer was successfully
updated.

The ParseAcpi() function parses the given ACPI table buffer by a
number of bytes which is a minimum of the buffer length and the length
described by ACPI_PARSER array. If the buffer length is shorter than
the array describing how to process the ACPI structure, then it is
possible that the ItemPtr inside ACPI_PARSER may not get updated or
initialized. This can lead to an error if the value pointed to by
ItemPtr is later used to control the parsing logic.

A typical example would be a 'number of elements' field in an ACPI
structure header which defines how many substructures of a given type
are present in the structure body. If the 'number of elements' field
is not parsed, we will have a dangling pointer which could cause a
problem later.

Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
4 years agoShellPkg: Document UpdateArgcArgv returns EFI_INVALID_PARAMETER
Philippe Mathieu-Daud? [Mon, 2 Dec 2019 17:40:51 +0000 (01:40 +0800)]
ShellPkg: Document UpdateArgcArgv returns EFI_INVALID_PARAMETER

ShellParametersProtocol::UpdateArgcArgv() can return
a EFI_INVALID_PARAMETER value. Document it.

Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
4 years agoShellPkg: Document ParseCommandLineToArgs returns EFI_INVALID_PARAMETER
Philippe Mathieu-Daud? [Mon, 2 Dec 2019 17:40:50 +0000 (01:40 +0800)]
ShellPkg: Document ParseCommandLineToArgs returns EFI_INVALID_PARAMETER

ShellParametersProtocol::ParseCommandLineToArgs() can return
a EFI_INVALID_PARAMETER value. Document it.

Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
4 years agoShellPkg/UefiShellAcpiViewCommandLib: Fix FADT Parser
Ashish Singhal [Mon, 20 Jan 2020 05:44:34 +0000 (13:44 +0800)]
ShellPkg/UefiShellAcpiViewCommandLib: Fix FADT Parser

FADT parser was checking for reduced ACPI flag incorrectly
leading to incorrect error message if FIRMWARE_CTRL and
X_FIRMWARE_CTRL are both 0.

Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
4 years agoUefiCpuPkg/Smm: Fix various typos
Antoine Coeur [Fri, 7 Feb 2020 01:08:31 +0000 (02:08 +0100)]
UefiCpuPkg/Smm: Fix various typos

Fix various typos in comments and documentation.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-79-philmd@redhat.com>

4 years agoUefiCpuPkg/PiSmm: Fix various typos
Antoine Coeur [Fri, 7 Feb 2020 01:08:30 +0000 (02:08 +0100)]
UefiCpuPkg/PiSmm: Fix various typos

Fix various typos in comments and documentation.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-78-philmd@redhat.com>

4 years agoUefiCpuPkg/CpuDxe: Fix few typos
Antoine Coeur [Fri, 7 Feb 2020 01:08:29 +0000 (02:08 +0100)]
UefiCpuPkg/CpuDxe: Fix few typos

Fix few typos in comments and documentation.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-77-philmd@redhat.com>

4 years agoStandaloneMmPkg: Fix few typos
Antoine Coeur [Fri, 7 Feb 2020 01:08:28 +0000 (02:08 +0100)]
StandaloneMmPkg: Fix few typos

Fix few typos in comments.

Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-76-philmd@redhat.com>

4 years agoStandaloneMmPkg: Fix a typo
Philippe Mathieu-Daudé [Fri, 7 Feb 2020 01:08:27 +0000 (02:08 +0100)]
StandaloneMmPkg: Fix a typo

Fix a typo in a comment.

Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-75-philmd@redhat.com>