Commit Graph

27131 Commits

Author SHA1 Message Date
Laszlo Ersek 83357313dd OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug
MaxCpuCountInitialization() currently handles the following options:

(1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0)

    In this case, PlatformPei makes MpInitLib enumerate APs up to the
    default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until
    the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses.
    (Whichever is reached first.)

    Time-limited AP enumeration had never been reliable on QEMU/KVM, which
    is why commit 45a70db3c3 strated handling case (2) below, in OVMF.

(2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero)

    In this case, PlatformPei sets

    - PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count
      (FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"),

    - and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity"
      (MAX_UINT32, ~71 minutes).

    That causes MpInitLib to enumerate exactly the present (boot) APs.

    With CPU hotplug in mind, this method is not good enough. Because,
    using QEMU terminology, UefiCpuPkg expects
    PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count
    ("MachineState.smp.max_cpus"), which includes present and not present
    CPUs both (with not present CPUs being subject for hot-plugging).
    FW_CFG_NB_CPUS does not include not present CPUs.

Rewrite MaxCpuCountInitialization() for handling the following cases:

(1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set
    to values different from the defaults.)

(2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via
    FW_CFG_NB_CPUS), but not the possible CPUs count
    ("MachineState.smp.max_cpus").

    In this case, the behavior remains unchanged.

    The way MpInitLib is instructed to do the same differs however: we now
    set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count
    (while continuing to set PcdCpuMaxLogicalProcessorNumber identically).
    PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant.

(3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via
    FW_CFG_NB_CPUS), and the possible CPUs count
    ("MachineState.smp.max_cpus").

    We tell UefiCpuPkg about the possible CPUs count through
    PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU
    count for precise and quick AP enumeration, via
    PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is
    irrelevant again.

This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE.
As a side effect, the patch also enables S3 to work with CPU hotplug at
once, *without* SMM_REQUIRE.

(Without the patch, S3 resume fails, if a CPU is hot-plugged at OS
runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume
causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not
permitted.

With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely
"MachineState.smp.max_cpus". Therefore, the CPU structures allocated
during normal boot can accommodate the CPUs at S3 resume that have been
hotplugged prior to S3 suspend.)

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191022221554.14963-4-lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-01-29 17:28:22 +00:00
Laszlo Ersek b75d1de536 OvmfPkg/IndustryStandard: define macros for QEMU's CPU hotplug registers
In v1.5.0, QEMU's "pc" (i440fx) board gained a "CPU present bitmap"
register block. In v2.0.0, this was extended to the "q35" board.

In v2.7.0, a new (read/write) register interface was laid over the "CPU
present bitmap", with an option for the guest to switch the register block
to the new (a.k.a. modern) interface.

Both interfaces are documented in "docs/specs/acpi_cpu_hotplug.txt" in the
QEMU tree.

Add macros for a minimal subset of the modern interface, just so we can
count the possible CPUs (as opposed to boot CPUs) in a later patch in this
series.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191022221554.14963-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-01-29 17:28:22 +00:00
Laszlo Ersek 4ef78a39f0 OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaults
PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds are
only referenced in "OvmfPkg/PlatformPei/PlatformPei.inf", and OvmfXen does
not include that module. Remove the unnecessary dynamic PCD defaults from
"OvmfXen.dsc".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Message-Id: <20191022221554.14963-2-lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
2020-01-29 17:28:22 +00:00
Michael D Kinney c8b8157e12 BaseTools/Scripts/PatchCheck.py: Remove submodule false positives
https://bugzilla.tianocore.org/show_bug.cgi?id=2484
https://bugzilla.tianocore.org/show_bug.cgi?id=2485

Update PatchCheck to not enforce no tabs and not enforce CR/LF
line endings for .gitmodules files.  These files are updated by
git when a git submodule command is used and the updates by git
use tab characters and LF line endings.

Also update patch check to not enforce CR/LF line endings for
patch lines that create a submodule directory.  These patch
lines use LF line endings.  The git submodule directory is
added as a new file with attributes 160000 that can be detected
by looking for the pattern "new file mode 160000".

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-24 18:30:13 +00:00
Jian J Wang 9a1f14ad72 CryptoPkg/BaseCryptLib: remove HmacXxxGetContextSize interface
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1792

Hmac(Md5|Sha1|Sha256)GetContextSize() use a deprecated macro
HMAC_MAX_MD_CBLOCK defined in openssl. They should be dropped to
avoid misuses in the future. For context allocation and release,
use HmacXxxNew() and HmacXxxFree() instead.

Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
2020-01-20 16:41:23 +00:00
Jian J Wang a23fdff6fb CryptoPkg/BaseCryptLib: replace HmacXxxInit API with HmacXxxSetKey
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1792

HmacXxxInit() is supposed to be initialize user supplied buffer as HMAC
context, as well as user supplied key. Currently it has no real use cases.

Due to BZ1792, the user has no way to get correct size of context buffer
after it's fixed, and then cannot make use of HmacXxxInit to initialize
it.

So it's decided to replace it with HmacXxxSetKey to keep the functionality
of supplying a key to HMAC, but drop all other initialization works. The
user can still get HMAC context via HmacXxxNew interface, which hides the
details about the context.

Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
2020-01-20 16:41:23 +00:00
Bob Feng 5cd3d4bc43 BaseTools: Fixed a incremental build bug
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2451

If removing a header file from source code and file
system, the incremental build will fail.

This patch is to fix this issue by setting each header file
as a target without any actions in makefile.

Signed-off-by: Bob Feng <bob.c.feng@intel.com>

Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2020-01-19 07:46:18 +00:00
Hao A Wu 18fcb37598 UefiCpuPkg/MpInitLib: Fix possible uninitialized 'InitFlag' field
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2474

Previous commit d786a17232:
UefiCpuPkg/MpInitLib: Reduce the size when loading microcode patches

Removed the below assignments for the 'InitFlag' field of CPU_MP_DATA
structure in function MpInitLibInitialize() when APs are waken up to do
some initialize sync:

CpuMpData->InitFlag  = ApInitReconfig;
...
CpuMpData->InitFlag = ApInitDone;

The above commit mistakenly assumed the 'InitFlag' field will have a value
of 'ApInitDone' when the APs have been successfully waken up before. And
since there is no explicit comparision for the 'InitFlag' field with the
'ApInitReconfig' value. The commit removed those assignments.

However, under some cases (e.g. when variable OldCpuMpData is not NULL,
which means function CollectProcessorCount() will not be called), removing
the above assignments will left the 'InitFlag' field being uninitialized
with a value of 0, which is a invalid value for the type of 'InitFlag'
(AP_INIT_STATE).

It may potentially cause the WakeUpAP() function to run some unnecessary
codes when the APs have been successfully waken up before:

  if (CpuMpData->WakeUpByInitSipiSipi ||
      CpuMpData->InitFlag   != ApInitDone) {
    ResetVectorRequired = TRUE;
    AllocateResetVector (CpuMpData);
    FillExchangeInfoData (CpuMpData);
    SaveLocalApicTimerSetting (CpuMpData);
  }

This commit will address the above-mentioned issue.

Test done:
* OS boot on a real platform with multi processors

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2020-01-19 04:10:43 +00:00
Xu, Wei6 2ed845b3c3 FmdDevicePkg/FmpDxe: Support Fmp Capsule Dependency.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2421

Capsule Dependency is an incremental change of Fmp Capsule Update. The
capsule format is extended to include a set of binary encoded dependency
expression. The dependency expression is signed together with the Fmp
payload and evaluated before update is applied.
This feature is defined in UEFI Spec 2.8.

The dependency evaluation has two steps:
1. Validate platform existing Fmp images' version satisfy the dependency
expression in capsule image.
2. Validate the capsule image version satisfy all the platform existing
Fmp image's dependency expression.
If the dependency expression evaluates to FALSE, then the capsule update
fails and last attempt status is set to
LAST_ATTEMPT_STATUS_ERROR_UNSATISFIED_DEPENDENCIES.

The dependency saving and getting is FmpDeviceLib implementation scope.
The parameter "Image" of FmpDeviceSetImage and FmpDeviceGetImage function
is extended to contain the dependency. The layout:
  +--------------------------+
  |   Dependency Op-codes    |
  +--------------------------+
  |    Fmp Payload Image     |
  +--------------------------+
1. FmpDeviceSetImage is responsible for retrieving the dependency from the
parameter "Image" and saving it to a protected storage.
2. FmpDeviceGetImage is responsible for retrieving the dependency from the
storage where FmpDeviceSetImage saves dependency and combining it with the
Fmp Payload Image into one buffer which is returned to the caller. This
dependency will be populated into EFI_FIRMWARE_IMAGE_DESCRIPTOR and used
for dependency evaluation.
3. FmpDeviceGetAttributes must set the bit IMAGE_ATTRIBUTE_DEPENDENCY to
indicate the Fmp device supports Fmp Capsule Dependency feature.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2020-01-19 02:47:47 +00:00
Xu, Wei6 d9c919744b MdeModulePkg/CapsuleApp: Enhance CapsuleApp for Fmp Capsule Dependency
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2421

1. Enhance "CapsuleApp -P" to output the depex expression op-codes in
the EFI_FIRMWARE_IMAGE_DESCRIPTOR.
2. Enhance Last Attempt Status String with a new string to describe the
error LAST_ATTEMPT_STATUS_ERROR_UNSATISFIED_DEPENDENCIES.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2020-01-19 02:47:47 +00:00
Xu, Wei6 48997fe4d3 MdePkg: Add definition for Fmp Capsule Dependency.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2421

Add new definitions for Fmp Capsule dependency in UEFI Spec 2.8.
1. Extend the Last Attempt Status with a value to indicate the firmware
update fails with unsatisfied dependencies.
2. Add the definition of dependency expression op-codes.
3. Add the definition of EFI_FIRMWARE_IMAGE_DEP which is an array of FMP
dependency expression op-codes.
4. Extend the EFI_FIRMWARE_IMAGE_DESCRIPTOR with a pointer to the array of
FMP dependency expression op-codes.
5. Extend the Image Attribute Definitions with IMAGE_ATTRIBUTE_DEPENDENCY
to indicate that there is and EFI_FIRMWARE_IMAGE_DEP section associated
with the image.
6. Update EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION to 4.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2020-01-19 02:47:47 +00:00
Albecki, Mateusz 430743a1e8 MdeModulePkg/SdMmcPciHcDxe: Add retries for async commands
This patch adds retries for async execution for commands that
failed due to the CRC errors.

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>
2020-01-19 01:58:00 +00:00
Albecki, Mateusz c67617f3c6 MdeModulePkg/SdMmcPciHcDxe: Add retries for sync commands
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140

To increase the resiliency driver will now attempt to
retry the commands that failed due to the CRC error up
to 5 times. This should address the problems with the commands
that fail due to random condition on links. This should also
help the boards on which CMD13 is particularly unstable after
switching the link frequency.

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>
2020-01-19 01:58:00 +00:00
Albecki, Mateusz a22f4c34df MdeModulePkg/SdMmcPciHcDxe: Refactor command error detection
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140

Error detection function will now check if the command
failure has been caused by one of the errors that can
appear randomly on link(CRC error + end bit error). If
such an error has been a cause of failure, function will
return EFI_CRC_ERROR instead of EFI_DEVICE_ERROR to indicate
to the higher level that command has a chance of succeeding if
resent.

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>
2020-01-19 01:58:00 +00:00
Albecki, Mateusz 4e2ac8062c MdeModulePkg/SdMmcPciHcDxe: Fix DAT lane SW reset
Driver used to reset the DAT lane on a current error which
is not required according to SD specification(it's not going
to help). This patch will reset the DAT lane only on DAT
lane specific errors.

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>
2020-01-19 01:58:00 +00:00
Leif Lindholm c40c6351fa Maintainers.txt: update email address for Leif Lindholm
Leif now works at NUVIA Inc, update email address accordingly.

Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-17 20:16:38 +00:00
Laszlo Ersek a523556244 UefiCpuPkg/PiSmmCpuDxeSmm: fix 2M->4K page splitting regression for PDEs
In commit 4eee0cc7cc ("UefiCpuPkg/PiSmmCpu: Enable 5 level paging when
CPU supports", 2019-07-12), the Page Directory Entry setting was regressed
(corrupted) when splitting a 2MB page to 512 4KB pages, in the
InitPaging() function.

Consider the following hunk, displayed with

$ git show --function-context --ignore-space-change 4eee0cc7cc

>            //
>            // If it is 2M page, check IsAddressSplit()
>            //
>            if (((*Pd & IA32_PG_PS) != 0) && IsAddressSplit (Address)) {
>              //
>              // Based on current page table, create 4KB page table for split area.
>              //
>              ASSERT (Address == (*Pd & PHYSICAL_ADDRESS_MASK));
>
>              Pt = AllocatePageTableMemory (1);
>              ASSERT (Pt != NULL);
>
> +            *Pd = (UINTN) Pt | IA32_PG_RW | IA32_PG_P;
> +
>              // Split it
> -          for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++) {
> -            Pt[PtIndex] = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
> +            for (PtIndex = 0; PtIndex < SIZE_4KB / sizeof(*Pt); PtIndex++, Pt++) {
> +              *Pt = Address + ((PtIndex << 12) | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
>              } // end for PT
>              *Pd = (UINT64)(UINTN)Pt | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
>            } // end if IsAddressSplit
>          } // end for PD

First, the new assignment to the Page Directory Entry (*Pd) is
superfluous. That's because (a) we set (*Pd) after the Page Table Entry
loop anyway, and (b) here we do not attempt to access the memory starting
at "Address" (which is mapped by the original value of the Page Directory
Entry).

Second, appending "Pt++" to the incrementing expression of the PTE loop is
a bug. It causes "Pt" to point *right past* the just-allocated Page Table,
once we finish the loop. But the PDE assignment that immediately follows
the loop assumes that "Pt" still points to the *start* of the new Page
Table.

The result is that the originally mapped 2MB page disappears from the
processor's view. The PDE now points to a "Page Table" that is filled with
garbage. The random entries in that "Page Table" will cause some virtual
addresses in the original 2MB area to fault. Other virtual addresses in
the same range will no longer have a 1:1 physical mapping, but be
scattered over random physical page frames.

The second phase of the InitPaging() function ("Go through page table and
set several page table entries to absent or execute-disable") already
manipulates entries in wrong Page Tables, for such PDEs that got split in
the first phase.

This issue has been caught as follows:

- OVMF is started with 2001 MB of guest RAM.

- This places the main SMRAM window at 0x7C10_1000.

- The SMRAM management in the SMM Core links this SMRAM window into
  "mSmmMemoryMap", with a FREE_PAGE_LIST record placed at the start of the
  area.

- At "SMM Ready To Lock" time, PiSmmCpuDxeSmm calls InitPaging(). The
  first phase (quoted above) decides to split the 2MB page at 0x7C00_0000
  into 512 4KB pages, and corrupts the PDE. The new Page Table is
  allocated at 0x7CE0_D000, but the PDE is set to 0x7CE0_E000 (plus
  attributes 0x67).

- Due to the corrupted PDE, the second phase of InitPaging() already looks
  up the PTE for Address=0x7C10_1000 in the wrong place. The second phase
  goes on to mark bogus PTEs as "NX".

- PiSmmCpuDxeSmm calls SetMemMapAttributes(). Address 0x7C10_1000 is at
  the base of the SMRAM window, therefore it happens to be listed in the
  SMRAM map as an EfiConventionalMemory region. SetMemMapAttributes()
  calls SmmSetMemoryAttributes() to mark the region as XP. However,
  GetPageTableEntry() in ConvertMemoryPageAttributes() fails -- address
  0x7C10_1000 is no longer mapped by anything! -- and so the attribute
  setting fails with RETURN_UNSUPPORTED. This error goes unnoticed, as
  SetMemMapAttributes() ignores the return value of
  SmmSetMemoryAttributes().

- When SetMemMapAttributes() reaches another entry in the SMRAM map,
  ConvertMemoryPageAttributes() decides it needs to split a 2MB page, and
  calls SplitPage().

- SplitPage() calls AllocatePageTableMemory() for the new Page Table,
  which takes us to InternalAllocMaxAddress() in the SMM Core.

- The SMM core attempts to read the FREE_PAGE_LIST record at 0x7C10_1000.
  Because this virtual address is no longer mapped, the firmware crashes
  in InternalAllocMaxAddress(), when accessing (Pages->NumberOfPages).

Remove the useless assignment to (*Pd) from before the loop. Revert the
loop incrementing and the PTE assignment to the known good version.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1789335
Fixes: 4eee0cc7cc
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-17 09:41:05 +00:00
Michael Kubacki 302eb57b18 MdeModulePkg/Variable: Fix VarErrorFlag RT cache offset calculation
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2457

This commit fixes an offset calculation that is used to write the
VarErrorFlag UEFI variable to the UEFI variable runtime cache.

Currently a physical address is used instead of an offset. This
commit changes the offset to zero with a length of the entire
non-volatile variable store so the entire non-volatile variable
store buffer in SMRAM (with the variable update modification) is
copied to the runtime variable cache. This follows the same pattern
used in other SynchronizeRuntimeVariableCache () calls for
consistency.

* Observable symptom: An exception in SMM will most likely occur
  due to the invalid memory reference when the VarErrorFlag variable
  is written. The variable is most commonly written when the UEFI
  variable store is full.

* The issue only occurs when the variable runtime cache is enabled
  by the following PCD being set to TRUE:
  gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache

Fixes: aab3b9b9a1

Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Michael Turner <michael.turner@microsoft.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2020-01-17 02:51:42 +00:00
Liming Gao 63653ff8c8 MdePkg Base.h: Use correct style to check the defined macro
#if MACRO is not good style. It should be changed to
#ifdef MACRO style or #if defined (MACRO) style.

Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2020-01-17 00:57:34 +00:00
Krzysztof Koch 710ff7490a ShellPkg: acpiview: Update SRAT parser to ACPI 6.3
Add support for revision 3 of System Resource Affinity Table (SRAT).

Decode and dump the new Generic Initiator Affinity Structure.

Validate the Device Handle Type field inside the Generic Initiator
Affinity Structure.

Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Tested-by: Sudipto Paul <sudipto.paul@arm.com>
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
2020-01-15 05:37:53 +00:00
Li, Aaron f6f66e0c30 BaseTools/Capsule: Add capsule dependency support
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2412

Capsule generate tool support encode capsule dependencies through '-j'
command with a JSON file. To enable dependency feature, "Dependencies"
field for each payload in JSON file is required.
The value of "Dependencies" field is C style infix notation expression.
For example:
  "Dependencies":"72E2945A-00DA-448E-9AA7-075AD840F9D4 > 0x00000001"

The relation of Dependency Expression Opcode in UEFI2.8 chap 23.2 and
infix notation expression value is as follows:
+-----------------------------+--------------------------+
| OPCODE                      | INFIX EXPRESSION VALUE   |
+-----------------------------+--------------------------+
| 0x00 (PUSH_GUID)            | {GUID}                   |
| 0x01 (PUSH_VERSION)         | {UINT32}                 |
| 0x02 (DECLEAR_VERSION_NAME} | DECLEAR "{VERSION_NAME}" |
| 0x03 (AND)                  | &&                       |
| 0x04 (OR)                   | ||                       |
| 0x05 (NOT)                  | ~                        |
| 0x06 (TRUE)                 | TRUE                     |
| 0x07 (FALSE)                | FALSE                    |
| 0x08 (EQ)                   | ==                       |
| 0x09 (GT)                   | >                        |
| 0x0A (GTE)                  | >=                       |
| 0x0B (LT)                   | <                        |
| 0x0C (LTE)                  | <=                       |
+-----------------------------+--------------------------+

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>

Signed-off-by: Aaron Li <aaron.li@intel.com>

Reviewed-by: Bob Feng <bob.c.feng@intel.com>
2020-01-15 03:16:46 +00:00
Brian R Haug 94057f7402 MdeModulePkg/Setup: Update opcode number variable type to UINTN
Update data type of variables which save the opcode numbers
to UINTN, in case some configuration module has lots of
configuration items.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Brian R Haug <brian.r.haug@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
2020-01-15 00:48:32 +00:00
Ard Biesheuvel a6a835bdb1 ArmPlatformPkg/PrePeiCore: enable VFP at startup
While the alternative PEI-less SEC implementation in PrePi already
takes the EnableVFP PCD into account, the PrePeiCore code does not,
and so we may end up triggering synchronous exception when code
attempts to use FP or SIMD registers, which is permitted on AARCH64
by the spec.

So enable the VFP as early as feasible if the associated PCD is set.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2020-01-14 22:12:17 +00:00
Ard Biesheuvel e3756ba90a ArmPkg/ArmSmcPsciResetSystemLib: remove EnterS3WithImmediateWake ()
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib. Note that this means the hack to support warm
reboot by jumping to the SEC entry point with the MMU and caches off
is also no longer used, and can be removed as well, along with the PCD
PcdArmReenterPeiForCapsuleWarmReboot that was introduced for this
purpose.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2020-01-14 22:12:17 +00:00
Laszlo Ersek 4cca792399 NetworkPkg/HttpDxe: fix 32-bit truncation in HTTPS download
When downloading over TLS, each TLS message ("APP packet") is returned as
a (decrypted) fragment table by EFI_TLS_PROTOCOL.ProcessPacket().

The TlsProcessMessage() function in "NetworkPkg/HttpDxe/HttpsSupport.c"
linearizes the fragment table into a single contiguous data block. The
resultant flat data block contains both TLS headers and data.

The HttpsReceive() function parses the actual application data -- in this
case: decrypted HTTP data -- out of the flattened TLS data block, peeling
off the TLS headers.

The HttpResponseWorker() function in "NetworkPkg/HttpDxe/HttpImpl.c"
propagates this HTTP data outwards, implementing the
EFI_HTTP_PROTOCOL.Response() function.

Now consider the following documentation for EFI_HTTP_PROTOCOL.Response(),
quoted from "MdePkg/Include/Protocol/Http.h":

> It is the responsibility of the caller to allocate a buffer for Body and
> specify the size in BodyLength. If the remote host provides a response
> that contains a content body, up to BodyLength bytes will be copied from
> the receive buffer into Body and BodyLength will be updated with the
> amount of bytes received and copied to Body. This allows the client to
> download a large file in chunks instead of into one contiguous block of
> memory.

Note that, if the caller-allocated buffer is larger than the
server-provided chunk, then the transfer length is limited by the latter.
This is in fact the dominant case when downloading a huge file (for which
UefiBootManagerLib allocated a huge contiguous RAM Disk buffer) in small
TLS messages.

For adjusting BodyLength as described above -- i.e., to the application
data chunk that has been extracted from the TLS message --, the
HttpResponseWorker() function employs the following assignment:

    HttpMsg->BodyLength = MIN (Fragment.Len, (UINT32) HttpMsg->BodyLength);

The (UINT32) cast is motivated by the MIN() requirement -- in
"MdePkg/Include/Base.h" -- that both arguments be of the same type.

"Fragment.Len" (NET_FRAGMENT.Len) has type UINT32, and
"HttpMsg->BodyLength" (EFI_HTTP_MESSAGE.BodyLength) has type UINTN.
Therefore a cast is indeed necessary.

Unfortunately, the cast is done in the wrong direction. Consider the
following circumstances:

- "Fragment.Len" happens to be consistently 16KiB, dictated by the HTTPS
  Server's TLS stack,

- the size of the file to download is 4GiB + N*16KiB, where N is a
  positive integer.

As the download progresses, each received 16KiB application data chunk
brings the *next* input value of BodyLength closer down to 4GiB. The cast
in MIN() always masks off the high-order bits from the input value of
BodyLength, but this is no problem because the low-order bits are nonzero,
therefore the MIN() always permits progress.

However, once BodyLength reaches 4GiB exactly on input, the MIN()
invocation produces a zero value. HttpResponseWorker() adjusts the output
value of BodyLength to zero, and then passes it to HttpParseMessageBody().

HttpParseMessageBody() (in "NetworkPkg/Library/DxeHttpLib/DxeHttpLib.c")
rejects the zero BodyLength with EFI_INVALID_PARAMETER, which is fully
propagated outwards, and aborts the HTTPS download. HttpBootDxe writes the
message "Error: Unexpected network error" to the UEFI console.

For example, a file with size (4GiB + 197MiB) terminates after downloading
just 197MiB.

Invert the direction of the cast: widen "Fragment.Len" to UINTN.

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: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com>
2020-01-14 10:53:42 +00:00
Laszlo Ersek a56af23f06 MdeModulePkg/UefiBootManagerLib: log reserved mem allocation failure
The LoadFile protocol can report such a large buffer size that we cannot
allocate enough reserved pages for. This particularly affects HTTP(S)
Boot, if the remote file is very large (for example, an ISO image).

While the TianoCore wiki mentions this at
<https://github.com/tianocore/tianocore.github.io/wiki/HTTP-Boot#ram-disk-image-size>:

> The maximum RAM disk image size depends on how much continuous reserved
> memory block the platform could provide.

it's hard to remember; so log a DEBUG_ERROR message when the allocation
fails.

This patch produces error messages such as:

> UiApp:BmExpandLoadFile: failed to allocate reserved pages:
> BufferSize=4501536768
> LoadFile="PciRoot(0x0)/Pci(0x3,0x0)/MAC(5254001B103E,0x1)/
>      IPv4(0.0.0.0,TCP,DHCP,192.168.124.106,192.168.124.1,255.255.255.0)/
>      Dns(192.168.124.1)/
>      Uri(https://ipv4-server/RHEL-7.7-20190723.1-Server-x86_64-dvd1.iso)"
> FilePath=""

(Manually rewrapped here for keeping PatchCheck.py happy.)

Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
2020-01-14 10:53:42 +00:00
Michael D Kinney b112ec225f BaseTools/Scripts/PatchCheck: Address false error conditions
https://bugzilla.tianocore.org/show_bug.cgi?id=2406

* Always print subject line after the git commit id to make
  it easier to know the context of warnings or errors.
* Allow UTF-8 characters in subject line
* Error if subject line length > 75 without CVE-xxx-xxxxx present
* Error if subject line length > 92 with CVE-xxxx-xxxxx present
* If body line length is > 75, then print warning instead of error.

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
2020-01-13 18:18:03 +00:00
Fan, ZhijuX 4465cd124f BaseTools:Fix GenFds issue for BuildOption replace GenFdsOption
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2455

BuildOption is used by TargetTxtClassObj.py
GenFdsOption is used by GenFds.py
When the GenFds tool is used alone (e.g. python3 -m GenFds.GenFds -h)
With the OptionParser function, the first detected function
prints the help message

import TargetTxtClassObj to GenFds,
The BuildOption will be executed and replace GenFdsOption

We removed all objects associated with this problem that
were created directly during the import process
(e.g. BuildOption, BuildTarget = MyOptionParser(),
 TargetTxt = TargetTxtDict())

The Patch is going to fix this issue

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>
2020-01-13 02:08:46 +00:00
Fan, ZhijuX 072b9c2839 BaseTools:Change the case rules for ECC check pointer names
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2087

In CryptHkdf.c  line 42

  EVP_PKEY_CTX *pHkdfCtx;

Variable pHkdfCtx begins with lower case 'p',
which should be acceptable because it it is a pointer.
(Refer to CCS_2_1_Draft, 4.3.3.3)

So ECC tool should be improved to handle issues like this.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>

Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
2020-01-13 02:08:46 +00:00
Albecki, Mateusz 27f44ea1fb MdeModulePkg/SdMmcPciHcDxe: Fix unknown doxygen tag error
Changed @rtval to @retval in SdMmcHcStartSdClock
function description.

Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
2020-01-13 01:24:13 +00:00
Ard Biesheuvel 9d1c9d0379 ArmVirtPkg: remove EnterS3WithImmediateWake () from ResetSystemLib
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-10 07:00:51 +00:00
Ard Biesheuvel 2d9950a2bf OvmfPkg: remove EnterS3WithImmediateWake () from ResetSystemLib
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-10 07:00:51 +00:00
Ard Biesheuvel eaea26b781 UefiPayloadPkg: remove EnterS3WithImmediateWake () from ResetSystemLib
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Guo Dong <guo.dong@intel.com>
2020-01-10 07:00:51 +00:00
Ard Biesheuvel 6eacb857c1 PcAtChipsetPkg: remove EnterS3WithImmediateWake () from ResetSystemLib
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-10 07:00:51 +00:00
Ard Biesheuvel 7d3d87e4d7 MdeModulePkg: remove EnterS3WithImmediateWake () from ResetSystemLib
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-10 07:00:51 +00:00
Siyuan Fu dd01704111 UefiCpuPkg: Shadow microcode patch according to FIT microcode entry.
The existing MpInitLib will shadow the microcode update patches from
flash to memory and this is done by searching microcode region specified
by PCD PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize.
This brings a limition to platform FW that all the microcode patches must
be placed in one continuous flash space.

This patch shadows microcode update according to FIT microcode entries if
it's present, otherwise it will fallback to original logic (by PCD).

A new featured PCD gUefiCpuPkgTokenSpaceGuid.PcdCpuShadowMicrocodeByFit
is added for enabling/disabling this support.

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: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-10 06:20:42 +00:00
Siyuan Fu c7c964b109 MdePkg: Add header file for Firmware Interface Table specification.
This patch add FirmwareInterfaceTable.h for the Firmware Interface Table
BIOS specification.

This is to remove future edk2 dependency on edk2-platforms repo. The file
content comes from
 edk2-platforms\Silicon\Intel\IntelSiliconPkg\Include\IndustryStandard

BZ link: https://tianocore.acgmultimedia.com/show_bug.cgi?id=2449

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>
2020-01-10 06:20:42 +00:00
Philippe Mathieu-Daude c0328cf380 BaseTools/PatchCheck.py: Check the patch author email address
To avoid patches committed with incorrect email address,
use the EmailAddressCheck class on the author email too.

Example:

  $ python BaseTools/Scripts/PatchCheck.py 1a04951309
  Checking git commit: 1a04951309
  The 'Author' email address is not valid:
  * The email address cannot contain a space: /o=Intel/ou=External \
    (FYDIBOHF25SPDLT)/cn=Recipients/cn=fe425ca7e5f4401abed22b904fe5d964

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
2020-01-10 04:06:42 +00:00
Philippe Mathieu-Daude 8120390aab BaseTools/PatchCheck.py: Let EmailAddressCheck describe email checked
We are checking different emails from the signature list. We are
going to check more. To be able to differency, add a description
field, so the error reported is clearer.

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
2020-01-10 04:06:42 +00:00
Philippe Mathieu-Daude 8f38b08b50 BaseTools/PatchCheck.py: Check the committer email address
To avoid patches committed with incorrect email address,
use the EmailAddressCheck class on the committer email too.

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
2020-01-10 04:06:42 +00:00
Philippe Mathieu-Daude 8ffa47fb3a BaseTools/PatchCheck.py: Extract email check code to EmailAddressCheck
As we are going to reuse this code out of the CommitMessageCheck
class, extract it in a new class: EmailAddressCheck.

Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
2020-01-10 04:06:42 +00:00
Jason Voelz 1f0d809629 UefiCpuPkg/CpuCommonFeaturesLib: SMXE bit of CR4 should set
Add code to set SMXE in CR4 in the SmxInitialize flow when SMX is enabled.

Signed-off-by: Jason Voelz <jason.voelz@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-10 03:41:55 +00:00
Jason Voelz 859046e000 MdePkg BaseLib.h: Update IA32_CR4 strut to include all public fields
Based on Intel Software Develeper's Manual, add all fields in IA32_CR4.

Signed-off-by: Jason Voelz <jason.voelz@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-10 03:41:55 +00:00
Vitaly Cheptsov via Groups.Io df851da3ce MdePkg: Do not use CreateEventEx unless required
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2446

There are many firmwares in the wild not supporting CreateEventEx,
including devices less than 5 years old.

Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2020-01-10 03:25:59 +00:00
Eric Dong e18792566c UefiCpuPkg/PiSmmCpuDxeSmm: Add missed comments for parameter.
This issue caused by below change:
  SHA-1: b948a49615
  * UefiCpuPkg/PiSmmCpuDxeSmm: Pre-allocate PROCEDURE_TOKEN buffer
  REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2388

Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
2020-01-10 02:50:48 +00:00
Ard Biesheuvel f55477fe2d OvmfPkg: use HII type PCDs for TPM2 config related variables
The HII pages that are part of Tcg2ConfigDxe expect the following PCDs
to be of dynamic HII type, so declare them as such.

  gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer
  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev

Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-09 13:13:28 +00:00
Ard Biesheuvel cf3ad972a2 OvmfPkg: reorganize TPM2 support in DSC/FDF files
Put the TPM2 related DXE modules together in the DSC, and add a
TPM2 support header comment while at it.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-09 13:13:28 +00:00
Philippe Mathieu-Daud? 2649a735b2 BaseTools/PatchCheck.py: Ignore CR and LF characters in subject length
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=113

Strip the trailing characters before checking the subject line is
less than 72 characters.

Fixes: e61406708c
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>

Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
2020-01-09 06:09:33 +00:00
Ashish Singhal 972d887264 MdeModulePkg: Add EDK2 Platform Boot Manager Protocol
Add edk2 platform boot manager protocol which would have platform
specific refreshes to the auto enumerated as well as NV boot options
for the platform.

Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2020-01-08 07:28:39 +00:00
Pavana.K c9d7262843 CryptoPkg: Support for SHA384 & SHA512 RSA signing schemes
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2389

Currently RSA signing scheme support is available for MD5, SHA-1 or
SHA-256 algorithms.The fix is to extend this support for SHA384 and
SHA512.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>

Signed-off-by: Pavana.K <pavana.k@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2020-01-08 06:57:44 +00:00