Tomas Pilar [Fri, 19 Jun 2020 11:59:54 +0000 (12:59 +0100)]
ShellPkg/AcpiView: Add application wrapper
Simple application wrapper that invokes the shell
command wrapper for 'acpiview'.
This allows the AcpiView functionality to be used
on platforms with older specifications of the UEFI
shell or where the 'acpiview' command is not built in
due to platform build configuration.
Furthermore, this app can be integrated into more comprehensive
testing frameworks as a single component of a more thorough
specification compliance validation strategy.
Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
Tomas Pilar [Fri, 19 Jun 2020 11:59:54 +0000 (12:59 +0100)]
ShellPkg: Add AcpiViewCommandLib
The UefiShellAcpiViewCommandLib is converted from NULL library to a
named library so that it may be used in modules other than shell.
The library interface exposes the main method for to AcpiView
functionality as well as a helper method to dump a buffer to a file.
The Shell module is still built by pulling UefiShellAcpiViewCommandLib
as a NULL library to preserve the modularity of shell builds.
Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
Tomas Pilar [Fri, 19 Jun 2020 11:59:54 +0000 (12:59 +0100)]
ShellPkg/AcpiView: Refactor DumpAcpiTableToFile
Method is refactored into two parts. A new method is
created that dumps arbitrary buffers into a newly created
file. This method is called from core code after the core code
determined the appropriate filename to be used.
This improves the modular design.
Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
Tomas Pilar [Fri, 19 Jun 2020 11:59:54 +0000 (12:59 +0100)]
ShellPkg/AcpiView: Refactor configuration
A new file and header (AcpiViewConfig.[ch]) is created
that houses the user configuration. This declutters the
core code and improves modularity of the design.
The module level symbols for verbosity, table selection, and
highlighting are refactored into the new file.
Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Tomas Pilar <tomas.pilar@arm.com>
SHA1 is deprecated but it is required for compatible issue.
So add a MARCO for the platform to disable the usage of SHA1 for
security.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
MD5 is deprecated but it is required for compatible issue.
So add a MARCO for the platform to disable the usage of MD5 for
security.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Pierre Gondois [Fri, 26 Jun 2020 15:28:04 +0000 (16:28 +0100)]
ArmPkg/ArmMmuLib: Fix implicit cast
While building with the following command line:
build -b DEBUG -a AARCH64 -t VS2017 -p MdeModulePkg\MdeModulePkg.dsc
A missing cast triggers the following warning, then triggering an error:
ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c(652):
warning C4152: nonstandard extension, function/data pointer
conversion in expression
This patch first casts the function pointer to (UINTN), then to (VOID *),
followowing the C99 standard s6.3.2.3 "Pointer", paragraphs 5 and 6.
This suppresses the warning.
Ard Biesheuvel [Tue, 23 Jun 2020 17:54:46 +0000 (19:54 +0200)]
ArmVirtPkg/NorFlashQemuLib: disable NOR flash DT nodes upon discovery
Our UEFI guest firmware takes ownership of the emulated NOR flash in
order to support the variable runtime services, and it does not expect
the OS to interfere with the underlying storage directly. So disable
the NOR flash DT nodes as we discover them, in a way similar to how we
disable the PL031 RTC in the device tree when we attach our RTC runtime
driver to it.
Note that this also hides the NOR flash bank that carries the UEFI
executable code, but this is not intended to be updatable from inside
the guest anyway, and if it was, we should use capsule update to do so.
Also, the first -pflash argument that defines the backing for this flash
bank is often issued with the 'readonly' modifier, in order to prevent
any changes whatsoever to be made to the executable firmware image by
the guest.
This issue has become relevant due to the following Linux changes,
which enable the flash driver stack for default build configurations
targetting arm64 and 32-bit ARM.
Abner Chang [Thu, 18 Jun 2020 00:59:51 +0000 (08:59 +0800)]
BaseTools: Add external definitions for RISC-V assembly build
Add opensbi external definitions to RISC-V build for assembly
code. Use GCC5_RISCV_OPENSBI_TYPES to refer to edk2 data type
for assembly files instead of using opensbi data type.
Signed-off-by: Abner Chang <abner.chang@hpe.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Daniel Schaefer <daniel.schaefer@hpe.com> Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ray Ni [Wed, 17 Jun 2020 08:34:29 +0000 (16:34 +0800)]
UefiPayloadPkg/Pci: Use the PCIE Base Addr stored in AcpiBoardInfo HOB
Today's UefiPayloadPkg always uses 0xE0000000 as the PCIE base address
and ignores the value set in AcpiBoardInfo HOB created by the boot
loader. This makes the payload binary cannot work in environment
where the PCIE base address set by boot loader doesn't equal to
0xE0000000.
The patch enhances UefiPayloadPkg so that the PCIE base address
set by boot loader in the AcpiBoardInfo HOB is used.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
Ray Ni [Wed, 3 Jun 2020 09:42:23 +0000 (17:42 +0800)]
MdePkg/PciSegmentInfoLib: Add missing EFIAPI to GetPciSegmentInfo()
All public APIs should have EFIAPI modifier. Somehow PciSegmentInfoLib
missed the EFIAPI modifier.
The patch updates the library header file and NULL instance in MdePkg
to add the missing EFIAPI.
Signed-off-by: Ray Ni <ray.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Introduce FSPT_ARCH_UPD and FSPS_ARCH_UPD to support debug events
and multi-phase silicon initialization.
For backward compatibility the original structures are kept and
new ARCH_UPD structures will be included only when UPD header
revision equal or greater than 2.
GenCfgOpt script also updated to prevent from generating duplicate
FSPT_ARCH_UPD and FSPS_ARCH_UPD typedef structures.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Add a vector at 0xFF000 (0xFFFFF000) that can be used by Init-SIPI-SIPI
to start an AP before memory is initialized. This vector jumps into the
same SEC entry point as the ordinary reset vector, with a special value
of "AP" in the DI register. The platform-specific SEC code is expected
to check for that value and take a different path for APs, if this
feature is supported by the platform.
Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Deric Cole <deric.cole@intel.com>
Igor Druzhinin [Tue, 16 Jun 2020 02:49:42 +0000 (03:49 +0100)]
OvmfPkg: End timer interrupt later to avoid stack overflow under load
RestoreTPL called while at TPL_HIGH_LEVEL unconditionally enables
interrupts even if called in interrupt handler. That opens a window while
interrupt is not completely handled but another interrupt could be
accepted.
If a VM starts on a heavily loaded host hundreds of periodic timer
interrupts might be queued while vCPU is descheduled (the behavior is
typical for a Xen host). The next time vCPU is scheduled again all of them
get delivered back to back causing OVMF to accept each one without
finishing a previous one and cleaning up the stack. That quickly results
in stack overflow and a triple fault.
Fix it by postponing sending EOI until we finished processing the current
tick giving interrupt handler opportunity to clean up the stack before
accepting the next tick.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Message-Id: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2815 Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: add BZ ref; rewrap msg to silence PatchCheck.py]
Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory
in MdeModulePkg.dec are changed, so change them from
PcdsFeatureFlag to PcdsFixedAtBuild in dsc files.
Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory
in MdeModulePkg.dec are changed, so change them from
PcdsFeatureFlag to PcdsFixedAtBuild in dsc files.
Cc: Maurice Ma <maurice.ma@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory
in MdeModulePkg.dec are changed, so change them from
PcdsFeatureFlag to PcdsFixedAtBuild in dsc file.
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
In order to support enable/disable report status code through memory
or serial dynamic, change the following PCDs from [PcdsFeatureFlag] to
[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]:
PcdStatusCodeUseSerial
PcdStatusCodeUseMemory
The original plaforms can use PcdsFixedAtBuild in .dsc files to save size.
Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
The bounce buffering code in NonCoherentDmaLib copies data into the
bounce buffer using CopyMem(), but passes Map->HostAddress as the
source of the copy before it has been assigned its correct value.
Ard Biesheuvel [Tue, 16 Jun 2020 17:35:24 +0000 (19:35 +0200)]
ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure
One of the side effects of the recent changes to PlatformBootManagerLib
changes to avoid connecting all devices on every boot is that we no
longer default to network boot on a virgin boot, but end up in the
UiApp menu. At this point, the UiApp will instantiate the autogenerated
boot options that we used to rely on as before, but since we are already
sitting idle in the root UiApp menu at that point, it does break the
unattended boot case where devices are expected to attempt a network
boot on the very first power on.
Let's work around this by refreshing all boot options explicitly in
the UnableToBoot() handler, and rebooting the system if doing so
resulted in a change to the total number of configured boot options.
This way, we ultimately end up in the UiApp as before if no boot
options could be started, but only after all the autogenerated ones
have been attempted as well.
downloads the vmlinuz and initrd files from the remote OS tree, and passes
them to the guest firmware via fw_cfg.
When used with IA32 / X64 guests, virt-install expects the guest firmware
to do two things, at the same time:
- launch the fw_cfg kernel image even if the latter does not pass SB
verification (SB checking is supposed to be bypassed entirely in favor
of the Linux/x86 Boot Protocol),
- still let the guest kernel perceive SB as enabled.
Commit ced77332cab6 prevented this, by removing the Linux/x86 Boot
Protocol from such an OVMF image that was built with SECURE_BOOT_ENALBE.
While that's the right thing in theory, in practice "virt-install
--location NETWORK-URL" is entrenched, and we shouldn't break it.
We can tolerate the Linux/x86 Boot Protocol as a one-of-a-kind SB bypass
for direct-booted kernels, because:
- the fw_cfg content comes from QEMU, and the guest is already at QEMU's
mercy,
- in the guest, OS boots after the initial installation will use "shim"
rather than an fw_cfg kernel, which we can consider somewhat similar to
"Audit Mode / Deployed Mode" (~ trust for install, lock down after).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Message-Id: <20200615144514.24597-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
[lersek@redhat.com: truncate the subject line, originally auto-generated
by git-revert, to pacify PatchCheck.py]
Ard Biesheuvel [Tue, 9 Jun 2020 08:34:27 +0000 (10:34 +0200)]
StandaloneMmPkg/StandaloneMmCoreEntryPoint: relocate StMM core on the fly
Apply PE/COFF fixups when starting up the standalone MM core, so that
it can execute at any address regardless of the link time address.
Note that this requires the PE/COFF image to be emitted with its
relocation section preserved. Special care is taken to ensure that
TE images are dealt with correctly as well.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ard Biesheuvel [Tue, 9 Jun 2020 08:24:06 +0000 (10:24 +0200)]
StandaloneMmPkg: generate position independent code for StMM core
The standalone MM core runs in a restricted environment that is set
up by a higher privilege level, and which may not allow memory regions
to be writable and executable at the same time.
This means that making the StMM core self-relocatable requires that
all the targets of the relocation fixups are outside of the executable
region of the image, given that we cannot remap the executable code
writable from the executable code itself without losing those execute
permissions.
So instead, use the existing toolchain support to ensure that position
independent code is used where possible, and that all the remaining
relocated quantities are emitted into the data section. (Note that
staticallly initialized const pointers will be emitted into the
.data.rel.ro section, which gets pulled into the .data section by
our linker script)
To ensure that we don't pick up any absolute references in executable
code inadvertently (e.g., in assembler code), add the '-z text' linker
option which will force the build to fail in this case.
Ard Biesheuvel [Tue, 9 Jun 2020 08:16:05 +0000 (10:16 +0200)]
StandaloneMmPkg/Core: fix bogus FV pointer in DEBUG string
FvIsBeingProcessed () emits a DEBUG print with the intent to print
the memory address of the FV that is being processed, but instead,
it prints the contents of an uninitialized stack variable.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ard Biesheuvel [Wed, 10 Jun 2020 07:36:35 +0000 (09:36 +0200)]
MdePkg/BasePrintLib: avoid absolute addresses for error strings
The mStatusString[] array is constructed as an array of pointer-to-char,
which means that on X64 or AARCH64, it is emitted as a single linear list
of 64-bit quantities, each containing the absolute address of one of the
string literals in memory.
This means that each string takes up 8 bytes of additional space, along
with 2 bytes of relocation data. It also means that extra work needs to
be done at runtime to process these relocations, every time a module is
loaded that incorporates this library.
So fix both issues, by splitting mStatusString into two arrays of char
arrays. The memory footprint decreases from 955 to 843 bytes, and given
that in the latter case, the overhead consists of 278 NUL characters rather
than 390 bytes worth of absolute addresses and relocation records, the size
of a compressed image is reduced even further. For example, when building
ArmVirtQemu.dsc in RELEASE mode for AARCH64 with the GCC5 profile, I get:
Before
FV Space Information
FVMAIN [100%Full] 5329920 total, 5329920 used, 0 free
FVMAIN_COMPACT [38%Full] 2093056 total, 811840 used, 1281216 free
After
FV Space Information
FVMAIN [100%Full] 5321728 total, 5321728 used, 0 free
FVMAIN_COMPACT [38%Full] 2093056 total, 809696 used, 1283360 free
So the uncompressed contents of the compressed image are 8 KB smaller,
whereas the resulting flash image (consisting of the compressed image
along with SEC, PEI_CORE and a set of PEIMs that execute in place) is
2 KB smaller.
Removes the FrameworkHandle parameter from SaveFrameworkState() in the
UnitTestLib library instance and updates callers of the function in the
library to use the new function signature.
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The framework handle can be retrieved from GetActiveFrameworkHandle()
internal to SaveFrameworkState() so this change removes the parameter
from the function signature.
Cc: Bret Barkelew <brbarkel@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Ard Biesheuvel [Mon, 8 Jun 2020 11:07:54 +0000 (13:07 +0200)]
ArmVirtPkg/PrePi: use standard PeCoff routines for self-relocation
Instead of having a GCC specific routine to perform self-relocation
based on ELF metadata, use the PE/COFF metadata and the existing
PeCoff library routines. This reduces the amount of bespoke assembler
code that is a burden to maintain, and is not portable across the set
of toolchains we support.
This does require some special care, as we have no control over how
the C code references global symbols, so we need to emit these
references from the calling assembler code. Otherwise, they may be
emitted as absolute references, in which case they need to be fixed
up themselves, leading to a circular dependency.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
Ard Biesheuvel [Mon, 8 Jun 2020 11:02:12 +0000 (13:02 +0200)]
ArmVirtPkg: add FDF rule for self-relocating PrePi
In preparation for making the self-relocating PrePi use the ordinary
BasePeCoffLib routines for relocating the image in place in memory
at start, add a special FDF rule that builds SEC modules as PE32
images with the relocation metadata preserved.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Sami Mujawar <Sami.Mujawar@arm.com>
EmbeddedPkg/MmcDxe: Added MaxBlock Transfer Limit 65535 in R/W.
Moved BlockCount calculation below BufferSize Validation checks.
First Ensure Buffersize is Not Zero and multiple of Media BlockSize.
then calculate BlockCount and perform Block checks.
Corrected BlockCount calculation, as BufferSize is multiple of BlockSize,
So adding (BlockSize-1) bytes to BufferSize and
then divide by BlockSize will have no impact on BlockCount.
Reading Large Images from MMC causes errors.
As per SD Host Controller Spec version 4.20,
Restriction of 16-bit Block Count transfer is 65535.
Max block transfer limit in single cmd is 65535 blocks.
Added Max Block check that can be processed is 0xFFFF.
then Update BlockCount on the basis of MaxBlock.
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com> Reviewed-by: "Loh, Tien Hock" <tien.hock.loh@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2691
For files to be added to the tree, this feature will check
whether it has BSD plus patent license. If not, licenses listed in
Readme are also accepted but warning will be reported.
Otherwise, it should be error.
If the top FFS is placed in FV image, current FV will show there is no space.
In fact, the pad ffs in FV image can be regarded as the spare space.
This change reports the max pad ffs size as the spare space for use.
Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Heyi Guo [Tue, 9 Jun 2020 01:26:30 +0000 (09:26 +0800)]
ArmPkg/ArmExceptionLib: use static buffer for sp_el0
The exception library is also used in DxeMain before memory services
are available, and AllocatePages() will fail in this case and cause
sp_el0 remains 0. Then if any exception occurs before CpuDxe driver is
loaded, a recursive exception will be trigged by page translation
fault for sp = 0 - 0x130.
Laszlo Ersek [Tue, 9 Jun 2020 10:54:14 +0000 (12:54 +0200)]
OvmfPkg/GenericQemuLoadImageLib: log "Not Found" at INFO level
gBS->LoadImage() returning EFI_NOT_FOUND is an expected condition; it
means that QEMU wasn't started with "-kernel". Log this status code as
INFO rather than ERROR.
Recording to the spec, the reconnect is activated upon exiting of the
formset or the browser. Exiting is by user but form-browser internal
logic. That means the reconnection is only happened when user press
ESC or _EXIT action to exit form.
Driver callback may update HII form dynamically so form-browser needs
to refresh its internal data. It's not exiting formset for user
exactly and they didn't know what happened. So use a flag to record
that and do not reconnect driver if updated by callback.
Signed-off-by: Walon Li <walon.li@hpe.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Eric Dong [Wed, 10 Jun 2020 03:38:26 +0000 (11:38 +0800)]
Maintainers.txt: Add reviewer for Pei Core.
Signed-off-by: Eric Dong <eric.dong@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
Dong, Eric [Wed, 3 Jun 2020 03:18:05 +0000 (11:18 +0800)]
Maintainers.txt: Add reviewer for SEC related modules.
Signed-off-by: Eric Dong <eric.dong@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@Intel.com>
MdeModulePkg: Sets the Cursor to selected BootOption.
Its been observed that in MenuManagerMenuApp when user
selects a different BootOption using Up/Down key, the
current Cursor position is not chaning.
Still points to the old BootOption.
This changes first dispalys/redraws the old BootOption
followed by new BootOption. Doing so will make current
cursor pointing to the user selected BootOption.
Signed-off-by: Abdul Lateef Attar <abdul@marvell.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Laszlo Ersek [Fri, 5 Jun 2020 23:52:42 +0000 (01:52 +0200)]
OvmfPkg/X86QemuLoadImageLib: handle EFI_ACCESS_DENIED from LoadImage()
When an image fails Secure Boot validation, LoadImage() returns
EFI_SECURITY_VIOLATION if the platform policy is
DEFER_EXECUTE_ON_SECURITY_VIOLATION.
If the platform policy is DENY_EXECUTE_ON_SECURITY_VIOLATION, then
LoadImage() returns EFI_ACCESS_DENIED (and the image does not remain
loaded).
(Before <https://bugzilla.tianocore.org/show_bug.cgi?id=2129>, this
difference would be masked, as DxeImageVerificationLib would incorrectly
return EFI_SECURITY_VIOLATION for DENY_EXECUTE_ON_SECURITY_VIOLATION as
well.)
In X86QemuLoadImageLib, proceed to the legacy Linux/x86 Boot Protocol upon
seeing EFI_ACCESS_DENIED too.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2785 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200605235242.32442-1-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Wed, 3 Jun 2020 17:04:13 +0000 (19:04 +0200)]
OvmfPkg/Tcg2ConfigPei: restrict BaseLib class dependency to IA32 and X64
BaseLib interfaces (namely, SwapBytesXx()) are only used in
"Tpm12Support.c", which is IA32/X64-only. Therefore the BaseLib class
dependency should also be restricted to IA32 & X64, in the INF file.
The "#include <Library/BaseLib.h>" directive is already present in
"Tpm12Support.c" only.
(The BaseLib dependency should have been restricted to IA32 and X64
together with the Tpm12DeviceLib dependency, as part of commit 74f90d38c446, "OvmfPkg/Tcg2ConfigPei: skip TPM-1.2 detection when building
for ARM/AARCH64", 2020-05-21.)
This is a trivial cleanup; functionally a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603170413.23936-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The leading comments in "Tcg2ConfigPei.inf" and "Tcg2ConfigPeim.c" say,
"In OvmfPkg, the module only performs TPM2 hardware detection".
The statement hasn't been correct since commit 89236992913f ("OvmfPkg:
detect TPM 1.2 in Tcg2ConfigPei", 2020-03-04). Replace "TPM2" with "TPM"
(without stating a version) in those file-top comments.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2752 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603170413.23936-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Laszlo Ersek [Wed, 3 Jun 2020 16:06:27 +0000 (18:06 +0200)]
Maintainers.txt: move StandaloneMmPkg to the right spot
Place StandaloneMmPkg between SourceLevelDebugPkg and UefiCpuPkg, where it
belongs in lexicographical order. (Right now it succeeds
UnitTestFrameworkPkg, which is a disorder.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2778 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200603160627.3594-4-lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Leif Lindholm [Sun, 7 Jun 2020 20:03:43 +0000 (21:03 +0100)]
ArmPkg: only attempt buildin MmCommunicationDxe for AArch64
Commit 045e4b84c18f ("ArmPkg/ArmPkg.dsc: Add missing components")
adds some components to the ArmPkg.dsc build config, but it adds
them to Components.common, and MmCommunicationDxe is AArch64 only.
Move it to Components.AARCH64 to stop the ARM build breaking.
The Trim.py would break the build process when the file not found
issue occures, however sometimes we do not care about this issue.
This patch changes the error with warning in order to solve this
kind of break.
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Yuwei Chen <yuwei.chen@intel.com> Reviewed-by: Bob Feng<bob.c.feng@intel.com>
Irene Park [Tue, 2 Jun 2020 21:58:50 +0000 (05:58 +0800)]
BaseTools/build.py: Exit with 1 when AutoGen error occurred
AutoGen manager/workers halt the progress when an error occurs but
doesn't propagate the error code to main and allows main exit with 0
and gets the build system unable to catch the occurrence of an error.
This change informs main with an error when a progress is halted and
helps main exit with 1.
Signed-off-by: Irene Park <ipark@nvidia.com> Reviewed-by: Bob Feng<bob.c.feng@intel.com>
Ard Biesheuvel [Thu, 28 May 2020 09:17:41 +0000 (11:17 +0200)]
ArmPkg/PlatformBootManagerLib: don't connect all devices on each boot
In order to avoid boot delays from devices such as network controllers
that may not even be involved in booting at all, drop the call to
EfiBootManagerConnectAll () from the boot path. It will be called by
UiApp, so when going through the menu, all devices will be connected
as usual, but for the default boot, it is really not necessary so
let's get rid of this.
Enumerating all possible boot options and creating Boot#### variables
for them is equally unnecessary in the default case, and also happens
automatically in UiApp, so drop that as well.
Ard Biesheuvel [Thu, 28 May 2020 09:17:40 +0000 (11:17 +0200)]
ArmPkg/PlatformBootManagerLib: hide UEFI Shell as a regular boot option
Without ConnectAll() being called on the boot path, the UEFI shell will
be entered with no block devices or anything else connected, and so for
the novice user, this is not a very accommodating environment. Now that
we have made the UiApp the last resort on boot failure, and made the
UEFI Shell accessible directly via the 's' hotkey if you really need
it, let's hide it as an ordinary boot option.
Ard Biesheuvel [Thu, 28 May 2020 09:17:39 +0000 (11:17 +0200)]
MdeModulePkg/BootManagerUiLib: show inactive boot options
UEFI boot options may exist but have the LOAD_OPTION_ACTIVE flag
cleared. This means that the boot option should not be selected
by default, but it does not mean it should be omitted from the
boot selection presented by the boot manager: for this purpose,
another flag LOAD_OPTION_HIDDEN exists.
Given that the latter flag exists solely for the purpose of omitting
boot options from the boot selection menu, and LOAD_OPTION_XXX flags
can be combined if desired, hiding inactive boot options as well is
a mistake, and violates the intent of paragraph 3.1.3 of the UEFI
specification (revision 2.8 errata A). Let's fix this by dropping
the LOAD_OPTION_ACTIVE check from the code that populates the boot
selection menu.
Ard Biesheuvel [Thu, 28 May 2020 09:17:38 +0000 (11:17 +0200)]
ArmPkg/PlatformBootManagerLib: fall back to the UiApp on boot failure
As a last resort, drop into the UiApp application when no active boot
options could be started. Doing so will connect all devices, and so
it will allow the user to enter the Boot Manager submenu and pick a
network or removable disk option.
Note that this only occurs if even the default removable filepath
could not be booted (e.g., \EFI\BOOT\BOOTAA64.EFI on AArch64)
Ard Biesheuvel [Thu, 28 May 2020 09:17:37 +0000 (11:17 +0200)]
ArmPkg/PlatformBootManagerLib: register 's' as UEFI Shell hotkey
In preparation of hiding the UEFI Shell boot option as an ordinary
boot option, make sure we can invoke it directly using the 's'
hotkey. Without ConnectAll() having been called, this results in
a shell that may have no block devices or other things connected,
so don't advertise the 's' in the console string that is printed
at boot - for novice users, we will go through the UiApp which
connects everything first. For advanced use, having the ability
to invoke the UEFI shell without any devices connected may be an
advantage, so let's keep this behavior as is for now.
Ard Biesheuvel [Fri, 22 May 2020 08:40:06 +0000 (10:40 +0200)]
ArmPkg/PlatformBootManagerLib: connect non-discoverable USB hosts
The way the BDS handles the short-form USB device path of the console
keyboard relies on USB host controllers to be locatable via their PCI
metadata, which implies that these controllers already have a PCI I/O
protocol installed on their handle.
This is not the case for non-discoverable USB host controllers that are
supported by the NonDiscoverable PCI device driver. These controllers
must be connected first, or the BDS will never notice their existence,
and will not enable any USB keyboards connected through them.
Let's work around this by connecting these handles explicitly. This is
a bit of a stopgap, but it is the cleanest way of dealing with this
without violating the UEFI driver model entirely. This ensures that
platforms that do not rely on ConnectAll() will keep working as
expected.
Supervisor Call instruction (SVC) is used by the Arm Standalone MM
environment to request services from the privileged software (such as
ARM Trusted Firmware running in EL3) and also return back to the
non-secure caller via EL3. Some Arm CPUs speculatively executes the
instructions after the SVC instruction without crossing the privilege
level (S-EL0). Although the results of this execution are
architecturally discarded, adversary running on the non-secure side can
manipulate the contents of the general purpose registers to leak the
secure work memory through spectre like micro-architectural side channel
attacks. This behavior is demonstrated by the SafeSide project [1] and
[2]. Add barrier instructions after SVC to prevent speculative execution
to mitigate such attacks.
Nickle Wang [Thu, 9 Apr 2020 03:20:39 +0000 (11:20 +0800)]
EmulatorPkg/WinHost: Enable network support.
Follow the implementation from Unix host to implement SNP
EMU_IO_THUNK_PROTOCOL and EMU_SNP_PROTOCOL. The network IO driver is the
same one as Nt32. Please refer to NETWORK-IO Subproject for network Io
driver(SnpNt32Io.dll).
Signed-off-by: Nickle Wang <nickle.wang@hpe.com> Signed-off-by: Derek Lin <derek.lin2@hpe.com> Acked-by: Ray Ni <ray.ni@intel.com>
Ard Biesheuvel [Wed, 3 Jun 2020 19:32:17 +0000 (21:32 +0200)]
ArmPkg/ArmPkg.dsc: set terminal type PCD to the right value
PlatformBootManagerLib now asserts at build time that the correct
terminal type is used, and so leaving it unset breaks the ArmPkg
DSC build. So fix that.
Ard Biesheuvel [Tue, 19 May 2020 12:23:51 +0000 (14:23 +0200)]
ArmPkg/PlatformBootManagerLib: reject 'default' parity and stop bit count
In the ArmPkg version of PlatformBootManagerLib, we construct a
serial device path based on the default settings for baud rate,
parity and the number of stop bits, to ensure that a serial console
is available even on the very first boot.
This assumes that PcdUartDefaultParity or PcdUartDefaultStopBits are
not set to '0', meaning 'the default', as there is no default for
these when constructing a device path.
So add a couple of STATIC_ASSERT()s to make sure that we catch this
condition, since it otherwise ignores the bogus device path silently,
which is rather tedious to debug,.
Ard Biesheuvel [Tue, 19 May 2020 12:23:50 +0000 (14:23 +0200)]
ArmPkg/PlatformBootManagerLib: use static assertion for console type
Replace the runtime ASSERT with the build time STATIC_ASSERT on the
check that ensures that the terminal type we use for the serial
console matches the one we explicitly add to the ConIn/ConOut/StdErr
variables.
This helps catch serial console issues early, even in RELEASE builds,
reducing the risk of ending up with no console at all, which can be
tricky to debug on bare metal.
Ard Biesheuvel [Wed, 20 May 2020 11:44:48 +0000 (13:44 +0200)]
ArmPkg/CompilerIntrinsicsLib: provide atomics intrinsics
Gary reports the GCC 10 will emit calls to atomics intrinsics routines
unless -mno-outline-atomics is specified. This means GCC-10 introduces
new intrinsics, and even though it would be possible to work around this
by specifying the command line option, this would require a new GCC10
toolchain profile to be created, which we prefer to avoid.
So instead, add the new intrinsics to our library so they are provided
when necessary.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Gary Lin <glin@suse.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Bret Barkelew [Fri, 14 Feb 2020 15:01:01 +0000 (07:01 -0800)]
UnitTestFrameworkPkg: Add info to readme about working with UnitTests
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Bret Barkelew <bret.barkelew@microsoft.com> Signed-off-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The ReportOutput() function in UnitTestResultReportLib copies characters
from a function input buffer to an intermediate local buffer in fixed
size chunks of the maximum size of the intermediate buffer. The
implementation currently calls AsciiStrCpyS() which will ASSERT on an
error.
This commit changes the call to AsciiStrnCpyS() to avoid the
ASSERT which is not expected in the usage of the string copy in this
implementation.
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Runtime checks returned via status return code should not work as
assertions to permit parsing not trusted data with SafeString
interfaces. Replace ASSERT() with a DEBUG_VERBOSE message.
Cc: Andrew Fish <afish@apple.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Bret Barkelew <bret.barkelew@microsoft.com> Cc: Brian J. Johnson <brian.johnson@hpe.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Marvin Häuser <mhaeuser@outlook.de> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Vincent Zimmer <vincent.zimmer@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Maggie Chu [Mon, 18 May 2020 11:41:50 +0000 (19:41 +0800)]
SecurityPkg: Change default value source
https://bugzilla.tianocore.org/show_bug.cgi?id=2713
In current code, If TCG2_PHYSICAL_PRESENCE_FLAGS_VARIABLE variable
is not exist, code will get default value from two places.
This fix is to make the default value comes from the PCD
gEfiSecurityPkgTokenSpaceGuid.PcdTcg2PhysicalPresenceFlags
Signed-off-by: Maggie Chu <maggie.chu@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Sami Mujawar [Fri, 22 Nov 2019 18:48:21 +0000 (18:48 +0000)]
BaseTools: Remove deprecated Visual Studio Option
The VS2017 compiler reports 'warning D9035 : option
'Gm' has been deprecated and will be removed in a
future release'
The documentation for the 'Gm' option at
https://docs.microsoft.com/en-us/cpp/build/reference/gm-enable-minimal-rebuild?view=vs-2019
indicates that this option can be safely removed
from the project.
Therefore, remove the deprecated 'Gm' Visual Studio
Compiler option.
Laszlo Ersek [Wed, 20 May 2020 22:58:41 +0000 (00:58 +0200)]
OvmfPkg/Tcg2ConfigPei: skip TPM-1.2 detection when building for ARM/AARCH64
Dating back to commits f5cb3767038e and ddd34a818315d, the
"ArmVirtPkg/ArmVirtQemu.dsc" platform includes the
"OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module when the TPM2_ENABLE
build flag is defined.
This was regressed in commit 89236992913f, which added a Tpm12DeviceLib
dependency to Tcg2ConfigPei. "ArmVirtQemu.dsc" does not resolve that class
to any instance, so now we get a build failure:
> build.py...
> ArmVirtPkg/ArmVirtQemu.dsc(...): error 4000: Instance of library class
> [Tpm12DeviceLib] is not found
> in [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] [AARCH64]
> consumed by module [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf]
The TPM-1.2 code in OvmfPkg/Tcg2ConfigPei is limited to a special use case
(a kind of physical TPM-1.2 assignment), and that has never applied to
"ArmVirtQemu.dsc".
Short-circuit the TPM-1.2 detection in the ARM/AARCH64 builds of
OvmfPkg/Tcg2ConfigPei, removing the Tpm12DeviceLib dependency.
Functionally, this patch is a no-op on IA32 / X64.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Simon Hardy <simon.hardy@itdev.co.uk> Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Wed, 20 May 2020 22:58:40 +0000 (00:58 +0200)]
OvmfPkg/Tcg2ConfigPei: factor out InternalTpm12Detect()
Move the calls to the Tpm12RequestUseTpm() and Tpm12SubmitCommand()
Tpm12DeviceLib functions to a separate C file, so that we can override
these actions in a subsequent patch.
This code movement requires moving the TPM_RSP_GET_TICKS / TestTpm12()
helper structure / function too.
While at it, give the TestTpm12() function @retval / @return
documentation, plus wrap an overlong line in it.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Simon Hardy <simon.hardy@itdev.co.uk> Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Wed, 20 May 2020 22:58:39 +0000 (00:58 +0200)]
OvmfPkg/Tcg2ConfigPei: clean up some lib class dependencies
Commit 89236992913f introduced an explicit Tpm12CommandLib dependency to
Tcg2ConfigPei.
In reality this lib class is not consumed by Tcg2ConfigPei at all (such a
dependency is not even inherited from other lib instances). Simplify the
module by dropping the superfluous dependency.
(The Tpm12CommandLib class resolution that was also added in commit 89236992913f is not useless, at the platform build level: it is consumed
by TcgPei and TcgDxe. Meaning that said Tpm12CommandLib resolution should
have likely been a part of the subsequent patch in the original series,
namely commit 6be54f15a0c9.)
Commit 89236992913f also introduced SwapBytesXx() calls. Those functions
are provided by BaseLib. Spell out the BaseLib dependency.
Functionally, this patch is a no-op.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Eric Auger <eric.auger@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Simon Hardy <simon.hardy@itdev.co.uk> Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-2-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
When FSP switching stack and calling bootloader functions,
the function parameter in stack may not be accessible easily.
We can store the function parameter pointer to FspGlobalData
and retrieve it after stack switched.
Also need to add Loader2PeiSwitchStack () to header file
as public function for platform FSP code to consume.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Oleksiy Yakovlev [Thu, 14 May 2020 20:51:43 +0000 (04:51 +0800)]
MdePkg: Add FMP Capsule Image Header extension
Add bitmask to structure which gives a binary-inspectable mechanism to
determine if a capsule contains an authentication section or depex section.
(UEFI 2.8 errata a, mantis 2026)
Liming Gao [Tue, 19 May 2020 15:47:33 +0000 (23:47 +0800)]
MdePkg: Add EFI_RT_PROPERTIES_TABLE
Define Guid & data structure for EFI_RT_PROPERTIES_TABLE, designed
to be published by a platform if it no longer supports all EFI
runtime services once ExitBootServices() has been called by the OS.
(UEFI 2.8 errata a, mantis 2049)
Zhang, Shenglei [Wed, 20 May 2020 03:08:47 +0000 (11:08 +0800)]
NetworkPkg/DxeNetLib: Change the order of conditions in IF statement
The condition, NET_HEADSPACE(&(Nbuf->BlockOp[Index])) < Len, is
meaningless if Index = 0. So checking 'Index != 0' should be
performed first in the if statement.
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Jiaxin Wu <jiaxin.wu@intel.com> Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com> Reviewed-by: Maciej Rabeda <maciej.rabeda@linux.intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:51 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: increase memory type info defaults
Any new OVMF binary (containing commit d42fdd6f8384, and built with
SMM_REQUIRE) is likely to reboot during its first boot, regardless of
whether the variable store is logically empty, or it contains a
MemoryTypeInformation variable from an earlier OVMF binary.
This "reboot on first boot after OVMF upgrade" occurs despite having
eliminated BS Code/Data tracking in earlier parts of this series. Meaning
that we've outgrown the bins of those memory types too that matter for SMM
security.
Eliminating said reboot will make an upgrade to edk2-stable202005 more
comfortable for users. Increase the defaults empirically. (The total
doesn't exceed 3MB by much.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-5-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:50 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: extract memory type info defaults to PCDs
Some OvmfPkg modules already depend on "EmbeddedPkg.dec"; thus, replace
the open-coded memory type info defaults in the source code with the
EmbeddedPkg PCDs that stand for the same purpose. Consequently, platform
builders can override these values with the "--pcd" option of "build",
without source code updates.
While at it, sort the memory type names alphabetically.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-4-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:49 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: rewrite MemTypeInfo HOB production logic
The previous patch has no effect -- i.e., it cannot stop the tracking of
BS Code/Data in MemTypeInfo -- if the virtual machine already has a
MemoryTypeInformation UEFI variable.
In that case, our current logic allows the DXE IPL PEIM to translate the
UEFI variable to the HOB, and that translation is verbatim. If the
variable already contains records for BS Code/Data, the issues listed in
the previous patch persist for the virtual machine.
For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This
prevents the DXE IPL PEIM's variable-to-HOB translation.
In PlatformPei, consume the records in the MemoryTypeInformation UEFI
variable as hints:
- Ignore all memory types for which we wouldn't by default install records
in the HOB. This hides BS Code/Data from any existent
MemoryTypeInformation variable.
- For the memory types that our defaults cover, enable the records in the
UEFI variable to increase (and *only* to increase) the page counts.
This lets the MemoryTypeInformation UEFI variable function as designed,
but it eliminates a reboot when such a new OVMF binary is deployed (a)
that has higher memory consumption than tracked by the virtual machine's
UEFI variable previously, *but* (b) whose defaults also reflect those
higher page counts.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Laszlo Ersek [Fri, 8 May 2020 12:16:48 +0000 (14:16 +0200)]
OvmfPkg/PlatformPei: don't track BS Code/Data in default MemTypeInfo HOB
In commit d42fdd6f8384 ("OvmfPkg: improve SMM comms security with adaptive
MemoryTypeInformation", 2020-03-12), we enabled the boot-to-boot tracking
of the usages of various UEFI memory types.
Both whitepapers listed in that commit recommend that BS Code/Data type
memory *not* be tracked. This recommendation was confirmed by Jiewen in
the following two messages as well:
While tracking BS Code/Data type memory has one benefit (it de-fragments
the UEFI memory map), the downsides outweigh it. Spikes in BS Data type
memory usage are not uncommon in particular, and they may have the
following consequences:
- such reboots during normal boot that look "spurious" to the end user,
and have no SMM security benefit,
- a large BS Data record in MemoryTypeInformation may cause issues when
the DXE Core tries to prime the according bin(s), but the system's RAM
size has been reduced meanwhile.
Removing the BS Code/Data entries from MemoryTypeInformation leads to a
bit more fragmentation in the UEFI memory map, but that should be
harmless.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706 Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Intel SDM introduces 6-levels for describing the CPU topology:
* Package
* Module
* Tile
* Die
* Core
* Thread
A PI spec ECR was submitted to enhance CPU_MP PPI/Protocol to
support returning such information through GetProcessorInfo().
An accordingly change was implemented and pushed to edk2-staging.
Now the PI spec has been published.
The patch is cherry-picked from edk2-staging to edk2.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Robert Phelps [Mon, 11 May 2020 20:24:13 +0000 (04:24 +0800)]
MdePkg: Update structures for MpServices Protocol
Added EXTENDED_PROCESSOR_INFORMATION structure and supporting
structures and definitions. The intent is to support updated
topology layout for CPUs. (PI 1.7a Mantis 2071)
Signed-off-by: Robert Phelps <robert@ami.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
projects / mirror_edk2.git / log