mirror_edk2.git
3 years agoIntelSiliconPkg/Vtd: Add DMA_CTRL_PLATFORM_OPT_IN_FLAG dump
Jiewen Yao [Thu, 8 Mar 2018 12:40:57 +0000 (20:40 +0800)]
IntelSiliconPkg/Vtd: Add DMA_CTRL_PLATFORM_OPT_IN_FLAG dump

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoSecurityPkg/TcgPei: drop PeiReadOnlyVariable from Depex
Laszlo Ersek [Fri, 9 Mar 2018 19:06:31 +0000 (20:06 +0100)]
SecurityPkg/TcgPei: drop PeiReadOnlyVariable from Depex

TcgPei doesn't actually use the PEI-phase read-only variable service, so
drop that from the Depex.

This patch was inspired by commit ab9e11da6651 ("SecurityPkg/Tcg2Pei: drop
PeiReadOnlyVariable from Depex", 2018-03-09).

Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Suggested-by: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/Tcg2ConfigPei: trivial coding style updates
Laszlo Ersek [Fri, 9 Mar 2018 18:54:20 +0000 (19:54 +0100)]
OvmfPkg/Tcg2ConfigPei: trivial coding style updates

- the @file comment block should match between INF and main C file

- rewrap / refill columns to 79 characters

- insert space before opening paren

- prefix and suffix //-style comment block with empty // lines

- fix indentation of arguments in multi-line function call

- general tab spacing (indent step) is 2 in edk2, unlike QEMU's 4

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoOvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active
Brijesh Singh [Fri, 9 Mar 2018 16:06:03 +0000 (10:06 -0600)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active

Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
early in DXE phase and clears the C-bit from NonExistent entry -- which
is later split and accommodate the flash MMIO. When SMM is enabled, we
build two sets of page tables; first page table is used when executing
code in non SMM mode (SMM-less-pgtable) and second page table is used
when we are executing code in SMM mode (SMM-pgtable).

During boot time, AmdSevDxe driver clears the C-bit from the
SMM-less-pgtable. But when SMM is enabled, Qemu Flash services are used
from SMM mode.

In this patch we explicitly clear the C-bit from Qemu flash MMIO range
before we probe the flash. When OVMF is built with SMM_REQUIRE then
call to initialize the flash services happen after the SMM-pgtable is
created and processor has served the first SMI. At this time we will
have access to the SMM-pgtable.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
[lersek@redhat.com: trivial coding style improvements]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe
Marc-André Lureau [Thu, 22 Feb 2018 18:10:03 +0000 (19:10 +0100)]
OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe

The library registers a security management handler, to measure images
that are not measure in PEI phase. For example with the qemu PXE rom:

Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi

And the following binary_bios_measurements log entry seems to be
added:

PCR: 2 type: EV_EFI_BOOT_SERVICES_DRIVER      size: 0x4e digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4

The following order of operations ensures that 3rd party UEFI modules,
such as PCI option ROMs and other modules possibly loaded from outside
of firmware volumes, are measured into the TPM:

(1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2
    protocol sometime in the DXE phase (assuming a TPM2 chip is present,
    reported via PcdTpmInstanceGuid).

(2) The DXE core finds that no more drivers are left to dispatch from
    DXEFV, and we enter the BDS phase.

(3) OVMF's PlatformBootManagerLib connects all PCI root bridges
    non-recursively, producing PciIo instances and discovering PCI
    oproms.

(4) The dispatching of images that don't originate from FVs is deferred
    at this point, by
    "MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c".

(5) OVMF's PlatformBootManagerLib signals EndOfDxe.

(6) OVMF's PlatformBootManagerLib calls
    EfiBootManagerDispatchDeferredImages() -- the images deferred in
    step (4) are now dispatched.

(7) Image dispatch invokes the Security / Security2 Arch protocols
    (produced by SecurityStubDxe). In this patch, we hook
    DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch
    will try to locate the TCG2 protocol, and measure the image into the
    TPM2 chip with the protocol. Because of step (1), the TCG2 protocol
    will always be found and used (assuming a TPM2 chip is present).

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: include Tcg2Dxe module
Marc-André Lureau [Thu, 22 Feb 2018 16:53:16 +0000 (17:53 +0100)]
OvmfPkg: include Tcg2Dxe module

This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS.

The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2,
which is required for crypto-agile log. In fact, only upcoming 4.16
adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2:

[    0.000000] efi: EFI v2.70 by EDK II
[    0.000000] efi:  SMBIOS=0x3fa1f000  ACPI=0x3fbb6000  ACPI 2.0=0x3fbb6014  MEMATTR=0x3e7d4318  TPMEventLog=0x3db21018

$ python chipsec_util.py tpm parse_log binary_bios_measurements

[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements']

PCR: 0 type: EV_S_CRTM_VERSION                size: 0x2 digest: 1489f923c4dca729178b3e3233458550d8dddf29
+ version:
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB    size: 0x10 digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc
+ base: 0x820000 length: 0xe0000
PCR: 0 type: EV_EFI_PLATFORM_FIRMWARE_BLOB    size: 0x10 digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
+ base: 0x900000 length: 0xa00000
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x35 digest: 57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x24 digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x26 digest: 9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x24 digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7 type: EV_EFI_VARIABLE_DRIVER_CONFIG    size: 0x26 digest: 734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x3e digest: 252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x6e digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x80 digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x84 digest: 425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x9a digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0xbd digest: 20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1 type: EV_EFI_VARIABLE_BOOT             size: 0x88 digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4 type: EV_EFI_ACTION                    size: 0x28 digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5 type: EV_SEPARATOR                     size: 0x4 digest: 9069ca78e7450a285173431b3e52c5c25299e473

$ tpm2_pcrlist
sha1 :
  0  : 35bd1786b6909daad610d7598b1d620352d33b8a
  1  : ec0511e860206e0af13c31da2f9e943fb6ca353d
  2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  4  : 45a323382bd933f08e7f0e256bc8249e4095b1ec
  5  : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
  6  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  7  : 518bd167271fbb64589c61e43d8c0165861431d8
  8  : 0000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000
sha256 :
  0  : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
  1  : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
  2  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  3  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  4  : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
  5  : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
  6  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  7  : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068
  8  : 0000000000000000000000000000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000000000000000000000000000
sha384 :

The PhysicalPresenceLib is required, it sets some variables, but the
firmware doesn't act on it yet.

Laszlo Ersek explained on the list why Tpm2DeviceLib has to be
resolved differently for DXE_DRIVER modules in general and for
"Tcg2Dxe.inf" specifically:

  * We have a library class called Tpm2DeviceLib -- this is basically the
  set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
  Its leading comment says "This library abstract how to access TPM2
  hardware device".

  There are two *sets* of APIs in "Tpm2DeviceLib.h":

  (a) functions that deal with the TPM2 device:
      - Tpm2RequestUseTpm(),
      - Tpm2SubmitCommand()

      This set of APIs is supposed to be used by clients that *consume*
      the TPM2 device abstraction.

  (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be
      used by *providers* of various TPM2 device abstractions.

  * Then, we have two implementations (instances) of the Tpm2DeviceLib class:
  (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
  (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf

  (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the
  APIs listed under (a), and it does not implement (b) -- see
  EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for
  drivers that *consume* the TPM2 device abstraction. And, the (a) group
  of APIs is implemented by forwarding the requests to the TCG2 protocol.

  The idea here is that all the drivers that consume the TPM2 abstraction
  do not have to be statically linked with a large TPM2 device library
  instance; instead they are only linked (statically) with this "thin"
  library instance, and all the actual work is delegated to whichever
  driver that provides the singleton TCG2 protocol.

  (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant
  for the driver that offers (produces) the TCG2 protocol. This lib
  instance implements both (a) and (b) API groups.

  * Here's how things fit together:

  (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf"
  library instance (which has no lib class) is linked into "Tcg2Dxe.inf"
  via NULL class resolution. This simply means that before the
  "Tcg2Dxe.inf" entry point function is entered, the constructor function
  of "Tpm2InstanceLibDTpm.inf" will be called.

  (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and
  registers its own actual TPM2 command implementation with the
  "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe
  driver). This provides the back-end for the API set (a).

         TCG2 protocol provider (Tcg2Dxe.inf driver) launches
                      |
                      v
    NULL class: Tpm2InstanceLibDTpm instance construction
                      |
                      v
    Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
           backend registration for API set (a)

  (iii) The Tcg2Dxe driver exposes the TCG2 protocol.

  (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls
  land in Tcg2Dxe, via the protocol.

  (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a)
  from lib instance (2).

  (vi) Those functions call the "backend" functions registered by
  Tpm2DeviceLibDTpm in step (ii).

       TPM 2 consumer driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance
                |
                v
         TCG2 protocol interface
                |
                v
  TCG2 protocol provider: Tcg2Dxe.inf driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
                |
                v
     NULL class: Tpm2InstanceLibDTpm instance
        (via earlier registration)
                |
                v
       TPM2 chip (actual hardware)

  * So that is the "router" pattern in edk2. Namely,

  - Consumers of an abstraction use a thin library instance.

  - The thin library instance calls a firmware-global (singleton) service,
    i.e. a PPI (in the PEI phase) or protocol (in the DXE phase).

  - The PEIM providing the PPI, or the DXE driver providing the protocol,
    don't themselves implement the actual service either. Instead they
    offer a "registration" service too, and they only connect the incoming
    "consumer" calls to the earlier registered back-end(s).

  - The "registration service", for back-ends to use, may take various
    forms.

    It can be exposed globally to the rest of the firmware, as
    another member function of the PPI / protocol structure. Then backends
    can be provided by separate PEIMs / DXE drivers.

    Or else, the registration service can be exposed as just another
    library API. In this case, the backends are provided as NULL class
    library instances, and a platform  DSC file links them into the PEIM /
    DXE driver via NULL class resolutions. The backend lib instances call
    the registration service in their own respective constructor
    functions.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: include Tcg2Pei module
Marc-André Lureau [Thu, 22 Feb 2018 14:26:34 +0000 (15:26 +0100)]
OvmfPkg: include Tcg2Pei module

This module will initialize TPM device, measure reported FVs and BIOS
version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format
compatibility, but the SHA-256 measurements and TCG 2 log format are
now recommended.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: add customized Tcg2ConfigPei clone
Marc-André Lureau [Thu, 22 Feb 2018 13:20:58 +0000 (14:20 +0100)]
OvmfPkg: add customized Tcg2ConfigPei clone

The Tcg2ConfigPei module informs the firmware globally about the TPM
device type, by setting the PcdTpmInstanceGuid PCD to the appropriate
GUID value. The original module under SecurityPkg can perform device
detection, or read a cached value from a non-volatile UEFI variable.

OvmfPkg's clone of the module only performs the TPM2 hardware detection.

This is what the module does:

- Check the QEMU hardware for TPM2 availability only

- If found, set the dynamic PCD "PcdTpmInstanceGuid" to
  &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of
  the firmware about the TPM type.

- Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the
  PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD.
  In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting
  and the consumption of the "TPM type" PCD.

- If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid.
  (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if
  no TPM2 is available. So in that case our Tcg2ConfigPei must do it.)

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg: simplify SecurityStubDxe.inf inclusion
Marc-André Lureau [Mon, 5 Mar 2018 16:14:18 +0000 (17:14 +0100)]
OvmfPkg: simplify SecurityStubDxe.inf inclusion

SecurityStubDxe.inf should be included unconditionally.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg/Core/Pei: fix REGISITER -> REGISTER typo
Marc-André Lureau [Fri, 2 Mar 2018 17:19:33 +0000 (18:19 +0100)]
MdeModulePkg/Core/Pei: fix REGISITER -> REGISTER typo

No functional changes.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoSecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex
Marc-André Lureau [Thu, 1 Mar 2018 15:09:39 +0000 (16:09 +0100)]
SecurityPkg/Tcg2Pei: drop PeiReadOnlyVariable from Depex

The module doesn't use read-only variable.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoBaseTools: GlobalData remove unused variable
Carsey, Jaben [Thu, 8 Mar 2018 00:45:18 +0000 (08:45 +0800)]
BaseTools: GlobalData remove unused variable

gWideStringPattern is not used.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools: Fix parse OFFSET_OF get wrong offset
Feng, YunhuaX [Fri, 9 Mar 2018 08:46:00 +0000 (16:46 +0800)]
BaseTools: Fix parse OFFSET_OF get wrong offset

Fix parse OFFSET_OF get wrong offset

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools: Fix a bug for --pcd used in ConditionalStatement calculate
Yonghong Zhu [Fri, 9 Mar 2018 07:18:35 +0000 (15:18 +0800)]
BaseTools: Fix a bug for --pcd used in ConditionalStatement calculate

Move the GlobalData.BuildOptionPcd before FdfParser() function and add
type check for Pcd item.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Update --pcd parser to support flexible pcd format
Yonghong Zhu [Wed, 7 Mar 2018 06:14:43 +0000 (14:14 +0800)]
BaseTools: Update --pcd parser to support flexible pcd format

This patch update --pcd parser to support flexible pcd format.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Fixed Pcd from command line issue.
BobCF [Thu, 8 Mar 2018 05:56:21 +0000 (13:56 +0800)]
BaseTools: Fixed Pcd from command line issue.

Save the pcd command line value in Pcd object

Contributed-under: TianoCore Contribution Agreement 1.1
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>
3 years agoIntelSiliconPkg/Vtd: Add MapHandleInfo in VtdDxe.
Jiewen Yao [Thu, 8 Mar 2018 11:42:49 +0000 (19:42 +0800)]
IntelSiliconPkg/Vtd: Add MapHandleInfo in VtdDxe.

This information is to record which device requested which DMA buffer.
It can be used for DMA buffer analysis.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoSecurityPkg: also clear HashInterfaceHob.SupportedHashMask
Marc-Andr? Lureau [Wed, 7 Mar 2018 15:57:39 +0000 (23:57 +0800)]
SecurityPkg: also clear HashInterfaceHob.SupportedHashMask

Commit 4cc2b63bd829426b05bad0d8952f1855a10d6ed7 fixed an out of bounds
ZeroMem() call. However, as Laszlo Ersek pointed out, the intent was
to clear all but the Identifier (to revert the effect of
RegisterHashInterfaceLib()). For that, it should clear the
SupportedHashMask too.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-Andr? Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoSecurityPkg OpalPasswordExtraInfoVariable.h: Remove it
Star Zeng [Tue, 6 Mar 2018 13:47:06 +0000 (21:47 +0800)]
SecurityPkg OpalPasswordExtraInfoVariable.h: Remove it

Remove OpalPasswordExtraInfoVariable.h as it is not been used
anymore.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg OpalPasswordSupportLib: Remove it
Star Zeng [Sun, 11 Feb 2018 06:40:03 +0000 (14:40 +0800)]
SecurityPkg OpalPasswordSupportLib: Remove it

Remove OpalPasswordSupportLib as it is not been used
anymore.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg OpalPassword: Remove old solution
Star Zeng [Tue, 6 Mar 2018 13:43:20 +0000 (21:43 +0800)]
SecurityPkg OpalPassword: Remove old solution

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg OpalPassword: Add solution without SMM device code
Star Zeng [Sun, 11 Feb 2018 03:00:44 +0000 (11:00 +0800)]
SecurityPkg OpalPassword: Add solution without SMM device code

After IOMMU is enabled in S3, original solution with SMM device
code (OpalPasswordSmm) to unlock OPAL device for S3 will not work
as the DMA operation will be aborted without granted DMA buffer.
Instead, this solution is to add OpalPasswordPei to eliminate
SMM device code, and OPAL setup UI produced by OpalPasswordDxe
will be updated to send requests (set password, update password,
and etc), and then the requests will be processed in next boot
before SmmReadyToLock, password and device info will be saved to
lock box used by OpalPasswordPei to unlock OPAL device for S3.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg TcgStorageCoreLib: Make it be base type really
Star Zeng [Tue, 6 Mar 2018 13:37:22 +0000 (21:37 +0800)]
SecurityPkg TcgStorageCoreLib: Make it be base type really

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg TcgStorageOpalLib: Make it be base type really
Star Zeng [Mon, 15 Jan 2018 10:42:02 +0000 (18:42 +0800)]
SecurityPkg TcgStorageOpalLib: Make it be base type really

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg LockBoxLib: Support LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY
Star Zeng [Sun, 11 Feb 2018 02:01:21 +0000 (10:01 +0800)]
MdeModulePkg LockBoxLib: Support LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY

With this flag, the LockBox can be restored in S3 resume only.
The LockBox can not be restored after SmmReadyToLock in normal boot
and after EndOfS3Resume in S3 resume.
It can not be set together with LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoUefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory
Jian J Wang [Fri, 2 Mar 2018 02:46:05 +0000 (10:46 +0800)]
UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory

if PcdDxeNxMemoryProtectionPolicy is enabled for EfiReservedMemoryType
of memory, #PF will be triggered for each APs after ExitBootServices
in SCRT test. The root cause is that AP wakeup code executed at that
time is stored in memory of type EfiReservedMemoryType (referenced by
global mReservedApLoopFunc), which is marked as non-executable.

This patch fixes this issue by setting memory of mReservedApLoopFunc to
be executable immediately after allocation.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg/Core: fix too many available pages between BS_Data
Jian J Wang [Wed, 7 Mar 2018 03:26:32 +0000 (11:26 +0800)]
MdeModulePkg/Core: fix too many available pages between BS_Data

The root cause is an unnecessary check to Size parameter in function
AdjustMemoryS(). It will cause one standalone free page (happen to have
Guard page around) in the free memory list cannot be allocated, even if
the requested memory size is less than a page.

  //
  // At least one more page needed for Guard page.
  //
  if (Size < (SizeRequested + EFI_PAGES_TO_SIZE (1))) {
    return 0;
  }

The following code in the same function actually covers above check
implicitly. So the fix is simply removing above check.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoSecurityPkg/SmmTcg2PhysicalPresenceLib: Fix coding style issue
Dandan Bi [Wed, 7 Mar 2018 05:24:37 +0000 (13:24 +0800)]
SecurityPkg/SmmTcg2PhysicalPresenceLib: Fix coding style issue

Boolean values do not need to use explicit comparisons
to TRUE or FALSE.

Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by:Chao Zhang <chao.b.zhang@intel.com>

3 years agoUefiCpuPkg/CpuCommonFeaturesLib: Fix coding style issue
Dandan Bi [Wed, 7 Mar 2018 05:20:29 +0000 (13:20 +0800)]
UefiCpuPkg/CpuCommonFeaturesLib: Fix coding style issue

Boolean values do not need to use explicit comparisons
to TRUE or FALSE.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/DriverSampleDxe: Refine the sample case for UNION type
Dandan Bi [Wed, 7 Mar 2018 02:34:00 +0000 (10:34 +0800)]
MdeModulePkg/DriverSampleDxe: Refine the sample case for UNION type

The example of UNION storage is not good, now update it.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/header.makefile: revert gcc-8 "-Wno-xxx" options on OSX
Laszlo Ersek [Wed, 7 Mar 2018 09:17:28 +0000 (10:17 +0100)]
BaseTools/header.makefile: revert gcc-8 "-Wno-xxx" options on OSX

I recently added the gcc-8 specific "-Wno-stringop-truncation" and
"-Wno-restrict" options to BUILD_CFLAGS, both for "Darwin" (XCODE5 /
clang, OSX) and otherwise (gcc, Linux / Cygwin).

I also regression-tested the change with gcc-4.8 on Linux -- gcc-4.8 does
not know either of the (gcc-8 specific) "-Wno-stringop-truncation" and
"-Wno-restrict" options, yet the build completed fine (by GCC design).

Regarding OSX, my expectation was that

- XCODE5 / clang would either recognize these warnings options (because
  clang does recognize most -W options of gcc),

- or, similarly to gcc, clang would simply ignore the "-Wno-xxx" flags
  that it didn't recognize.

Neither is the case; the new flags have broken the BaseTools build on OSX.
Revert them (for OSX only).

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Liming Gao <liming.gao@intel.com>
Fixes: 1d212a83df0eaf32a6f5d4159beb2d77832e0231
Fixes: 9222154ae7b3eef75ae88cdb56158256227cb929
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoSecurityPkg: only clear HashInterface information
Marc-Andr? Lureau [Tue, 6 Mar 2018 20:27:18 +0000 (04:27 +0800)]
SecurityPkg: only clear HashInterface information

The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
HOB list corruption. Instead, just clear the HashInterface fields, as
I suppose was originally intended.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-Andr? Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/Core: Fix feature conflict between NX and Stack guard
Hao Wu [Tue, 6 Mar 2018 11:34:38 +0000 (19:34 +0800)]
MdeModulePkg/Core: Fix feature conflict between NX and Stack guard

If enabled, NX memory protection feature will mark some types of active
memory as NX (non-executable), which includes the first page of the stack.
This will overwrite the attributes of the first page of the stack if the
stack guard feature is also enabled.

The solution is to override the attributes setting to the first page of
the stack by adding back the 'EFI_MEMORY_RP' attribute when the stack
guard feature is enabled.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/Core: Refine handling NULL detection in NX setting
Hao Wu [Tue, 6 Mar 2018 10:36:37 +0000 (18:36 +0800)]
MdeModulePkg/Core: Refine handling NULL detection in NX setting

The commit rewrites the logic in function
InitializeDxeNxMemoryProtectionPolicy() for handling the first page
(page 0) when NULL pointer detection feature is enabled.

Instead of skip setting the page 0, the codes will now override the
attribute setting of page 0 by adding the 'EFI_MEMORY_RP' attribute.

The purpose is to make it easy for other special handling of pages
(e.g. the first page of the stack when stack guard feature is enabled).

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoShellBinPkg: Ia32/X64 Shell binary update.
Ruiyu Ni [Wed, 7 Mar 2018 08:30:32 +0000 (16:30 +0800)]
ShellBinPkg: Ia32/X64 Shell binary update.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/UefiBootManagerLib: limit recursive call depth
Heyi Guo [Thu, 1 Mar 2018 02:39:32 +0000 (10:39 +0800)]
MdeModulePkg/UefiBootManagerLib: limit recursive call depth

Function BmRepairAllControllers may recursively call itself if some
driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, driver health protocol of some buggy third party driver may
always return such status even after one and another reconnect. The
endless iteration will cause stack overflow and then system exception,
and it may be not easy to find that the exception is actually caused
by stack overflow.

So we limit the number of reconnect retry to 10 to improve code
robustness, and DEBUG_CODE is moved ahead before recursive repair to
track the repair result.

We also remove a duplicated declaration of BmRepairAllControllers() in
InternalBm.h in this patch, for it is only a trivial change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg/NullMemoryTest: Fix bug in CompatibleRangeTest
Ruiyu Ni [Tue, 6 Mar 2018 03:31:57 +0000 (11:31 +0800)]
MdeModulePkg/NullMemoryTest: Fix bug in CompatibleRangeTest

CompatibleRangeTest() contains two bugs:
1. It doesn't reject the memory above 16MB
2. it cannot handle the case when the partial or whole range of
   requested memory is already tested.

The patch fixes the two bugs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/NullMemoryTest: Change prototype of ConvertToTestedMemory
Ruiyu Ni [Tue, 6 Mar 2018 03:04:27 +0000 (11:04 +0800)]
MdeModulePkg/NullMemoryTest: Change prototype of ConvertToTestedMemory

The patch should not impact the functionality.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoArmPkg/TimerDxe: Always perform an EOI, even for spurious interrupts
Marc Zyngier [Tue, 6 Mar 2018 13:00:35 +0000 (13:00 +0000)]
ArmPkg/TimerDxe: Always perform an EOI, even for spurious interrupts

The generic timer driver only EOIs the timer interrupt if
the ISTATUS bit is set. This is completely fine if you pretend
that spurious interrupts do not exist. But as a matter of fact,
they do, and the first one will leave the interrupt activated
at the GIC level, making sure that no other interrupt can make
it anymore.

Making sure that each interrupt Ack is paired with an EOI is the
way to go. Oh, and enabling the interrupt each time it is taken
is completely pointless. We entered this function for a good
reason...

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoIntelSiliconPkg VTdPmrPei: Add PcdVTdPeiDmaBufferSize(S3)
Star Zeng [Mon, 5 Mar 2018 14:10:16 +0000 (22:10 +0800)]
IntelSiliconPkg VTdPmrPei: Add PcdVTdPeiDmaBufferSize(S3)

Add PcdVTdPeiDmaBufferSize(S3) to replace the hard coded value
TOTAL_DMA_BUFFER_SIZE and TOTAL_DMA_BUFFER_SIZE_S3 in IntelVTdPmrPei.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoIntelSiliconPkg VTdPmrPei: Return SUCCESS when Mapping == NULL in Unmap
Star Zeng [Wed, 14 Feb 2018 09:10:36 +0000 (17:10 +0800)]
IntelSiliconPkg VTdPmrPei: Return SUCCESS when Mapping == NULL in Unmap

NULL is returned to Mapping when Operation is BusMasterCommonBuffer or
BusMasterCommonBuffer64 in PeiIoMmuMap().
So Mapping == NULL is valid when calling PeiIoMmuUnmap().

940dbd071e9f01717236af236740aa0da716805f wrongly changed EFI_SUCCESS
to EFI_INVALID_PARAMETER when Mapping == NULL in PeiIoMmuUnmap().
This patch is to correct it.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoOvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map
Laszlo Ersek [Thu, 1 Mar 2018 21:05:55 +0000 (22:05 +0100)]
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map

Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:

  [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
  http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
  https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html

Original commit message from Brijesh:

> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
> both guest and hypervisor. Since the data need to be accessed by both
> hence we must map the SMMSaved State area as unencrypted (i.e C-bit
> cleared).
>
> This patch clears the SavedStateArea address before SMBASE relocation.
> Currently, we do not clear the SavedStateArea address after SMBASE is
> relocated due to the following reasons:
>
> 1) Guest BIOS never access the relocated SavedStateArea.
>
> 2) The C-bit works on page-aligned address, but the SavedStateArea
> address is not a page-aligned. Theoretically, we could roundup the
> address and clear the C-bit of aligned address but looking carefully we
> found that some portion of the page contains code -- which will causes a
> bigger issue for the SEV guest. When SEV is enabled, all the code must
> be encrypted otherwise hardware will cause trap.

Changes by Laszlo:

- separate AmdSevDxe bits from SmmCpuFeaturesLib bits;

- spell out PcdLib dependency with #include and in LibraryClasses;

- replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation
  with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages()
  function;

- consequently, pass page-aligned BaseAddress to
  MemEncryptSevClearPageEncMask();

- zero the pages before clearing the C-bit;

- pass Flush=TRUE to MemEncryptSevClearPageEncMask();

- harden the treatment of MemEncryptSevClearPageEncMask() failure.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map
Laszlo Ersek [Thu, 1 Mar 2018 19:59:12 +0000 (20:59 +0100)]
OvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map

Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:

  [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
  http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
  https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html

Once PiSmmCpuDxeSmm relocates SMBASE for all VCPUs, the pages of the
initial SMRAM save state map can be re-encrypted (including zeroing them
out after setting the C-bit on them), and they can be released to DXE for
general use (undoing the allocation that we did in PlatformPei's
AmdSevInitialize() function).

The decryption of the same pages (which will occur chronologically
earlier) is implemented in the next patch; hence the "re-encryption" part
of this patch is currently a no-op. The series is structured like this in
order to be bisection-friendly. If the decryption patch preceded this
patch, then an info leak would be created while standing between the
patches.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/PlatformPei: SEV: allocate pages of initial SMRAM save state map
Laszlo Ersek [Thu, 1 Mar 2018 16:59:19 +0000 (17:59 +0100)]
OvmfPkg/PlatformPei: SEV: allocate pages of initial SMRAM save state map

In the next two patches, we'll temporarily decrypt the pages containing
the initial SMRAM save state map, for SMBASE relocation. (Unlike the
separate, relocated SMRAM save state map of each VCPU, the original,
shared map behaves similarly to a "common buffer" between guest and host.)
The decryption will occur near the beginning of the DXE phase, in
AmdSevDxe, and the re-encryption will occur in PiSmmCpuDxeSmm, via OVMF's
SmmCpuFeaturesLib instance.

There is a non-trivial time gap between these two points, and the DXE
phase might use the pages overlapping the initial SMRAM save state map for
arbitrary purposes meanwhile. In order to prevent any information leak
towards the hypervisor, make sure the DXE phase puts nothing in those
pages until re-encryption is done.

Creating a memalloc HOB for the area in question is safe:

- the temporary SEC/PEI RAM (stack and heap) is based at
  PcdOvmfSecPeiTempRamBase, which is above 8MB,

- the permanent PEI RAM (installed in PlatformPei's PublishPeiMemory()
  function) never starts below PcdOvmfDxeMemFvBase, which is also above
  8MB.

The allocated pages can be released to the DXE phase after SMBASE
relocation and re-encryption are complete.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map
Laszlo Ersek [Thu, 1 Mar 2018 16:31:44 +0000 (17:31 +0100)]
OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map

In the next three patches, we're going to modify three modules under
OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest,
each affected module will have to know the page range that covers the
initial (pre-SMBASE relocation) SMRAM save state map. Add a helper
function to MemEncryptSevLib that calculates the "base address" and
"number of pages" constants for this page range.

(In a RELEASE build -- i.e., with assertions disabled and optimization
enabled --, the helper function can be compiled to store two constants
determined at compile time.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/AmdSevDxe: refresh #includes and LibraryClasses
Laszlo Ersek [Thu, 1 Mar 2018 20:43:09 +0000 (21:43 +0100)]
OvmfPkg/AmdSevDxe: refresh #includes and LibraryClasses

List those and only those libraries that are used.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections
Laszlo Ersek [Thu, 1 Mar 2018 14:02:11 +0000 (15:02 +0100)]
OvmfPkg/AmdSevDxe: sort #includes, and entries in INF file sections

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/AmdSevDxe: rewrap to 79 characters width
Laszlo Ersek [Thu, 1 Mar 2018 13:32:23 +0000 (14:32 +0100)]
OvmfPkg/AmdSevDxe: rewrap to 79 characters width

There are many overlong lines; it's hard to work with the module like
this. Rewrap all files to 79 columns.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: remove unneeded #includes and LibraryClasses
Laszlo Ersek [Thu, 1 Mar 2018 18:20:37 +0000 (19:20 +0100)]
OvmfPkg/SmmCpuFeaturesLib: remove unneeded #includes and LibraryClasses

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: sort #includes, and entries in INF file sections
Laszlo Ersek [Thu, 1 Mar 2018 18:20:37 +0000 (19:20 +0100)]
OvmfPkg/SmmCpuFeaturesLib: sort #includes, and entries in INF file sections

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: upper-case the "static" keyword
Laszlo Ersek [Thu, 1 Mar 2018 18:20:37 +0000 (19:20 +0100)]
OvmfPkg/SmmCpuFeaturesLib: upper-case the "static" keyword

In edk2, the "static" keyword is spelled "STATIC". Also let "STATIC" stand
alone on a line in function definitions.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns
Laszlo Ersek [Thu, 1 Mar 2018 17:55:09 +0000 (18:55 +0100)]
OvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns

There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.

(

The rewrapping of the "mSmmCpuRegisterRanges" and "mSmmCpuWidthOffset"
arrays was verified by hexdumping the arrays in
SmmCpuFeaturesLibConstructor(), both before and after the patch, and
comparing the dumps.

Contents of "mSmmCpuRegisterRanges", IA32 build:

> mSmmCpuRegisterRanges: {
> mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 14 00 00 00
> mSmmCpuRegisterRanges: 000010 2E 00 00 00 1B 00 00 00 33 00 00 00 36 00 00 00
> mSmmCpuRegisterRanges: 000020 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: }

Contents of "mSmmCpuRegisterRanges", X64 build:

> mSmmCpuRegisterRanges: {
> mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000010 14 00 00 00 2E 00 00 00 1B 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000020 33 00 00 00 36 00 00 00 04 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: }

Contents of "mSmmCpuWidthOffset", both IA32 and X64 builds:

> mSmmCpuWidthOffset: {
> mSmmCpuWidthOffset: 000000 00 00 00 00 00 00 00 00 00 00 00 08 00 00 68 02
> mSmmCpuWidthOffset: 000010 6C 02 00 00 00 08 00 00 88 02 8C 02 00 00 00 08
> mSmmCpuWidthOffset: 000020 00 00 78 02 7C 02 00 00 00 00 00 00 64 02 68 02
> mSmmCpuWidthOffset: 000030 00 00 00 00 00 00 84 02 88 02 00 00 00 00 00 00
> mSmmCpuWidthOffset: 000040 74 02 78 02 00 00 00 00 00 00 00 00 04 00 00 00
> mSmmCpuWidthOffset: 000050 04 04 A8 03 00 02 00 00 00 00 04 04 AC 03 10 02
> mSmmCpuWidthOffset: 000060 00 00 00 00 04 04 B0 03 20 02 00 00 00 00 04 04
> mSmmCpuWidthOffset: 000070 B4 03 30 02 00 00 00 00 04 04 B8 03 40 02 00 00
> mSmmCpuWidthOffset: 000080 00 00 04 04 BC 03 50 02 00 00 00 00 00 04 00 00
> mSmmCpuWidthOffset: 000090 70 02 00 00 00 00 04 04 C4 03 90 02 00 00 00 00
> mSmmCpuWidthOffset: 0000A0 04 08 C8 03 60 03 64 03 00 00 04 08 CC 03 68 03
> mSmmCpuWidthOffset: 0000B0 6C 03 00 00 00 08 00 00 B8 03 BC 03 01 00 00 08
> mSmmCpuWidthOffset: 0000C0 00 00 B0 03 B4 03 01 00 00 08 00 00 A8 03 AC 03
> mSmmCpuWidthOffset: 0000D0 01 00 00 08 00 00 A0 03 A4 03 01 00 00 08 00 00
> mSmmCpuWidthOffset: 0000E0 98 03 9C 03 01 00 00 08 00 00 90 03 94 03 01 00
> mSmmCpuWidthOffset: 0000F0 00 08 00 00 88 03 8C 03 01 00 00 08 00 00 80 03
> mSmmCpuWidthOffset: 000100 84 03 01 00 04 08 D0 03 F8 03 FC 03 01 00 04 08
> mSmmCpuWidthOffset: 000110 DC 03 E0 03 E4 03 01 00 04 08 D4 03 F0 03 F4 03
> mSmmCpuWidthOffset: 000120 01 00 04 08 D8 03 E8 03 EC 03 01 00 04 08 E0 03
> mSmmCpuWidthOffset: 000130 D8 03 DC 03 01 00 04 08 E4 03 D0 03 D4 03 01 00
> mSmmCpuWidthOffset: 000140 04 08 E8 03 C8 03 CC 03 01 00 04 08 EC 03 C0 03
> mSmmCpuWidthOffset: 000150 C4 03 01 00 04 08 F0 03 78 03 7C 03 01 00 04 08
> mSmmCpuWidthOffset: 000160 F4 03 70 03 74 03 01 00 04 08 FC 03 58 03 5C 03
> mSmmCpuWidthOffset: 000170 00 00 04 08 F8 03 50 03 54 03 00 00 00 04 00 00
> mSmmCpuWidthOffset: 000180 48 03 4C 03 00 00
> mSmmCpuWidthOffset: }

)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/PlatformPei: sort #includes in "AmdSev.c"
Laszlo Ersek [Thu, 1 Mar 2018 16:52:37 +0000 (17:52 +0100)]
OvmfPkg/PlatformPei: sort #includes in "AmdSev.c"

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: sort #includes, and entries in INF file sections
Laszlo Ersek [Thu, 1 Mar 2018 14:02:11 +0000 (15:02 +0100)]
OvmfPkg/MemEncryptSevLib: sort #includes, and entries in INF file sections

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "clear" reference to the C-bit with a "set" reference.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "set" reference to the C-bit with a "clear" reference.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up SetMemoryEncDec() comment block
Laszlo Ersek [Thu, 1 Mar 2018 14:10:04 +0000 (15:10 +0100)]
OvmfPkg/MemEncryptSevLib: clean up SetMemoryEncDec() comment block

Document the "Cr3BaseAddress" parameter, and correct several parameter
references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Replace any
leftover "clear" references to the C-bit with "set" references. Also
remove any excess space in the comment block, and unindent the trailing
"**/" if necessary. Correct several parameter references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary. Correct several parameter references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() decl
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() decl

The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/MemEncryptSevLib: rewrap to 79 characters width
Laszlo Ersek [Thu, 1 Mar 2018 13:32:23 +0000 (14:32 +0100)]
OvmfPkg/MemEncryptSevLib: rewrap to 79 characters width

There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoMdeModulePkg/Terminal: ReadKeyStrokeEx always return key state
Ruiyu Ni [Sat, 24 Feb 2018 07:13:19 +0000 (15:13 +0800)]
MdeModulePkg/Terminal: ReadKeyStrokeEx always return key state

Because terminal doesn't support shift and toggle key state,
ReadKeyStrokeEx just sets the two states to 0.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoBaseTools/GenVtf: silence false "stringop-overflow" warning with memcpy()
Laszlo Ersek [Fri, 2 Mar 2018 16:11:52 +0000 (17:11 +0100)]
BaseTools/GenVtf: silence false "stringop-overflow" warning with memcpy()

gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-overflow" in "-Wall". This warning is documented in detail at
<https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says

> Warn for calls to string manipulation functions such as memcpy and
> strcpy that are determined to overflow the destination buffer.

It breaks the BaseTools build with:

> GenVtf.c: In function 'ConvertVersionInfo':
> GenVtf.c:132:7: error: 'strncpy' specified bound depends on the length
> of the source argument [-Werror=stringop-overflow=]
>        strncpy (TemStr + 4 - Length, Str, Length);
>        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> GenVtf.c:130:14: note: length computed here
>      Length = strlen(Str);
>               ^~~~~~~~~~~

It is a false positive because, while the bound equals the length of the
source argument, the destination pointer is moved back towards the
beginning of the destination buffer by the same amount (and this amount is
range-checked first, so we can't precede the start of the dest buffer).

Replace both strncpy() calls with memcpy().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Cole Robinson <crobinso@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/header.makefile: add "-Wno-restrict"
Laszlo Ersek [Fri, 2 Mar 2018 16:11:52 +0000 (17:11 +0100)]
BaseTools/header.makefile: add "-Wno-restrict"

gcc-8 (which is part of Fedora 28) enables the new warning
"-Wrestrict" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says

> Warn when an object referenced by a restrict-qualified parameter (or, in
> C++, a __restrict-qualified parameter) is aliased by another argument,
> or when copies between such objects overlap.

It breaks the BaseTools build (in the Brotli compression library) with:

> In function 'ProcessCommandsInternal',
>     inlined from 'ProcessCommands' at dec/decode.c:1828:10:
> dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631
> bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at
> offset 16 [-Werror=restrict]
>          memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16));
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In function 'ProcessCommandsInternal',
>     inlined from 'SafeProcessCommands' at dec/decode.c:1833:10:
> dec/decode.c:1781:9: error: 'memcpy' accessing between 17 and 2147483631
> bytes at offsets 16 and 16 overlaps between 17 and 2147483631 bytes at
> offset 16 [-Werror=restrict]
>          memcpy(copy_dst + 16, copy_src + 16, (size_t)(i - 16));
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Paolo Bonzini <pbonzini@redhat.com> analyzed the Brotli source in detail,
and concluded that the warning is a false positive:

> This seems safe to me, because it's preceded by:
>
>     uint8_t* copy_dst = &s->ringbuffer[pos];
>     uint8_t* copy_src = &s->ringbuffer[src_start];
>     int dst_end = pos + i;
>     int src_end = src_start + i;
>     if (src_end > pos && dst_end > src_start) {
>       /* Regions intersect. */
>       goto CommandPostWrapCopy;
>     }
>
> If [src_start, src_start + i) and [pos, pos + i) don't intersect, then
> neither do [src_start + 16, src_start + i) and [pos + 16, pos + i).
>
> The if seems okay:
>
>        (src_start + i > pos && pos + i > src_start)
>
> which can be rewritten to:
>
>        (pos < src_start + i && src_start < pos + i)
>
> Then the numbers are in one of these two orders:
>
>      pos <= src_start < pos + i <= src_start + i
>      src_start <= pos < src_start + i <= pos + i
>
> These two would be allowed by the "if", but they can only happen if pos
> == src_start so they degenerate to the same two orders above:
>
>      pos <= src_start < src_start + i <= pos + i
>      src_start <= pos < pos + i <= src_start + i
>
> So it is a false positive in GCC.

Disable the warning for now.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reported-by: Cole Robinson <crobinso@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/header.makefile: add "-Wno-stringop-truncation"
Laszlo Ersek [Fri, 2 Mar 2018 16:11:52 +0000 (17:11 +0100)]
BaseTools/header.makefile: add "-Wno-stringop-truncation"

gcc-8 (which is part of Fedora 28) enables the new warning
"-Wstringop-truncation" in "-Wall". This warning is documented in detail
at <https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html>; the
introduction says

> Warn for calls to bounded string manipulation functions such as strncat,
> strncpy, and stpncpy that may either truncate the copied string or leave
> the destination unchanged.

It breaks the BaseTools build with:

> EfiUtilityMsgs.c: In function 'PrintMessage':
> EfiUtilityMsgs.c:484:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
>          strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:469:9: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
>          strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> EfiUtilityMsgs.c:511:5: error: 'strncat' output may be truncated copying
> between 0 and 511 bytes from a string of length 511
> [-Werror=stringop-truncation]
>      strncat (Line, Line2, MAX_LINE_LEN - strlen (Line) - 1);
>      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The right way to fix the warning would be to implement string concat with
snprintf(). However, Microsoft does not appear to support snprintf()
before VS2015
<https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010>,
so we just have to shut up the warning. The strncat() calls flagged above
are valid BTW.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Cole Robinson <crobinso@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: update DNS_DEVICE_PATH/URI_DEVICE_PATH definition
Yonghong Zhu [Thu, 1 Mar 2018 07:04:51 +0000 (15:04 +0800)]
BaseTools: update DNS_DEVICE_PATH/URI_DEVICE_PATH definition

Update this two definition to align with MdePkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg UsbMass: Correct comment about TPL for BLOCK IO APIs
Star Zeng [Sat, 3 Mar 2018 07:26:17 +0000 (15:26 +0800)]
MdeModulePkg UsbMass: Correct comment about TPL for BLOCK IO APIs

Current BLOCK IO API code is using TPL_CALLBACK,
but comment is saying TPL_NOTIFY.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoShellPkg/ConsoleLogger: Fix a typo in UpdateDisplayFromHistory()
Hao Wu [Sat, 3 Mar 2018 02:59:05 +0000 (10:59 +0800)]
ShellPkg/ConsoleLogger: Fix a typo in UpdateDisplayFromHistory()

Within function UpdateDisplayFromHistory():

When getting a character with different attribute with the current one,
the statement to compare the character with a 'NULL' char should be:

*StringSegmentEnd != CHAR_NULL

rather than:

StringSegmentEnd != CHAR_NULL

This commit resolves this typo.

Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/UsbMass: Retry CMD for MediaChanged sense key
Ruiyu Ni [Fri, 2 Mar 2018 09:35:41 +0000 (17:35 +0800)]
MdeModulePkg/UsbMass: Retry CMD for MediaChanged sense key

When a USB device reports failure for a CMD and REQUEST SENSE returns
Media Changed key, UsbBootExecCmdWithRetry() stops to retry CMD and
returns EFI_MEDIA_CHANGED to caller.

For this case, the CMD should be retried until success, getting
NoMedia sense key or timeout.
The patch updates UsbBootExecCmdWithRetry() to follow the above
rule so EFI_MEDIA_CHANGED is no longer returned.

UsbBootDetectMedia() is updated accordingly.

Because UsbBootGetParams() is called for new plugged USB storage,
and some USB storage devices may report Media Changed key,
UsbBootGetParams() is updated to treat it as a Success.
This change could fix the issue that some USB storage devices
cannot be detected.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UsbMass: remove unnecessary RestoreTPL() call
Ruiyu Ni [Fri, 2 Mar 2018 09:33:15 +0000 (17:33 +0800)]
MdeModulePkg/UsbMass: remove unnecessary RestoreTPL() call

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UsbMass: Add more debug message
Ruiyu Ni [Fri, 2 Mar 2018 09:31:50 +0000 (17:31 +0800)]
MdeModulePkg/UsbMass: Add more debug message

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UsbMass: Revert "map -r" media change detection fix
Ruiyu Ni [Fri, 2 Mar 2018 09:30:06 +0000 (17:30 +0800)]
MdeModulePkg/UsbMass: Revert "map -r" media change detection fix

This reverts commit a662afb5b023a187ef638d3cb0e0c313ad39a7fc.
* MdeModulePkg/UsbStorage: Fix "map -r" cannot detect media change

The above commit fixed the following issue:
When system boots to Shell without CDROM inside USB CDROM drive,
and then user inserts the CDROM with Eltorito file system,
"map -r" cannot show the new ELtorito file system.
The commit caused EFI_MEDIA_CHANGED status returned from
UsbBootDetectMedia().

But that fix exposes another issue:
When issuing ReadCapacity command to certain USB key
(Kingston DataTraveler G3 8GB) after it's hot-plugged, USB device
returns STALL error and RequestSense command returns media changed
sense data. (Most of the USB keys return SUCCESS for ReadCapacity
command after hot-plug.)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UsbMass: Revert POWER_ON(29h) ASC handling logic
Ruiyu Ni [Fri, 2 Mar 2018 09:29:56 +0000 (17:29 +0800)]
MdeModulePkg/UsbMass: Revert POWER_ON(29h) ASC handling logic

This reverts commit 6461344c318cd43a5494c0302e142a0cbe386d52.
* MdeModulePkg/UsbMass: Fix hot-plug USB CDROM can't be recognized

UsbBootExecCmd() only calls UsbBootRequestSense() to get sense key
when CMD fails.
When POWER ON (29h) ASC returns from REQUEST SENSE, implementation
should retry the CMD, instead of treating this as a SUCCESS.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoBaseTools: Fix byte orders when handling 8-byte array
Yonghong Zhu [Fri, 2 Mar 2018 15:07:06 +0000 (23:07 +0800)]
BaseTools: Fix byte orders when handling 8-byte array

Per UEFI spec, FibreEx.WWN, FibreEx.Lun, SasEx.Address, SasEx.Lun
and iSCSI.Lun are all 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
    UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or  UINT64 = {0807060504030201}

Today's implementation wrongly uses the reversed order.
The patch fixes this issue by using StrHexToBytes().
Copy this solution from MdePkg Hash version d0196be.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Fix bug when converting iSCSI node
Yonghong Zhu [Fri, 2 Mar 2018 15:03:34 +0000 (23:03 +0800)]
BaseTools: Fix bug when converting iSCSI node

If protocol string is not specified, default TCP(0) should be used.
Today's implementation wrongly sets to 1 for this case.
Copy the fix solution from MdePkg Hash version e6c80aea.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg/DevicePathFromText: Fix byte orders of iSCSI.Lun
Ruiyu Ni [Fri, 2 Mar 2018 11:50:30 +0000 (19:50 +0800)]
MdePkg/DevicePathFromText: Fix byte orders of iSCSI.Lun

Per UEFI spec, iSCSI.Lun is a 8-byte array with byte #0 in the left.
It means "0102030405060708" should be converted to:
    UINT8[8] = {01, 02, 03, 04, 05, 06, 07, 08}
or  UINT64 = {0807060504030201}

Today's implementation wrongly uses the reversed order.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jie Lin <jie.lin@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoMdePkg/DevicePathFromText: Fix bug when converting iSCSI node
Ruiyu Ni [Fri, 2 Mar 2018 11:45:15 +0000 (19:45 +0800)]
MdePkg/DevicePathFromText: Fix bug when converting iSCSI node

If protocol string is not specified, default TCP(0) should be used.
Today's implementation wrongly sets to 1 for this case.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoUefiCpuPkg S3ResumePei: Signal S3SmmInitDone
Star Zeng [Fri, 8 Dec 2017 11:22:49 +0000 (19:22 +0800)]
UefiCpuPkg S3ResumePei: Signal S3SmmInitDone

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
3 years agoMdeModulePkg PiSmmCore: Register SMI handler to install S3SmmInitDone
Star Zeng [Fri, 8 Dec 2017 10:06:25 +0000 (18:06 +0800)]
MdeModulePkg PiSmmCore: Register SMI handler to install S3SmmInitDone

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg: Add S3SmmInitDone definition
Star Zeng [Fri, 8 Dec 2017 10:04:54 +0000 (18:04 +0800)]
MdeModulePkg: Add S3SmmInitDone definition

Add gEdkiiS3SmmInitDoneGuid, after S3 SMM initialization is done and
before S3 boot script is executed, this GUID is installed as PPI in
PEI and protocol in SMM environment. It allows for PEIMs or SMM
drivers to hook this point and do the required tasks.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoBaseTools: Fix the bug to search Fv.txt file relative to workspace
Yonghong Zhu [Fri, 2 Mar 2018 17:09:03 +0000 (01:09 +0800)]
BaseTools: Fix the bug to search Fv.txt file relative to workspace

when the SECTION FV_IMAGE = $(XX)/XX.Fv, the Fv file should relative to
WORKSPACE, so when we search the XX.Fv.txt file, we should search the
path relative to workspace first.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Correct Structure Pcd value in the report
Yonghong Zhu [Fri, 2 Mar 2018 14:52:34 +0000 (22:52 +0800)]
BaseTools: Correct Structure Pcd value in the report

The patch "Fixed build failed issue" changed structure Pcd Object, so
we need update build report to correct structure Pcd Value.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Pcd Value override issue.
Feng, Bob C [Fri, 2 Mar 2018 15:51:56 +0000 (23:51 +0800)]
BaseTools: Pcd Value override issue.

For the case that the structure PCD has no value assignment in DSC,
but has value assignment in command line.

Contributed-under: TianoCore Contribution Agreement 1.1
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>
3 years agoBaseTools: Fixed build failed issue.
Feng, Bob C [Fri, 2 Mar 2018 10:11:14 +0000 (18:11 +0800)]
BaseTools: Fixed build failed issue.

Case 1. A Pcd has no default sku setting in DSC.
Case 2. Build as Single SKU.

Contributed-under: TianoCore Contribution Agreement 1.1
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>
3 years agoBaseTools: Fixed Pcd value override issue.
BobCF [Fri, 2 Mar 2018 10:11:13 +0000 (18:11 +0800)]
BaseTools: Fixed Pcd value override issue.

1. Handle the Pcd maxsize issue for the case
that the length of Pcd value from CommandLine
bigger that its maxsize

2. The Pcd value override in commandline.

Contributed-under: TianoCore Contribution Agreement 1.1
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>
3 years agoBaseTools: DSC Components section support flexible PCD
Yunhua Feng [Sat, 3 Mar 2018 01:12:18 +0000 (09:12 +0800)]
BaseTools: DSC Components section support flexible PCD

DSC Components section support flexible PCD, and for binary driver, we
need patch this value. Update the split char ',' not ', ' because some
value may have space, while others may not have this space.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/Mtftp4Dxe: Separate the timer ticking to calculate the packet live time.
Fu Siyuan [Fri, 2 Mar 2018 03:33:28 +0000 (11:33 +0800)]
MdeModulePkg/Mtftp4Dxe: Separate the timer ticking to calculate the packet live time.

TPL deadlock issue was enrolled by the commit of 39b0867d. To resolve the issue,
this patch separated the timer ticking for all the MTFTP clients to calculate the
packet live time in TPL_NOTIFY level.

Cc: Wang Fan <fan.wang@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
3 years agoBaseTools: Dsc/Fdf conditional statement parse issue
Feng, YunhuaX [Thu, 1 Mar 2018 12:42:01 +0000 (20:42 +0800)]
BaseTools: Dsc/Fdf conditional statement parse issue

Set PCD value with --pcd argument not replace DSC/Fdf PCD value.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoMdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file
Felix Polyudov [Fri, 2 Mar 2018 15:48:30 +0000 (23:48 +0800)]
MdePkg/Include/IndustryStandard: Add PCI Express 4.0 header file

v3: LaneEqualizationControl is changed to be an array.

v2: The structure is updated to include all the fields defined
in the PCI-E specification.

The header includes Physical Layer PCI Express Extended Capability definitions
described in section 7.7.5 of PCI Express Base Specification rev. 4.0.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Felix Polyudov <felixp@ami.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoSecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency
Marc-André Lureau [Fri, 23 Feb 2018 13:23:05 +0000 (14:23 +0100)]
SecurityPkg/Tcg2Pei: drop Tcg2PhysicalPresenceLib dependency

Apparently, unnecessary. Avoids extra build dependency and churn.

CC: Laszlo Ersek <lersek@redhat.com>
CC: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg: Fix incorrect commit introduced by commit SHA-1:052c98
Dandan Bi [Thu, 1 Mar 2018 07:08:01 +0000 (15:08 +0800)]
MdeModulePkg: Fix incorrect commit introduced by commit SHA-1:052c98

The default value of PcdExtFpdtBootRecordPadSize is 0x20000
But the following commit in master update it to 0 by mistake.
SHA-1: 052c98ce246a1ffb0b4c5185a644aa9f902650f7
Subject: MdeModulePkg: Add ResetSystemPei PEIM

This patch is to restore the value.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/DxeCorePerfLib: Add status check instead of ASSERT
Dandan Bi [Thu, 1 Mar 2018 05:40:48 +0000 (13:40 +0800)]
MdeModulePkg/DxeCorePerfLib: Add status check instead of ASSERT

Currently DxeCorePerformanceLib will get SMM performance data based
on SMM communication handler. If SMM communication handler returns error,
the library will ASSERT. In fact, if SMM perf data is not found.
DXE perf data can still be dumped. So using status check instead of
ASSERT is better.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/DebugLibReportStatusCode: Fix hang if format is too long
Ruiyu Ni [Thu, 1 Mar 2018 06:33:43 +0000 (14:33 +0800)]
MdeModulePkg/DebugLibReportStatusCode: Fix hang if format is too long

The previous commit 137ed15511e2045a7333e33ae7f1e873ce1961dd
* MdeModulePkg/DebugLib: Print partial when format string is too long
copies partial format string to DEBUG_INFO buffer but when parsing
the format modifier, the original format string is still used.

The patch fixes this issue.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoNetworkPkg/HttpDxe: Support HTTP Delete Method.
Jiaxin Wu [Tue, 27 Feb 2018 03:11:46 +0000 (11:11 +0800)]
NetworkPkg/HttpDxe: Support HTTP Delete Method.

Per the request to support HttpMethodDelete:
https://bugzilla.tianocore.org/show_bug.cgi?id=879,
This patch is to enable the HTTP Delete Method.

Cc: Karunakar P <karunakarp@amiindia.co.in>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
3 years agoNetworkPkg/Udp6Dxe: Fix the failure to leave one multicast group address.
Jiaxin Wu [Thu, 1 Mar 2018 09:24:20 +0000 (17:24 +0800)]
NetworkPkg/Udp6Dxe: Fix the failure to leave one multicast group address.

The issue was enrolled by the commit of ceec3638. One of the change in the commit
was to return the status from NetMapIterate in Udp6Groups function. But it should
not return EFI_ABORTED directly in case McastIp is not NULL, which means to terminate
the iteration and leave the McastIp successfully.

Cc: Wang Fan <fan.wang@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
3 years agoNetworkPkg/HttpBootDxe: Fix the incorrect error message output.
Jiaxin Wu [Thu, 1 Mar 2018 04:59:57 +0000 (12:59 +0800)]
NetworkPkg/HttpBootDxe: Fix the incorrect error message output.

For IPv6 case, if one invalid URL returned from DHCP server, HttpBootDxe
driver could not retrieve the URL host address from DNS server. In such a
case, the error message should be printed as:
  Error: Could not retrieve the host address from DNS server.
Instead of:
  Error: Could not discover the boot information for DHCP server.
Then, we can still output as following:
  Error: Could not retrieve NBP file size from HTTP server.

Besides, currently implementation in HttpBootLoadFile will always output
error message even the HTTP process is correct.

This patch is to fix above issue.

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
3 years agoNetworkPkg/HttpBootDxe: Correct the parameter check for the usage of HttpBootGetFileF...
Jiaxin Wu [Thu, 1 Mar 2018 03:52:28 +0000 (11:52 +0800)]
NetworkPkg/HttpBootDxe: Correct the parameter check for the usage of HttpBootGetFileFromCache.

The patch is to fix the incorrect parameter check for the HttpBootGetFileFromCache().

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
3 years agoBaseTools: report error if flag in LABEL() invalid
Feng, YunhuaX [Thu, 1 Mar 2018 08:22:08 +0000 (16:22 +0800)]
BaseTools: report error if flag in LABEL() invalid

Flag in LABEL() is not valid C variable name, will report error.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools: Fix the bug for display incorrect *M flag in report
Yonghong Zhu [Thu, 1 Mar 2018 05:48:31 +0000 (13:48 +0800)]
BaseTools: Fix the bug for display incorrect *M flag in report

The root cause is the byte array value in the driver Pcd, some bytes
have additional space character, while the value in DSC file doesn't
have this space, it cause the string compare return false, so we remove
the extra space.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Fix eval parse string issue
Feng, YunhuaX [Thu, 1 Mar 2018 02:16:07 +0000 (10:16 +0800)]
BaseTools: Fix eval parse string issue

eval argument start with " or ', but it is unicode string,
will encounter error:
    List = list(eval(Value)) # translate escape character
  File "<string>", line 1
    'j??=????????F??
             ^
SyntaxError: EOL while scanning string literal

Cc: Liming Gao <liming.gao@intel.com>
Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng <yunhuax.feng@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>