mirror_edk2.git
5 months agoMdeModulePkg/Pci: Fixed Asserts in SCT PCIIO Protocol Test.
Gaurav Jain [Tue, 25 Feb 2020 12:00:41 +0000 (20:00 +0800)]
MdeModulePkg/Pci: Fixed Asserts in SCT PCIIO Protocol Test.

ASSERT in PollMem_Conf, CopyMem_Conf, SetBarAttributes_Conf
Conformance Test.
SCT Test expect return as Invalid Parameter or Unsupported.
Added Checks for Function Parameters.
return Invalid or Unsupported if Check fails.

Added Checks in PciIoPollIo(), PciIoIoRead()
PciIoIoWrite()

Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoMdeModulePkg/SdMmcPciHcDxe: Fix PIO transfer mode
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:26 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Fix PIO transfer mode

Current driver does not support PIO transfer mode for
commands other then tuning. This change adds the code
to transfer PIO data.

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoMdeModulePkg/SdMmcPciHcDxe: Do not map memory for non DMA transfer
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:25 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Do not map memory for non DMA transfer

Driver code used to map memory for DMA transfer even if host doesn't
support DMA. This is causing memory corruption when driver transfers
data using PIO. This change refactors the code to skip call to
PciIo->Map for non DMA transfers.

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoMdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completion
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:24 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Refactor data transfer completion

This patch refactors the way in which the driver will check
the data transfer completion. Data transfer related
functionalities have been moved to separate function.

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoMdeModulePkg/SdMmcPciHcDxe: Read response on command completion
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:23 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Read response on command completion

SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed but data transfer timed out.

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoMdeModulePkg/SdMmcPciHcDxe: Enhance driver traces
Albecki, Mateusz [Thu, 27 Feb 2020 17:25:22 +0000 (01:25 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Enhance driver traces

To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrupt
status register on failed SD command.

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoMdeModulePkg/SdMmcPciHcDxe: Send SEND_STATUS at lower frequency
Albecki, Mateusz [Tue, 25 Feb 2020 15:05:53 +0000 (23:05 +0800)]
MdeModulePkg/SdMmcPciHcDxe: Send SEND_STATUS at lower frequency

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

To avoid stability issues on some designs the driver
will now send SEND_STATUS at previous, lower, frequency
when upgrading the bus timing.

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
5 months agoArmPlatformPkg/PrePeiCore: replace set/way cache ops with by-VA ones
Ard Biesheuvel [Fri, 21 Feb 2020 10:30:31 +0000 (11:30 +0100)]
ArmPlatformPkg/PrePeiCore: replace set/way cache ops with by-VA ones

Cache maintenance operations by set/way are only intended to be used
in the context of on/offlining a core, while it has been taken out of
the coherency domain. Any use intended to ensure that the contents of
the cache have made it to main memory is unreliable, since cacheline
migration and non-architected system caches may cause these contents
to linger elsewhere, without being visible in main memory once the
MMU and caches are disabled.

In KVM on Linux, there are horrid hacks in place to ensure that such
set/way operations are trapped, and replaced with a single by-VA
clean/invalidate of the entire guest VA space once the MMU state
changes, which can be costly, and is unnecessary if we manage the
caches a bit more carefully, and perform maintenance by virtual
address only.

So let's get rid of the call to ArmInvalidateDataCache () in the
PrePeiCore startup code, and instead, invalidate the temporary RAM
region by virtual address, which is the only memory region we will
be touching with the caches and MMU both disabled and enabled,
which will lead to data corruption if data written with the MMU off
is shadowed by clean, stale cachelines that stick around when the
MMU is enabled again.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
5 months agoArmPlatformPkg/LcdGraphicsOutputDxe: add missing protocol dependency
Ard Biesheuvel [Wed, 4 Mar 2020 11:56:46 +0000 (12:56 +0100)]
ArmPlatformPkg/LcdGraphicsOutputDxe: add missing protocol dependency

This driver depends on the gEfiCpuArchProtocolGuid protocol but does
not declare it, and so this dependency gets satisfied transitively
via ArmLib. However, ArmLib will drop this dependency as it does not
actually use it, so declare it for LcdGraphicsOutputDxe instead.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
5 months agoOvmfPkg/LinuxInitrdDynamicShellCommand: fix uninitialized status return
Ard Biesheuvel [Wed, 4 Mar 2020 11:45:31 +0000 (12:45 +0100)]
OvmfPkg/LinuxInitrdDynamicShellCommand: fix uninitialized status return

The Linaro CI reports:

  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:7:
  error: variable 'Status' is used uninitialized whenever 'if' condition is
                false [-Werror,-Wsometimes-uninitialized]
    if (mInitrdLoadFile2Handle != NULL) {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:141:10:
  note: uninitialized use occurs here
    return Status;
           ^~~~~~
  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:132:3:
  note: remove the 'if' if its condition is always true
    if (mInitrdLoadFile2Handle != NULL) {
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  OvmfPkg/LinuxInitrdDynamicShellCommand/LinuxInitrdDynamicShellCommand.c:130:23:
  note: initialize the variable 'Status' to silence this warning
    EFI_STATUS    Status;
                      ^
                       = 0

Fix this by pulling the return of Status into the conditional block where
it is assigned, and return EFI_SUCCESS otherwise.

Fixes: 2632178bc683f1f28f9dbe269f85d6b26b1800de
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
5 months agoArmPkg/MmCommunicationDxe: fix logic bug in DXE driver entrypoint
Ard Biesheuvel [Wed, 26 Feb 2020 12:06:31 +0000 (13:06 +0100)]
ArmPkg/MmCommunicationDxe: fix logic bug in DXE driver entrypoint

Commit 2fe25a74d6fee3c2 ("ArmPkg/MmCommunicationDxe: relay architected PI
events to MM context") update the ARM specific standalone MM client
driver to register for certain events in the entrypoint code, but did
so in a way that makes the entrypoint always return with an error.

Instead, return EFI_SUCCESS if registering for those events succeeds,
and back out the registrations that did succeed if one fails, and
return an error.

Fixes: 2fe25a74d6fee3c2 ("ArmPkg/MmCommunicationDxe: relay architected PI events to MM context")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
5 months agoArmPlatformPkg: convert LFs to CRLF, expand hard TABs
Laszlo Ersek [Thu, 27 Feb 2020 21:39:03 +0000 (22:39 +0100)]
ArmPlatformPkg: convert LFs to CRLF, expand hard TABs

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

At the same time, the following file had to undergo TAB expansion:

  ArmPlatformPkg/Scripts/Ds5/profile.py

I used "expand -t 4", conforming to the Indentation section of PEP-8
<https://www.python.org/dev/peps/pep-0008/#indentation>.

Both the CRLF conversion and the TAB expansion are motivated by
"PatchCheck.py". "PatchCheck.py" is also the reason why CRLF conversion
and TAB expansion have to happen in the same patch.

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-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
5 months agoArmVirtPkg: convert LFs to CRLF
Laszlo Ersek [Thu, 27 Feb 2020 21:39:02 +0000 (22:39 +0100)]
ArmVirtPkg: convert LFs to CRLF

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>
5 months agoArmPkg: convert LFs to CRLF, expand hard TABs
Laszlo Ersek [Thu, 27 Feb 2020 21:39:01 +0000 (22:39 +0100)]
ArmPkg: convert LFs to CRLF, expand hard TABs

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

At the same time, the following three files had to undergo TAB expansion:

  ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.c
  ArmPkg/Library/GccLto/liblto-aarch64.s
  ArmPkg/Library/GccLto/liblto-arm.s

I used "expand -t 2", in order to stay close to the edk2 coding style
(which uses two spaces for indentation.)

Both the CRLF conversion and the TAB expansion are motivated by
"PatchCheck.py". "PatchCheck.py" is also the reason why CRLF conversion
and TAB expansion have to happen in the same patch.

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-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
5 months agoOvmfPkg/CpuS3DataDxe: enable S3 resume after CPU hotplug
Laszlo Ersek [Wed, 26 Feb 2020 22:11:56 +0000 (23:11 +0100)]
OvmfPkg/CpuS3DataDxe: enable S3 resume after CPU hotplug

During normal boot, CpuS3DataDxe allocates

- an empty CPU_REGISTER_TABLE entry in the
  "ACPI_CPU_DATA.PreSmmInitRegisterTable" array, and

- an empty CPU_REGISTER_TABLE entry in the "ACPI_CPU_DATA.RegisterTable"
  array,

for every CPU whose APIC ID CpuS3DataDxe can learn.

Currently EFI_MP_SERVICES_PROTOCOL is used for both determining the number
of CPUs -- the protocol reports the present-at-boot CPU count --, and for
retrieving the APIC IDs of those CPUs.

Consequently, if a CPU is hot-plugged at OS runtime, then S3 resume
breaks. That's because PiSmmCpuDxeSmm will not find the hot-added CPU's
APIC ID associated with any CPU_REGISTER_TABLE object, in the SMRAM copies
of either of the "RegisterTable" and "PreSmmInitRegisterTable" arrays. The
failure to match the hot-added CPU's APIC ID trips the ASSERT() in
SetRegister() [UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c].

If "PcdQ35SmramAtDefaultSmbase" is TRUE, then:

- prepare CPU_REGISTER_TABLE objects for all possible CPUs, not just the
  present-at-boot CPUs (PlatformPei stored the possible CPU count to
  "PcdCpuMaxLogicalProcessorNumber");

- use QEMU_CPUHP_CMD_GET_ARCH_ID for filling in the "InitialApicId" fields
  of the CPU_REGISTER_TABLE objects.

This provides full APIC ID coverage for PiSmmCpuDxeSmm during S3 resume,
accommodating CPUs hot-added at OS runtime.

This patch is best reviewed with

$ git show -b

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-17-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
5 months agoOvmfPkg/CpuS3DataDxe: superficial cleanups
Laszlo Ersek [Wed, 26 Feb 2020 22:11:55 +0000 (23:11 +0100)]
OvmfPkg/CpuS3DataDxe: superficial cleanups

Sort the [Packages], [LibraryClasses], and [Pcd] sections in the INF file.
Pad the usage notes (CONSUMES, PRODUCES) in the [Pcd] section.

Sort the Library #includes in the C file.

This patch is functionally a no-op.

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-16-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>
5 months agoOvmfPkg: clone CpuS3DataDxe from UefiCpuPkg
Laszlo Ersek [Wed, 26 Feb 2020 22:11:54 +0000 (23:11 +0100)]
OvmfPkg: clone CpuS3DataDxe from UefiCpuPkg

The @file comments in UefiCpuPkg/CpuS3DataDxe say,

  [...] It also only supports the number of CPUs reported by the MP
  Services Protocol, so this module does not support hot plug CPUs.  This
  module can be copied into a CPU specific package and customized if these
  additional features are required. [...]

The driver is so small that the simplest way to extend it with hotplug
support is indeed to clone it at first. In this patch, customize the
driver only with the following no-op steps:

- Update copyright notices.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI files.
- Replace EFI_D_VERBOSE with DEBUG_VERBOSE, to appease "PatchCheck.py".

This patch is best reviewed with:

$ git show --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-15-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>
5 months agoOvmfPkg/CpuHotplugSmm: complete root MMI handler for CPU hotplug
Laszlo Ersek [Wed, 26 Feb 2020 22:11:53 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: complete root MMI handler for CPU hotplug

With the help of the Post-SMM Pen and the SMBASE relocation functions
added in the previous patches, we can now complete the root MMI handler
for CPU hotplug.

In the driver's entry point function:

- allocate the pen (in a reserved page in normal RAM),

- install the default ("first") SMI handler for hot-added CPUs (which
  includes priming the exchange area between the MM Monarch and the
  hot-added CPUs, i.e., shutting the APIC ID gate).

In the root MMI handler, for each hot-added CPU:

- record the APIC ID of the new CPU in CPU_HOT_PLUG_DATA,

- relocate the SMBASE of the new CPU,

- inform PiSmmCpuDxeSmm by calling
  EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor().

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-14-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
5 months agoOvmfPkg/CpuHotplugSmm: introduce First SMI Handler for hot-added CPUs
Laszlo Ersek [Wed, 26 Feb 2020 22:11:52 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: introduce First SMI Handler for hot-added CPUs

Implement the First SMI Handler for hot-added CPUs, in NASM.

Add the interfacing C-language function that the SMM Monarch calls. This
function launches and coordinates SMBASE relocation for a hot-added CPU.

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-13-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
5 months agoOvmfPkg/CpuHotplugSmm: introduce Post-SMM Pen for hot-added CPUs
Laszlo Ersek [Wed, 26 Feb 2020 22:11:51 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: introduce Post-SMM Pen for hot-added CPUs

Once a hot-added CPU finishes the SMBASE relocation, we need to pen it in
a HLT loop. Add the NASM implementation (with just a handful of
instructions, but much documentation), and some C language helper
functions.

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-12-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
5 months agoOvmfPkg/CpuHotplugSmm: collect CPUs with events
Laszlo Ersek [Wed, 26 Feb 2020 22:11:50 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: collect CPUs with events

Call QemuCpuhpCollectApicIds() in the root MMI handler. The APIC IDs of
the hotplugged CPUs will be used for several purposes in subsequent
patches.

For calling QemuCpuhpCollectApicIds(), pre-allocate both of its output
arrays "PluggedApicIds" and "ToUnplugApicIds" in the driver's entry point
function. The allocation size is dictated by the possible CPU count, which
we fetch from "CPU_HOT_PLUG_DATA.ArrayLength".

The CPU_HOT_PLUG_DATA structure in SMRAM is an out-of-band information
channel between this driver and PiSmmCpuDxeSmm, underlying
EFI_SMM_CPU_SERVICE_PROTOCOL.

In order to consume "CPU_HOT_PLUG_DATA.ArrayLength", extend the driver's
DEPEX to EFI_SMM_CPU_SERVICE_PROTOCOL. PiSmmCpuDxeSmm stores the address
of CPU_HOT_PLUG_DATA to "PcdCpuHotPlugDataAddress", before it produces
EFI_SMM_CPU_SERVICE_PROTOCOL.

Stash the protocol at once, as it will be needed later.

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-11-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
5 months agoOvmfPkg/CpuHotplugSmm: add function for collecting CPUs with events
Laszlo Ersek [Wed, 26 Feb 2020 22:11:49 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: add function for collecting CPUs with events

Add a function that collects the APIC IDs of CPUs that have just been
hot-plugged, or are about to be hot-unplugged.

Pending events are only located and never cleared; QEMU's AML needs the
firmware to leave the status bits intact in the hotplug register block.

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-10-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>
5 months agoOvmfPkg/CpuHotplugSmm: define the QEMU_CPUHP_CMD_GET_ARCH_ID macro
Laszlo Ersek [Wed, 26 Feb 2020 22:11:48 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: define the QEMU_CPUHP_CMD_GET_ARCH_ID macro

QEMU commit 3a61c8db9d25 ("acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command",
2020-01-22) introduced a new command in the modern CPU hotplug register
block that lets the firmware query the arch-specific IDs (on IA32/X64: the
APIC IDs) of CPUs. Add a macro for this command value, because we'll need
it later.

At the same time, add a sanity check for the modern hotplug interface to
CpuHotplugSmm.

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-9-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>
5 months agoOvmfPkg/CpuHotplugSmm: add hotplug register block helper functions
Laszlo Ersek [Wed, 26 Feb 2020 22:11:47 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: add hotplug register block helper functions

Add a handful of simple functions for accessing QEMU's hotplug registers
more conveniently. These functions thinly wrap some of the registers
described in "docs/specs/acpi_cpu_hotplug.txt" in the QEMU tree. The
functions hang (by design) if they encounter an internal failure.

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-8-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>
5 months agoOvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driver
Laszlo Ersek [Wed, 26 Feb 2020 22:11:46 +0000 (23:11 +0100)]
OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driver

Add a new SMM driver skeleton that registers a root SMI handler, and
checks if the SMI control value (written to 0xB2) indicates a CPU hotplug
SMI.

QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU
hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other
words, control value 4 is now allocated for this purpose; introduce the
ICH9_APM_CNT_CPU_HOTPLUG macro for it.

The standard identifiers in this driver use the new MM (Management Mode)
terminology from the PI spec, not the earlier SMM (System Management Mode)
terms.

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-7-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
5 months 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>
5 months 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>
5 months 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>
5 months 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]

5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>
5 months 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>