mirror_edk2.git
3 years agoIntelFsp2Pkg: Add Readme.md
Jiewen Yao [Thu, 9 Mar 2017 02:31:57 +0000 (10:31 +0800)]
IntelFsp2Pkg: Add Readme.md

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoQuarkPlatformPkg: Add UefiBootManagerLib to fix Shell build failure
Ruiyu Ni [Fri, 10 Mar 2017 09:36:39 +0000 (17:36 +0800)]
QuarkPlatformPkg: Add UefiBootManagerLib to fix Shell build failure

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdePkg/Pci22.h: Remove deprecated macros
Ruiyu Ni [Mon, 6 Mar 2017 06:38:59 +0000 (14:38 +0800)]
MdePkg/Pci22.h: Remove deprecated macros

The following deprecated macros are removed.The removal
doesn't cause any build failure to existing packages.

#define DEVICE_ID_NOCARE    0xFFFF
#define PCI_BAR_OLD_ALIGN   0xFFFFFFFFFFFFFFFFULL
#define PCI_BAR_EVEN_ALIGN  0xFFFFFFFFFFFFFFFEULL
#define PCI_BAR_SQUAD_ALIGN 0xFFFFFFFFFFFFFFFDULL
#define PCI_BAR_DQUAD_ALIGN 0xFFFFFFFFFFFFFFFCULL
#define PCI_BAR_ALL         0xFF
#define PCI_ACPI_UNUSED     0
#define PCI_BAR_NOCHANGE    0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoSignedCapsulePkg: Add Readme.md
Jiewen Yao [Thu, 9 Mar 2017 02:30:14 +0000 (10:30 +0800)]
SignedCapsulePkg: Add Readme.md

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoAdd SignedCapsule content.
Jiewen Yao [Thu, 9 Mar 2017 02:13:43 +0000 (10:13 +0800)]
Add SignedCapsule content.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent
Ard Biesheuvel [Thu, 9 Mar 2017 15:59:34 +0000 (16:59 +0100)]
ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent

Instead of having a build time switch to prevent the FDT configuration
table from being installed, make this behavior dependent on whether we
are passing ACPI tables to the OS. This is done by looking for the
ACPI 2.0 configuration table, and only installing the FDT one if the
ACPI one cannot be found.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot
Ard Biesheuvel [Thu, 9 Mar 2017 15:45:07 +0000 (16:45 +0100)]
ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot

Defer FDT configuration table installation until ReadyToBoot is signaled.
This allows any driver to make modifications in the mean time, and will
also allow us to defer the decision of whether to install it in the first
place to later on in the boot.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg/ArmVirtPL031FdtClientLib: unconditionally disable DT node
Ard Biesheuvel [Thu, 9 Mar 2017 15:38:53 +0000 (16:38 +0100)]
ArmVirtPkg/ArmVirtPL031FdtClientLib: unconditionally disable DT node

Disable the PL031 RTC DT node unconditionally rather than only when
the DT will be exposed to the OS. This allows us to defer the decision
whether to expose it to the OS to a later time without creating an
additional dependency on the FDT client code by the RTC driver.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg/FdtClientDxe: supplement missing EFIAPI calling conv specifiers
Laszlo Ersek [Wed, 8 Mar 2017 19:05:06 +0000 (20:05 +0100)]
ArmVirtPkg/FdtClientDxe: supplement missing EFIAPI calling conv specifiers

Add missing EFIAPI calling convention specifiers to STATIC function
that are exposed via the FdtClientProtocol interface.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoMdeModulePkg/AcpiTableDxe: improve FADT.{DSDT,X_DSDT} mutual exclusion
Laszlo Ersek [Wed, 1 Feb 2017 14:33:57 +0000 (15:33 +0100)]
MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT,X_DSDT} mutual exclusion

The ACPI specification, up to and including revision 5.1 Errata A, allows
the DSDT and X_DSDT fields to be both set in the FADT. (Obviously, this
only makes sense if the DSDT address is representable in 4 bytes.)

Starting with 5.1 Errata B, specifically for Mantis 1393
<https://mantis.uefi.org/mantis/view.php?id=1393>, the spec requires at
most one of DSDT and X_DSDT to be set to a nonzero value.

MdeModulePkg/AcpiTableDxe handles this mutual exclusion somewhat
inconsistently.

- If the caller of EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() installs the
  tables in "DSDT, FADT" order, then we enforce the exclusion between the
  DSDT and X_DSDT fields:

  DSDT under 4GB  FADT.DSDT  FADT.X_DSDT    [VARIANT B]
  --------------  ---------  -----------
  yes             set        clear
  no              clear      set

  This behavior conforms to 5.1 Errata B. (And it's not required by
  earlier versions of the spec.)

- If the caller passes in the tables in "FADT, DSDT" relative order, then
  we do not enforce the exclusion:

  DSDT under 4GB  FADT.DSDT  FADT.X_DSDT    [VARIANT A]
  --------------  ---------  -----------
  yes             set        set
  no              clear      set

  This satisfies 5.1 Errata A and earlier, but breaks 5.1 Errata B and
  later.

Unify the handling of both relative orders. In particular, check the major
and minor version numbers in the FADT. If the FADT version is strictly
before 5.1, then implement [VARIANT A]. If the FADT version is equal to or
larger than 5.1, then implement [VARIANT B].

We make three observations:

- We can't check the FADT table version precisely against "5.1 Errata B";
  erratum levels are not captured in the table. We err in the safe
  direction, namely we enforce the exclusion for "5.1" and "5.1 Errata A".

- The same applies to "6.0" versus "6.0 Errata A". Because we cannot
  distinguish these two, we consider "6.0" to be "equal to or larger than
  5.1", and apply [VARIANT B], enforcing the exclusion.

- While a blanket [VARIANT B] would be simpler, there is a significant
  benefit to [VARIANT A], under the spec versions that permit it:
  compatibility with a wider range of OSPMs (typically, older ones).

  For example, Igor reported about a "DELL R430 system with rev4 FADT
  where DSDT and X_DSDT are pointing to the same address". Michael also
  reported about several systems that exhibit the same.

Regression tested with the following KVM guests (QEMU built at
ata0def594286d, "Merge remote-tracking branch
'remotes/bonzini/tags/for-upstream' into staging", 2017-01-30):

- OVMF: boot and S3 suspend/resume
  - Ia32, Q35, SMM
    - Fedlet 20141209
  - Ia32X64, Q35, SMM
    - Fedora 22
    - Windows 7
    - Windows 8.1
    - Windows 10
    - Windows Server 2008 R2
    - Windows Server 2012 R2
    - Windows Server 2016 Tech Preview 4
  - X64, I440FX, no SMM
    - Fedora 24
    - RHEL-6.7
    - RHEL-7.2-ish
- ArmVirtQemu: boot test with virtio-gpu
  - AARCH64
    - Fedora 24
    - RHELSA-7.3
    - openSUSE Tumbleweed (4.8.4-based)

This change is connected to ASWG ticket
<https://mantis.uefi.org/mantis/view.php?id=1757>, which is now
closed/fixed.

Cc: Al Stone <ahs3@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Michael Tsirkin <mtsirkin@redhat.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/AcpiTableDxe: condense whitespace around FADT.{DSDT,X_DSDT}
Laszlo Ersek [Wed, 1 Feb 2017 14:10:02 +0000 (15:10 +0100)]
MdeModulePkg/AcpiTableDxe: condense whitespace around FADT.{DSDT,X_DSDT}

This patch incurs no functional changes, it just removes some whitespace,
and also makes sure we always assign

  AcpiTableInstance->Fadt3->Dsdt

first, and

  AcpiTableInstance->Fadt3->XDsdt

second. The goal is to separate the syntactic changes from the functional
changes implemented by the next patch.

Cc: Al Stone <ahs3@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Michael Tsirkin <mtsirkin@redhat.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoBaseTools/UPT: Fix an issue of adding Event twice
Hess Chen [Tue, 7 Mar 2017 08:01:25 +0000 (16:01 +0800)]
BaseTools/UPT: Fix an issue of adding Event twice

Fix the issue of after installing a package the Event information is duplicated. The tool checks if the EVENT information existing in UserExtension or not. If already existing in UserExtension the tool will not add additional information.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools/UPT: Man Page Update
Hess Chen [Tue, 7 Mar 2017 06:15:13 +0000 (14:15 +0800)]
BaseTools/UPT: Man Page Update

Update UPT man page to complete the description of options.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools/UPT: Add a checkpoint for missing '"'
Hess Chen [Tue, 7 Mar 2017 06:01:34 +0000 (14:01 +0800)]
BaseTools/UPT: Add a checkpoint for missing '"'

Add a checkpoint for UNI file which is missing '"' at the end of a line.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools/ECC: Fix an issue of parameter parser
Hess Chen [Tue, 7 Mar 2017 06:01:33 +0000 (14:01 +0800)]
BaseTools/ECC: Fix an issue of parameter parser

The original solution of getting parameter name is to skip "_" but
now it doesn't ignore "_" anymore.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen <hesheng.chen@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoArmPkg/CpuDxe: handle implied attributes in EfiAttributeToArmAttribute
Ard Biesheuvel [Wed, 8 Mar 2017 11:46:38 +0000 (12:46 +0100)]
ArmPkg/CpuDxe: handle implied attributes in EfiAttributeToArmAttribute

Some memory attributes are implied by the memory type, e.g., device memory
is always mapped non-executable and cached memory should have the inner
shareable attribute.

In order to prevent unnecessary memory attribute updates of mappings
created early on, make EfiAttributeToArmAttribute() return these implied
attributes in the same way as ArmMmuLib does already. This avoids false
positives when looking for differences between current and desired mapping
attributes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmVirtPkg: apply PE/COFF memory protection to DxeCore as well
Ard Biesheuvel [Tue, 7 Mar 2017 11:24:57 +0000 (12:24 +0100)]
ArmVirtPkg: apply PE/COFF memory protection to DxeCore as well

Include DXE_CORE in the BuildOptions that are set to force 4 KB section
alignment for PE/COFF images in order to allow them to be mapped with
strict memory permissions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmPkg/UncachedMemoryAllocationLib: map uncached allocations non-executable
Ard Biesheuvel [Tue, 28 Feb 2017 12:13:12 +0000 (12:13 +0000)]
ArmPkg/UncachedMemoryAllocationLib: map uncached allocations non-executable

The primary use case for UncachedMemoryAllocationLib is non-coherent DMA,
which implies that such regions are not used to fetch instructions from.

So let's map them as non-executable, to avoid creating a security hole
when the rest of the platform may be enforcing strict memory permissions
on ordinary allocations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/UncachedMemoryAllocationLib: use CWG value to align pool allocations
Ard Biesheuvel [Tue, 28 Feb 2017 12:13:11 +0000 (12:13 +0000)]
ArmPkg/UncachedMemoryAllocationLib: use CWG value to align pool allocations

Uncached pool allocations are aligned to the data cache line length under
the assumption that this is sufficient to prevent cache maintenance from
corrupting adjacent allocations. However, the value to use in such cases
is architecturally called the Cache Writeback Granule (CWG), which is
essentially the maximum Dcache line length rather than the minimum.

Note that this is mostly a cosmetical fix, given that the pool allocation
is turned into a page allocation later, and rounded up accordingly.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/UncachedMemoryAllocationLib: restore mapping attributes after free
Ard Biesheuvel [Tue, 28 Feb 2017 12:13:10 +0000 (12:13 +0000)]
ArmPkg/UncachedMemoryAllocationLib: restore mapping attributes after free

In order to play nice with platforms that use strict memory permission
policies, restore the original mapping attributes when freeing uncached
allocations.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoEmulatorPkg: Add the UefiBootManagerLib library
Dandan Bi [Tue, 7 Mar 2017 02:13:58 +0000 (10:13 +0800)]
EmulatorPkg: Add the UefiBootManagerLib library

Since shell has consumed the APIs in UefiBootManagerLib.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Refine casting result to bigger size
Hao Wu [Tue, 7 Mar 2017 01:00:48 +0000 (09:00 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Refine casting result to bigger size

The commit is a follow-up of commit 8491e30.

In file MpService.c line 786:
Pte[Index] = (UINT64)((UINTN)PageTable + EFI_PAGE_SIZE * (Index + 1)) |
mAddressEncMask ...

(Where PageTable is of type VOID*, Index is of type UINTN, mAddressEncMask
is of type UINT64 and Pte[Index] is of type UINT64.)

Since in this case, the code logic ensures that the expression will not
exceed the range of UINTN, the commit will remove the explicit type cast
'(UINT64)'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoMdeModulePkg/DxeCore: Fix coding style issues
Bi, Dandan [Fri, 3 Mar 2017 04:44:46 +0000 (12:44 +0800)]
MdeModulePkg/DxeCore: Fix coding style issues

Add comments for functions.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg: Add PROMPT&HELP string of pcd to UNI file
Bi, Dandan [Fri, 3 Mar 2017 04:44:45 +0000 (12:44 +0800)]
MdeModulePkg: Add PROMPT&HELP string of pcd to UNI file

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoArmVirtPkg: enable non-executable DXE stack for all platforms
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:43 +0000 (16:31 +0000)]
ArmVirtPkg: enable non-executable DXE stack for all platforms

Now that ARM has grown support for managing memory permissions in
ArmMmuLib, we can enable the non-executable DXE stack for all virt
platforms. Note that this includes the AARCH64 Xen platform as well.

Note that this is not [entirely] redundant: the non-executable stack
is configured before DxeCore is invoked. The image and memory protection
features configured during DXE only take affect when the CPU arch
protocol implementation is registered.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmPkg/ArmMmuLib ARM: implement memory permission control routines
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:42 +0000 (16:31 +0000)]
ArmPkg/ArmMmuLib ARM: implement memory permission control routines

Now that we have the prerequisite functionality available in ArmMmuLib,
wire it up into ArmSetMemoryRegionNoExec, ArmClearMemoryRegionNoExec,
ArmSetMemoryRegionReadOnly and ArmClearMemoryRegionReadOnly. This is
used by the non-executable stack feature that is configured by DxeIpl.

NOTE: The current implementation will not combine RO and XP attributes,
      i.e., setting/clearing a region no-exec will unconditionally
      clear the read-only attribute, and vice versa. Currently, we
      only use ArmSetMemoryRegionNoExec(), so for now, we should be
      able to live with this.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/ArmMmuLib: remove VirtualMask arg from ArmSetMemoryAttributes
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:41 +0000 (16:31 +0000)]
ArmPkg/ArmMmuLib: remove VirtualMask arg from ArmSetMemoryAttributes

We no longer make use of the ArmMmuLib 'feature' to create aliased
memory ranges with mismatched attributes, and in fact, it was only
wired up in the ARM version to begin with.

So remove the VirtualMask argument from ArmSetMemoryAttributes()'s
prototype, and remove the dead code that referred to it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg: move ARM version of SetMemoryAttributes to ArmMmuLib
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:40 +0000 (16:31 +0000)]
ArmPkg: move ARM version of SetMemoryAttributes to ArmMmuLib

... where it belongs, since AARCH64 already keeps it there, and
non DXE users of ArmMmuLib (such as DxeIpl, for the non-executable
stack) may need its functionality as well.

While at it, rename SetMemoryAttributes to ArmSetMemoryAttributes,
and make any functions that are not exported STATIC. Also, replace
an explicit gBS->AllocatePages() call [which is DXE specific] with
MemoryAllocationLib::AllocatePages().

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/ArmMmuLib: use correct return type for exported functions
Ard Biesheuvel [Wed, 1 Mar 2017 16:31:39 +0000 (16:31 +0000)]
ArmPkg/ArmMmuLib: use correct return type for exported functions

The routines ArmConfigureMmu(), SetMemoryAttributes() [*] and the
various set/clear read-only/no-exec routines are declared as returning
EFI_STATUS in the respective header files, so align the definitions with
that.

* SetMemoryAttributes() is declared in the wrong header (and defined in
  ArmMmuLib for AARCH64 and in CpuDxe for ARM)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmVirtPkg: enable PE/COFF image and memory protection for ARM platforms
Ard Biesheuvel [Thu, 2 Mar 2017 10:36:16 +0000 (10:36 +0000)]
ArmVirtPkg: enable PE/COFF image and memory protection for ARM platforms

Like for AARCH64, enable PE/COFF image and NX memory protection for all
32-bit ARM virt platforms.

Note that this does not [yet] protect EfiLoaderData regions, due to
compatibility issues with GRUB.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmPkg/CpuDxe ARM: honour RO/XP attributes in SetMemoryAttributes()
Ard Biesheuvel [Thu, 2 Mar 2017 10:36:15 +0000 (10:36 +0000)]
ArmPkg/CpuDxe ARM: honour RO/XP attributes in SetMemoryAttributes()

Enable the use of strict memory permissions on ARM by processing the
EFI_MEMORY_RO and EFI_MEMORY_XP rather than ignoring them. As before,
calls to CpuArchProtocol::SetMemoryAttributes that only set RO/XP
bits will preserve the cacheability attributes. Permissions attributes
are not preserved when setting the memory type only: the way the memory
permission attributes are defined does not allows for that, and so this
situation does not deviate from other architectures.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/CpuDxe ARM: avoid unnecessary cache/TLB maintenance
Ard Biesheuvel [Thu, 2 Mar 2017 10:36:14 +0000 (10:36 +0000)]
ArmPkg/CpuDxe ARM: avoid unnecessary cache/TLB maintenance

Page and section entries in the page tables are updated using the
helper ArmUpdateTranslationTableEntry(), which cleans the page
table entry to the PoC, and invalidates the TLB entry covering
the page described by the entry being updated.

Since we may be updating section entries, we might be leaving stale
TLB entries at this point (for all pages in the section except the
first one), which will be invalidated wholesale at the end of
SetMemoryAttributes(). At that point, all caches are cleaned *and*
invalidated as well.

This cache maintenance is costly and unnecessary. The TLB maintenance
is only necessary if we updated any section entries, since any page
by page entries that have been updated will have been invalidated
individually by ArmUpdateTranslationTableEntry().

So drop the clean/invalidate of the caches, and only perform the
full TLB flush if UpdateSectionEntries() was called, or if sections
were split by UpdatePageEntries(). Finally, make the cache maintenance
on the remapped regions themselves conditional on whether any memory
type attributes were modified.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoArmPkg/CpuDxe ARM: avoid splitting page table sections unnecessarily
Ard Biesheuvel [Thu, 2 Mar 2017 10:36:13 +0000 (10:36 +0000)]
ArmPkg/CpuDxe ARM: avoid splitting page table sections unnecessarily

Currently, any range passed to CpuArchProtocol::SetMemoryAttributes is
fully broken down into page mappings if the start or the size of the
region happens to be misaliged relative to the section size of 1 MB.

This is going to result in memory being wasted on second level page tables
when we enable strict memory permissions, given that we remap the entire
RAM space non-executable (modulo the code bits) when the CpuArchProtocol
is installed.

So refactor the code to iterate over the range in a way that ensures
that all naturally aligned section sized subregions are not broken up.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoMdePkg/SafeString.c: Fix code to be more readable
Ruiyu Ni [Mon, 6 Mar 2017 06:34:29 +0000 (14:34 +0800)]
MdePkg/SafeString.c: Fix code to be more readable

The change doesn't impact the functionality.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
3 years agoBaseTools/VolInfo: Fix VS2010/VS2012 build failure
Hao Wu [Mon, 6 Mar 2017 02:41:53 +0000 (10:41 +0800)]
BaseTools/VolInfo: Fix VS2010/VS2012 build failure

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

The commit makes the following refinements in VolInfo source codes to
avoid VS2010/VS2012 build failure:

1. Refines coding style for function 'CombinePath' to declare local
variables at the beginning of the function block.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools/GenVtf: Fix VS2010/VS2012 build failure
Hao Wu [Mon, 6 Mar 2017 02:39:34 +0000 (10:39 +0800)]
BaseTools/GenVtf: Fix VS2010/VS2012 build failure

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

The commit makes the following refinements in GenVtf source codes to
avoid VS2010/VS2012 build failure:

1. Refines coding style to declare local variables at the beginning of a
code block in function 'main'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoBaseTools/GenFw: Fix VS2010/VS2012 build failure
Hao Wu [Mon, 6 Mar 2017 01:56:02 +0000 (09:56 +0800)]
BaseTools/GenFw: Fix VS2010/VS2012 build failure

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

The commit makes the following refinements in GenFw source codes to
avoid VS2010/VS2012 build failure:

1. Replaces the uses of 'bool' with 'BOOLEAN' for accordance, and remove
the header file dependency for '<stdbool.h>'.

2. Refines coding style for function 'GetSymName' to declare local
variables at the beginning of the function block.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoMdeModulePkg/PeiCore: honour minimal runtime allocation granularity
Ard Biesheuvel [Fri, 3 Mar 2017 15:11:34 +0000 (15:11 +0000)]
MdeModulePkg/PeiCore: honour minimal runtime allocation granularity

Architectures such as AArch64 may run the OS with 16 KB or 64 KB sized
pages, and for this reason, the UEFI spec mandates a minimal allocation
granularity of 64 KB for regions that may require different memory
attributes at OS runtime.

So make PeiCore's implementation of AllocatePages () take this into
account as well.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/PiSmmCore: switch to MdePkg allocation granularity macros
Ard Biesheuvel [Fri, 3 Mar 2017 15:11:33 +0000 (15:11 +0000)]
MdeModulePkg/PiSmmCore: switch to MdePkg allocation granularity macros

Remove the local definitions for the default and runtime page allocation
granularity macros, and switch to the new MdePkg versions.

Note that this replaces a reference to the 'default' version with the
more correct 'runtime' version, but this matters little in practice.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/DxeCore: switch to MdePkg allocation granularity macros
Ard Biesheuvel [Fri, 3 Mar 2017 15:11:32 +0000 (15:11 +0000)]
MdeModulePkg/DxeCore: switch to MdePkg allocation granularity macros

Remove the local definitions for the default and runtime page allocation
granularity macros, and switch to the new MdePkg versions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg/ProcessorBind: add defines for page allocation granularity
Ard Biesheuvel [Fri, 3 Mar 2017 15:11:31 +0000 (15:11 +0000)]
MdePkg/ProcessorBind: add defines for page allocation granularity

The UEFI spec differs between architectures in the minimum alignment
and granularity of page allocations that are visible to the OS as
EFI_MEMORY_RUNTIME regions.

So define macros that carry these values to the respective ProcessorBind.h
header files.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoUefiCpuPkg/CpuDxe: Add support for PCD PcdPteMemoryEncryptionAddressOrMask
Leo Duran [Thu, 2 Mar 2017 23:36:03 +0000 (07:36 +0800)]
UefiCpuPkg/CpuDxe: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

The mask is applied when page tables entries are created or modified.

CC: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoShellPkg/comp: Use proper parameter names
Ruiyu Ni [Mon, 6 Mar 2017 07:15:22 +0000 (15:15 +0800)]
ShellPkg/comp: Use proper parameter names

The patch doesn't impact the functionality.
The rename also fixes the inconsistency between function
header comments and function parameters.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoUefiCpuPkg: Refine casting expression result to bigger size
Hao Wu [Fri, 17 Feb 2017 03:54:10 +0000 (11:54 +0800)]
UefiCpuPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoSourceLevelDebugPkg: Refine casting expression result to bigger size
Hao Wu [Fri, 17 Feb 2017 03:44:04 +0000 (11:44 +0800)]
SourceLevelDebugPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoShellPkg: Refine casting expression result to bigger size
Hao Wu [Fri, 17 Feb 2017 03:00:45 +0000 (11:00 +0800)]
ShellPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoSecurityPkg/Opal: Refine casting expression result to bigger size
Hao Wu [Fri, 17 Feb 2017 02:08:13 +0000 (10:08 +0800)]
SecurityPkg/Opal: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
3 years agoPcAtChipsetPkg: Refine casting expression result to bigger size
Hao Wu [Fri, 17 Feb 2017 01:46:27 +0000 (09:46 +0800)]
PcAtChipsetPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoNetworkPkg: Refine casting expression result to bigger size
Hao Wu [Thu, 16 Feb 2017 06:58:03 +0000 (14:58 +0800)]
NetworkPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
3 years agoIntelFspWrapperPkg: Refine casting expression result to bigger size
Hao Wu [Wed, 15 Feb 2017 08:04:26 +0000 (16:04 +0800)]
IntelFspWrapperPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoIntelFsp2WrapperPkg: Refine casting expression result to bigger size
Hao Wu [Wed, 15 Feb 2017 05:51:01 +0000 (13:51 +0800)]
IntelFsp2WrapperPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoIntelFrameworkModulePkg: Refine casting expression result to bigger size
Hao Wu [Mon, 23 Jan 2017 03:24:50 +0000 (11:24 +0800)]
IntelFrameworkModulePkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoFatPkg: Refine casting expression result to bigger size
Hao Wu [Sun, 22 Jan 2017 02:17:52 +0000 (10:17 +0800)]
FatPkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg: Refine casting expression result to bigger size
Hao Wu [Fri, 24 Feb 2017 02:01:34 +0000 (10:01 +0800)]
MdeModulePkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
3 years agoMdePkg: Refine casting expression result to bigger size
Hao Wu [Wed, 18 Jan 2017 08:22:15 +0000 (16:22 +0800)]
MdePkg: Refine casting expression result to bigger size

There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.

An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);

Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.

The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;

2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;

3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);

4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}

For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoShellPkg: Refine type cast for pointer subtraction
Hao Wu [Mon, 23 Jan 2017 06:38:43 +0000 (14:38 +0800)]
ShellPkg: Refine type cast for pointer subtraction

For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."

In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.

Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:

UINT8  *Ptr1, *Ptr2;
UINTN  PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);

The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:

PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoSecurityPkg: Refine type cast for pointer subtraction
Hao Wu [Mon, 23 Jan 2017 01:59:25 +0000 (09:59 +0800)]
SecurityPkg: Refine type cast for pointer subtraction

For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."

In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.

Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:

UINT8  *Ptr1, *Ptr2;
UINTN  PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);

The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:

PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoNetworkPkg: Refine type cast for pointer subtraction
Hao Wu [Mon, 23 Jan 2017 05:55:42 +0000 (13:55 +0800)]
NetworkPkg: Refine type cast for pointer subtraction

For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."

In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.

Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:

UINT8  *Ptr1, *Ptr2;
UINTN  PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);

The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:

PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
3 years agoIntelFrameworkModulePkg: Refine type cast for pointer subtraction
Hao Wu [Mon, 23 Jan 2017 01:53:45 +0000 (09:53 +0800)]
IntelFrameworkModulePkg: Refine type cast for pointer subtraction

For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."

In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.

Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:

UINT8  *Ptr1, *Ptr2;
UINTN  PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);

The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:

PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoCryptoPkg: Refine type cast for pointer subtraction
Hao Wu [Sun, 22 Jan 2017 02:12:06 +0000 (10:12 +0800)]
CryptoPkg: Refine type cast for pointer subtraction

For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."

In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.

Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:

UINT8  *Ptr1, *Ptr2;
UINTN  PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);

The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:

PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Qin Long <qin.long@intel.com>
3 years agoMdeModulePkg: Refine type cast for pointer subtraction
Hao Wu [Mon, 23 Jan 2017 03:56:05 +0000 (11:56 +0800)]
MdeModulePkg: Refine type cast for pointer subtraction

For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):

"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."

In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.

Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:

UINT8  *Ptr1, *Ptr2;
UINTN  PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);

The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:

PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
3 years agoMdeModulePkg: Variable: Update DBT PCR[7] measure
Zhang, Chao B [Fri, 3 Mar 2017 05:59:57 +0000 (13:59 +0800)]
MdeModulePkg: Variable: Update DBT PCR[7] measure

Measure DBT into PCR[7] when it is updated between initial measure
if present and not empty. by following TCG PC Client PFP 00.49
Previous patch for PCR[7] DBT part is overrode.
dc9bd6ed281fcba5358f3004632bdbda968be1e5

Cc: Star Zeng <star.zeng@intel.com>
Cc: Yao Jiewen <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
3 years agoSecurityPkg: Tcg2Dxe: Measure DBT into PCR[7]
Zhang, Chao B [Fri, 3 Mar 2017 05:56:10 +0000 (13:56 +0800)]
SecurityPkg: Tcg2Dxe: Measure DBT into PCR[7]

Measure DBT into PCR[7] in initial measurement phase if present and
not empty by following TCG PC Client PFP 00.49.
The previous patch according to 00.21 is removed
1404e3a1508473643efba89af34bd133ab082dd5

Cc: Star Zeng <star.zeng@intel.com>
Cc: Yao Jiewen <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
3 years agoSecurityPkg: Tcg2Dxe: Measure BootOrder, Boot#### to PCR[1]
Zhang, Chao B [Fri, 3 Mar 2017 03:15:01 +0000 (11:15 +0800)]
SecurityPkg: Tcg2Dxe: Measure BootOrder, Boot#### to PCR[1]

Measure BootOrder, Boot#### to PCR[1] according to TCG PC-Client PFP Spec
00.21 Section 2.4.4.2
http://www.trustedcomputinggroup.org/wp-content/uploads/PC-ClientSpecific_Platform_Profile_for_TPM_2p0_Systems_v21.pdf

Cc: Star Zeng <star.zeng@intel.com>
Cc: Yao Jiewen <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Yao Jiewen <jiewen.yao@intel.com>
3 years agoNetworkPkg/Dhcp6Dxe: Handle the Nil UUID case
Jiaxin Wu [Fri, 24 Feb 2017 03:16:37 +0000 (11:16 +0800)]
NetworkPkg/Dhcp6Dxe: Handle the Nil UUID case

Nil UUID is a special case with all zeros value. This
patch is to handle this case to avoid the invalid DUID.

Cc: Naveen Santhapur <naveens@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: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
3 years agoArmPlatformPkg/PlatformIntelBdsLib: don't clobber ConSplitter handle
Ard Biesheuvel [Wed, 1 Mar 2017 18:34:33 +0000 (18:34 +0000)]
ArmPlatformPkg/PlatformIntelBdsLib: don't clobber ConSplitter handle

The InitializeConsolePipe() routine takes care to only set its output
argument *Interface if it is not already set, to prevent overwriting
the ConSplitter interface pointer that may have already been assigned.

However, the associated OUT argument 'Handle' is clobbered by the
subsequent unnecessary LocateDevicePath() invocation, which should
similarly be made dependent on whether *Interface has been set
already.

Reported-by: "Lee, Terry Ping-Chung" <terry.lee@hpe.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoNetworkPkg/TlsAuthConfigDxe: Use StrToGuid in BaseLib
Jiaxin Wu [Tue, 28 Feb 2017 07:00:37 +0000 (15:00 +0800)]
NetworkPkg/TlsAuthConfigDxe: Use StrToGuid in BaseLib

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: Ye Ting <ting.ye@intel.com>
3 years agoBaseTools/Source/C/Makefiles: Fix NmakeSubdirs.bat always return 0
Hao Wu [Wed, 1 Mar 2017 13:07:34 +0000 (21:07 +0800)]
BaseTools/Source/C/Makefiles: Fix NmakeSubdirs.bat always return 0

In batch script file NmakeSubdirs.bat, the value changes made to the
variable 'TOOL_ERROR' within the 'setlocal...endlocal' block will not be
reflected in the return value of the script. A value of 0 will always be
returned. Thus, the script will not reflect the result of the 'nmake'
command correctly when building BaseTool source codes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoMdePkg/BasePrintLib: Add deprecated flag for APIs [A|U]ValueToString
Hao Wu [Mon, 13 Feb 2017 03:25:20 +0000 (11:25 +0800)]
MdePkg/BasePrintLib: Add deprecated flag for APIs [A|U]ValueToString

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/PrintLib: Add deprecated flag for APIs [A|U]ValueToString
Hao Wu [Mon, 13 Feb 2017 03:27:22 +0000 (11:27 +0800)]
MdeModulePkg/PrintLib: Add deprecated flag for APIs [A|U]ValueToString

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/PrintDxe: Handle the deprecation of [A|U]ValueToString
Hao Wu [Mon, 13 Feb 2017 03:03:30 +0000 (11:03 +0800)]
MdeModulePkg/PrintDxe: Handle the deprecation of [A|U]ValueToString

To handle the deprecation of PrintLib APIs UnicodeValueToString and
AsciiValueToString by subsequent commits, the commit refines the logic for
the implemetation of the UnicodeValueToString and AsciiValueToString
services in EFI_PRINT2_PROTOCOL.

When the macro DISABLE_NEW_DEPRECATED_INTERFACES is defined (indicating
the deprecation of the PrintLib APIs), the above two services will ASSERT
and will return zero to reflect not being supported.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoSignedCapsulePkg: Replace [Ascii|Unicode]ValueToString
Hao Wu [Wed, 18 Jan 2017 05:04:14 +0000 (13:04 +0800)]
SignedCapsulePkg: Replace [Ascii|Unicode]ValueToString

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoNt32Pkg: Replace [Ascii|Unicode]ValueToString
Hao Wu [Wed, 18 Jan 2017 03:12:55 +0000 (11:12 +0800)]
Nt32Pkg: Replace [Ascii|Unicode]ValueToString

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg: Replace [Ascii|Unicode]ValueToString
Hao Wu [Wed, 18 Jan 2017 02:31:02 +0000 (10:31 +0800)]
MdeModulePkg: Replace [Ascii|Unicode]ValueToString

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelFrameworkModulePkg: Replace [Ascii|Unicode]ValueToString
Hao Wu [Tue, 17 Jan 2017 01:00:26 +0000 (09:00 +0800)]
IntelFrameworkModulePkg: Replace [Ascii|Unicode]ValueToString

It is the follow up of commits 51f0ceb..9e32e97 to replace
AsciiValueToString/UnicodeValueToString with
AsciiValueToStringS/UnicodeValueToStringS.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoShellPkg: Link DxeSmmPerformanceLib to make DP command generic
Star Zeng [Wed, 1 Mar 2017 07:46:09 +0000 (15:46 +0800)]
ShellPkg: Link DxeSmmPerformanceLib to make DP command generic

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

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoPerformancePkg: Link DxeSmmPerformanceLib to make DP command generic
Star Zeng [Wed, 1 Mar 2017 07:44:52 +0000 (15:44 +0800)]
PerformancePkg: Link DxeSmmPerformanceLib to make DP command generic

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

Also remove the unreferenced TimerLib mapping.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoArmVirtPkg AARCH64: enable NX memory protection for all platforms
Ard Biesheuvel [Mon, 27 Feb 2017 14:10:59 +0000 (14:10 +0000)]
ArmVirtPkg AARCH64: enable NX memory protection for all platforms

This sets the recently introduced PCD PcdDxeNxMemoryProtectionPolicy to
a value that protects all memory regions except code regions against
inadvertent execution.

Note that this does not [yet] protect EfiLoaderData regions, due to
compatibility issues with shim and GRUB.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg: move UefiBootManagerLib resolution to ArmVirt.dsc.inc
Ard Biesheuvel [Wed, 1 Mar 2017 08:05:25 +0000 (08:05 +0000)]
ArmVirtPkg: move UefiBootManagerLib resolution to ArmVirt.dsc.inc

Recent changes to ShellPkg require a resolution for UefiBootManagerLib
for all platforms in ArmVirtPkg. So move the resolution to the shared
include ArmVirt.dsc.inc.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoArmVirtPkg/HighMemDxe: preserve non-exec permissions on newly added regions
Ard Biesheuvel [Tue, 28 Feb 2017 13:45:47 +0000 (13:45 +0000)]
ArmVirtPkg/HighMemDxe: preserve non-exec permissions on newly added regions

Using DxeServices::SetMemorySpaceAttributes to set cacheability
attributes has the side effect of stripping permission attributes,
given that those are bits in the same bitfield, and so setting the
Attributes argument to EFI_MEMORY_WB implies not setting EFI_MEMORY_XP
or EFI_MEMORY_RO attributes.

In fact, the situation is even worse, given that the descriptor returned
by DxeServices::GetMemorySpaceDescriptor does not reflect the permission
attributes that may have been set by the preceding call to
DxeServices::AddMemorySpace if PcdDxeNxMemoryProtectionPolicy has been
configured to map EfiConventionalMemory with non-executable permissions.

Note that this applies equally to the non-executable stack and to PE/COFF
sections that may have been mapped with R-X or RW- permissions. This is
due to the ambiguity in the meaning of the EFI_MEMORY_RO/EFI_MEMORY_XP
attributes when used in the GCD memory map, i.e., between signifying
that an underlying RAM region has the controls to be configured as
read-only or non-executable, and signifying that the contents of a
certain UEFI memory region allow them to be mapped with certain
restricted permissions.

So let's check the policy in PcdDxeNxMemoryProtectionPolicy directly,
and set the EFI_MEMORY_XP attribute if appropriate for
EfiConventionalMemory regions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
3 years agoSecurityPkg: Fix potential bug in Security Boot dxe.
Zhang Lubo [Wed, 22 Feb 2017 09:01:12 +0000 (17:01 +0800)]
SecurityPkg: Fix potential bug in Security Boot dxe.

v2: update hash value in SecureBootConfig.vfr to keep
them consistent with macro definition in SecureBootConfigImpl.h

since we removed the sha-1 definition in Hash table
and related macro, but the macro definition HashAlg index
may be value 4 which is exceed the range of the Hash
table array.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Long Qin <qin.long@intel.com>
Cc: Yao Jiewen <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
3 years agoNetworkPkg: Define the prompt and help information for new PCD.
Zhang Lubo [Mon, 27 Feb 2017 07:53:00 +0000 (15:53 +0800)]
NetworkPkg: Define the prompt and help information for new PCD.

Define the prompt and help information for PcdMaxIScsiAttemptNumber.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
3 years agoNetworkPkg: Add check logic for some variable in iSCSI driver.
Zhang Lubo [Mon, 27 Feb 2017 06:46:59 +0000 (14:46 +0800)]
NetworkPkg: Add check logic for some variable in iSCSI driver.

v2: need to check the global variable mPrivate before using it in
the Convert AttemptConfigData To IfrNvData by Keyword function.

Add check logic for some attempt variable to enhance code in iSCSI.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo <lubo.zhang@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
3 years agoMake [-D Macros] as optional argument for GenCfgOpt
edk2-devel On Behalf Of rthomaiy [Wed, 1 Mar 2017 06:57:58 +0000 (14:57 +0800)]
Make [-D Macros] as optional argument for GenCfgOpt

Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg: use LShiftU64() instead of "<<" to avoid IA32 build error.
Fu Siyuan [Wed, 1 Mar 2017 04:03:26 +0000 (12:03 +0800)]
MdeModulePkg: use LShiftU64() instead of "<<" to avoid IA32 build error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoShellPkg/bcfg: Add Shell Spec 2.2 modification functionality
Chen A Chen [Thu, 23 Feb 2017 06:03:43 +0000 (14:03 +0800)]
ShellPkg/bcfg: Add Shell Spec 2.2 modification functionality

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoShellPkg/Debug1CommandLib: Use StrToGuid/StrHexToBytes in BaseLib
Ruiyu Ni [Tue, 21 Feb 2017 09:20:54 +0000 (17:20 +0800)]
ShellPkg/Debug1CommandLib: Use StrToGuid/StrHexToBytes in BaseLib

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoUefiCpuPkg/PiSmmCpuDxeSmm: Add support for PCD PcdPteMemoryEncryptionAddressOrMask
Leo Duran [Sun, 26 Feb 2017 17:43:07 +0000 (01:43 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

The mask is applied when page tables entriees are created or modified.

CC: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoMdeModulePkg/Universal/Acpi/BootScriptExecutorDxe: Add support for PCD PcdPteMemoryEn...
Leo Duran [Sun, 26 Feb 2017 17:43:06 +0000 (01:43 +0800)]
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

This module updates the under-4GB page tables configured by the S3-Resume
code in UefiCpuPkg/Universal/Acpi/S3Resume2Pei. The mask is saved at module
start (ScriptExecute.c), and applied when tables are expanded on-demand by
page-faults above 4GB's (SetIdtEntry.c).

CC: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoUefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAdd...
Leo Duran [Sun, 26 Feb 2017 17:43:05 +0000 (01:43 +0800)]
UefiCpuPkg/Universal/Acpi/S3Resume2Pei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

The mask is applied when page tables are created (S3Resume.c).

CC: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
3 years agoMdeModulePkg/Universal/CapsulePei: Add support for PCD PcdPteMemoryEncryptionAddressO...
Leo Duran [Sun, 26 Feb 2017 17:43:04 +0000 (01:43 +0800)]
MdeModulePkg/Universal/CapsulePei: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

The mask is applied when 4GB tables are created (UefiCapsule.c), and when
the tables are expanded on-demand by page-faults above 4GB's (X64Entry.c).

Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/Core/DxeIplPeim: Add support for PCD PcdPteMemoryEncryptionAddressOrMask
Leo Duran [Sun, 26 Feb 2017 17:43:03 +0000 (01:43 +0800)]
MdeModulePkg/Core/DxeIplPeim: Add support for PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

The mask is applied when creating page tables.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg: Add PCD PcdPteMemoryEncryptionAddressOrMask
Leo Duran [Sun, 26 Feb 2017 17:43:02 +0000 (01:43 +0800)]
MdeModulePkg: Add PCD PcdPteMemoryEncryptionAddressOrMask

This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.

Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoBaseTools/GenVtf & VolInfo: Fix build fail for 'snprintf' not defined
Hao Wu [Tue, 28 Feb 2017 06:18:53 +0000 (14:18 +0800)]
BaseTools/GenVtf & VolInfo: Fix build fail for 'snprintf' not defined

Function snprintf() is not supported in Visual Studio 2013 or older
version. The commit replaces the use of snprintf() with sprintf() to avoid
build failure for VS compilers.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>
3 years agoMdeModulePkg/DxeCore: implement memory protection policy
Ard Biesheuvel [Fri, 24 Feb 2017 14:51:33 +0000 (14:51 +0000)]
MdeModulePkg/DxeCore: implement memory protection policy

This implements a DXE memory protection policy that ensures that regions
that don't require executable permissions are mapped with the non-exec
attribute set.

First of all, it iterates over all entries in the UEFI memory map, and
removes executable permissions according to the configured DXE memory
protection policy, as recorded in PcdDxeNxMemoryProtectionPolicy.

Secondly, it sets or clears the non-executable attribute when allocating
or freeing pages, both for page based or pool based allocations.

Note that this complements the image protection facility, which applies
strict permissions to BootServicesCode/RuntimeServicesCode regions when
the section alignment allows it. The memory protection configured by this
patch operates on non-code regions only.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg: define PCD for DXE memory protection policy
Ard Biesheuvel [Thu, 23 Feb 2017 10:36:38 +0000 (10:36 +0000)]
MdeModulePkg: define PCD for DXE memory protection policy

Define a new fixed/patchable PCD that sets the DXE memory protection
policy: its primary use is to define which memory types should have
their executable permissions removed. Combined with the image protection
policy, this can be used to implement a strict W^X policy, i.e.. a policy
where no regions exist that are both executable and writable at the same
time.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg/DxeCore: use separate lock for pool allocations
Ard Biesheuvel [Fri, 24 Feb 2017 14:21:18 +0000 (14:21 +0000)]
MdeModulePkg/DxeCore: use separate lock for pool allocations

In preparation of adding memory permission attribute management to
the pool allocator, split off the locking of the pool metadata into
a separate lock. This is an improvement in itself, given that pool
allocations can only interfere with the page allocation bookkeeping
if pool pages are allocated or released. But it is also required to
ensure that the permission attribute management does not deadlock,
given that it may trigger page table splits leading to additional
page tables being allocated.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg/EbcDxe: use EfiBootServicesCode memory for thunks
Ard Biesheuvel [Sun, 26 Feb 2017 16:45:24 +0000 (16:45 +0000)]
MdeModulePkg/EbcDxe: use EfiBootServicesCode memory for thunks

The EBC driver emits thunks for native to EBC calls, which are short
instructions sequences that bridge the gap between the native execution
environment and the EBC virtual machine.

Since these thunks are allocated using MemoryAllocationLib::AllocatePool(),
they are emitted into EfiBootServicesData regions, which does not reflect
the nature of these thunks accurately, and interferes with strict memory
protection policies that map data regions non-executable.

So instead, create a new helper EbcAllocatePoolForThunk() that invokes the
AllocatePool() boot service directly to allocate EfiBootServicesCode pool
memory explicitly, and wire up this helper for the various architecture
specific thunk generation routines.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
3 years agoMdeModulePkg/PeiCore: allocate BootServicesCode memory for PE/COFF images
Ard Biesheuvel [Thu, 23 Feb 2017 09:57:03 +0000 (09:57 +0000)]
MdeModulePkg/PeiCore: allocate BootServicesCode memory for PE/COFF images

Ensure that any memory allocated for PE/COFF images is identifiable as
a boot services code region, so that we know it requires its executable
permissions to be preserved when we tighten mapping permissions later on.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoArmPkg/CpuDxe: ignore attribute changes during SyncCacheConfig()
Ard Biesheuvel [Fri, 24 Feb 2017 09:58:38 +0000 (09:58 +0000)]
ArmPkg/CpuDxe: ignore attribute changes during SyncCacheConfig()

To prevent the initial MMU->GCD memory space map synchronization from
stripping permissions attributes [which we cannot use in the GCD memory
space map, unfortunately], implement the same approach as x86, and ignore
SetMemoryAttributes() calls during the time SyncCacheConfig() is in
progress. This is a horrible hack, but is currently the only way we can
implement strict permissions on arbitrary memory regions [as opposed to
PE/COFF text/data sections only]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>