UEFI v2.10 introduces a new flag to the memory attributes table to
inform the OS whether or not runtime services code regions were emitted
by the compiler with guard instructions for forward edge control flow
integrity enforcement.
So update our definition accordingly.
Link: https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-memory-attributes-table
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
This fixes messages like:
"Image type AARCH64 can't be loaded on <Unknown> UEFI system"
Cc: Daniel Schaefer <git@danielschaefer.me>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4315
MemoryType of EfiUnacceptedMemoryType should not be allocated in
AllocatePool. Instead it should return EFI_INVALID_PARAMETER.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Michael Roth <michael.roth@amd.com>
Reported-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Location of notification is has been specified in UEFI v2.9.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: "Min M. Xu" <min.m.xu@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: "Michael D. Kinney" <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
Message-Id: <20221108164616.3251967-4-dionnaglaze@google.com>
The page allocator code in CoreFindFreePagesI() uses a mask derived from
its UINTN Alignment argument to align the descriptor end address of a
MEMORY_MAP entry to the requested alignment, in order to check whether
the descriptor covers enough sufficiently aligned area to satisfy the
request.
However, on 32-bit architectures, 'Alignment' is a 32-bit type, whereas
DescEnd is a 64-bit type, and so the resulting operation performed on
the end address comes down to masking with 0xfffff000 instead of the
intended 0xffffffff_fffff000. Given the -1 at the end of the expression,
the resulting address is 0xffffffff_fffffffff for any descriptor that
ends on a 4G aligned boundary, and this is certainly not what was
intended.
So cast Alignment to UINT64 to ensure that the mask has the right size.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3387
Added use of SafeIntLib to validate values are not causing overflows or
underflows in user controlled values when calculating buffer sizes.
Signed-off-by: Miki Demeter <miki.demeter@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Unaccepted memory is a kind of new memory type,
CoreInitializeGcdServices() and CoreGetMemoryMap() are updated to handle
the unaccepted memory type.
Ref: microsoft/mu_basecore@97e9c31
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Updates debug macros in the package that have an imbalanced number
of print specifiers to arguments. These changes try to preserve
what was likely intended by the author. In cases information was
missing due to the bug, the specifier may be removed since it was
not previously accurately printing the expected value.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Remove clearing CR0.WP when marking the memory used for page table
as read-only in the page table itself created by DxeIpl. This page
table address is written to Cr3 after these protection steps. Till
this, the memory used for page table is always RW.
Signed-off-by: Dun Tan <dun.tan@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Hide the Exception implementation details in CpuExcetionHandlerLib and
caller only need to provide buffer
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
REF: https://https://bugzilla.tianocore.org/show_bug.cgi?id=3795
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Updated CoreInternalAllocatePages() to call PromoteMemoryResource() and
re-attempt the allocation if unable to convert the specified memory range
Signed-off-by: Stacy Howell <stacy.howell@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Commit e7abb94d1 removed InitializeCpuExceptionHandlersEx
and updated DxeMain to call InitializeCpuExceptionHandlers
for exception setup. But the old behavior that calls *Ex() sets
up the stack guard as well. To match the old behavior,
the patch calls InitializeSeparateExceptionStacks.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Today InitializeCpuExceptionHandlersEx is called from three modules:
1. DxeCore (links to DxeCpuExceptionHandlerLib)
DxeCore expects it initializes the IDT entries as well as
assigning separate stacks for #DF and #PF.
2. CpuMpPei (links to PeiCpuExceptionHandlerLib)
and CpuDxe (links to DxeCpuExceptionHandlerLib)
It's called for each thread for only assigning separate stacks for
#DF and #PF. The IDT entries initialization is skipped because
caller sets InitData->X64.InitDefaultHandlers to FALSE.
Additionally, SecPeiCpuExceptionHandlerLib, SmmCpuExceptionHandlerLib
also implement such API and the behavior of the API is simply to initialize
IDT entries only.
Because it mixes the IDT entries initialization and separate stacks
assignment for certain exception handlers together, in order to know
whether the function call only initializes IDT entries, or assigns stacks,
we need to check:
1. value of InitData->X64.InitDefaultHandlers
2. library instance
This patch cleans up the code to separate the stack assignment to a new API:
InitializeSeparateExceptionStacks().
Only when caller calls the new API, the separate stacks are assigned.
With this change, the SecPei and Smm instance can return unsupported which
gives caller a very clear status.
The old API InitializeCpuExceptionHandlersEx() is removed in this patch.
Because no platform module is consuming the old API, the impact is none.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3488
Current free pool routine from PiSmmCore will inspect memory guard status
for target buffer without considering pool headers. This could lead to
`IsMemoryGuarded` function to return incorrect results.
In that sense, allocating a 0 sized pool could cause an allocated buffer
directly points into a guard page, which is legal. However, trying to
free this pool will cause the routine changed in this commit to read XP
pages, which leads to page fault.
This change will inspect memory guarded with pool headers. This can avoid
errors when a pool content happens to be on a page boundary.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
Correct the logic about whether 5-level paging is supported.
Signed-off-by: Jason Lou <yun.lou@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
When setting mVirtualMap to NULL also set mVirtualMapMaxIndex to 0.
Without that RuntimeDriverConvertPointer() will go search the ZeroPage
for EFI_MEMORY_DESCRIPTOR entries.
In case mVirtualMapMaxIndex happens to be small small enough that'll go
unnoticed, the search will not find anything and EFI_NOT_FOUND will be
returned.
In case mVirtualMapMaxIndex is big enough the search will reach the end
of the ZeroPage and trigger a page fault.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdeModulePkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3767
Update use of DEBUG_CODE(Expression) if Expression is a complex code
block with if/while/for/case statements that use {}.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760
Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3680
This patch fixes the following issue:
The global variable gHandleList is a linked list.
This list is locked when a entry is added or removed from the list,
but there is no lock when iterating this list in function
CoreValidateHandle().
It can lead to "Handle.c (76): CR has Bad Signature" assertion if the
iterated entry in the list is just removed by other task during iterating.
Currently some caller functions of CoreValidateHandle() have
CoreAcquireProtocolLock(), but some caller functions of
CoreValidateHandle() do not CoreAcquireProtocolLock().
Add CoreAcquireProtocolLock() always when CoreValidateHandle() is called,
Also, A lock check is added in the CoreValidateHandle().
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hua Ma <hua.ma@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3666
Currently, CoreLocateHandleBuffer() follows three steps:
1) get the size of protocol database firstly
2) allocate the buffer based on the size
3) get the protocol database into the buffer
There is no lock protection for the whole three steps. If a new protocol
added in step 2) by other task, e.g. (event timer handle USB device
hotplug). The size of protocol database may be increased and cannot fit
into the previous buffer in step 3). The protocol database cannot be
returned successfully, EFI_BUFFER_TOO_SMALL error will be returned.
This patch adds the lock to protect the whole three steps.
It can make sure the correct protocol database be returned.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Hua Ma <hua.ma@intel.com>
Reviewed-by: Dandan Bi dandan.bi@intel.com
Reviewed-by: Liming Gao gaoliming@byosoft.com.cn
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3512
In 32-bit PEI, the local variable pointers MigratedFvHeader and
RawDataFvHeader in EvacuateTempRam() will be 32-bit in size. The
pointers are currently passed to PeiServicesAllocatePages() which
expects a 64-bit output buffer of type EFI_PHYSICAL_ADDRESS.
When PeiServicesAllocatePages() writes to the buffer, the data
can overflow.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Currently, the debug message that prints the name of a PEIM
being migrated is DEBUG_INFO while similar messages are
DEBUG_VERBOSE. This change updates the print level to
DEBUG_VERBOSE for consistency.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Corrects a typo in the return value description of MigratePeim() and
EvacuateTempRam():
"Succesfully" to "Successfully"
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The legacy codebase allowed SMM images to be registered for profiling
from DXE. Support for this has been dropped entirely, so remove the
remaining handlers.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Vitaly Cheptsov <vit9696@protonmail.com>
Signed-off-by: Marvin H?user <mhaeuser@posteo.de>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3564
This function has not been called since it was added in commit
9bedaec. If the function were to remain, it would need to be
re-evaluated and tested. This change removes the function since
it is not being used.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Harry Han <harry.han@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Cc: Marvin H?user <mhaeuser@posteo.de>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
1. Reduce the debug message during boot.
2. Update SmmCore debug level of MemoryAttributesTable align to DxeCore.
Signed-off-by: Yang Gang <yanggang@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
EFI_PEI_LOAD_FILE_PPI is invoked by DxeIpl for loading DxeCore.
It's possible that the instance produced by PeiCore fails to load but
other instances of EFI_PEI_LOAD_FILE_PPI can load.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Fix various typos throughout MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The DXE Core sets up a protocol notify function in its entry point, for
instances of the Firmware Volume Block2 Protocol:
DxeMain() [DxeMain/DxeMain.c]
FwVolDriverInit() [FwVol/FwVol.c]
Assume that a 3rd party UEFI driver or application installs an FVB
instance, with crafted contents. The notification function runs:
NotifyFwVolBlock() [FwVol/FwVol.c]
installing an instance of the Firmware Volume 2 Protocol on the handle.
(Alternatively, assume that a 3rd party application calls
gDS->ProcessFirmwareVolume(), which may also produce a Firmware Volume 2
Protocol instance.)
The EFI_FIRMWARE_VOLUME2_PROTOCOL.ReadSection() member performs "a
depth-first, left-to-right search algorithm through all sections found in
the specified file" (quoting the PI spec), as follows:
FvReadFileSection() [FwVol/FwVolRead.c]
GetSection() [SectionExtraction/CoreSectionExtraction.c]
FindChildNode() [SectionExtraction/CoreSectionExtraction.c]
FindChildNode() // recursive call
FindChildNode() is called recursively for encapsulation sections.
Currently this recursion is not limited. Introduce a new PCD
(fixed-at-build, or patchable-in-module), and make FindChildNode() track
the section nesting depth against that PCD.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1743
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119105340.16225-3-lersek@redhat.com>
FindChildNode() has two callers: GetSection(), and FindChildNode() itself.
- At the GetSection() call site, a positive (i.e., nonzero)
SectionInstance is passed. This is because GetSection() takes a
zero-based (UINTN) SectionInstance, and then passes
Instance=(SectionInstance+1) to FindChildNode().
- For reaching the recursive FindChildNode() call site, a section type
mismatch, or a section instance mismatch, is necessary. This means,
respectively, that SectionInstance will either not have been decreased,
or not to zero anyway, at the recursive FindChildNode() call site.
Add two ASSERT()s to FindChildNode(), for expressing the (SectionSize>0)
invariant.
In turn, the invariant provides the explanation why, after the recursive
call, a zero SectionInstance implies success. Capture it in a comment.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119105340.16225-2-lersek@redhat.com>
CoreInitializeMemoryServices() logs "BaseAddress" and "Length" with
DEBUG() before DxeMain() calls ProcessLibraryConstructorList()
explicitly. (Library construction is not an automatic part of the DXE
Core entry point.)
So those DEBUG()s in CoreInitializeMemoryServices() are issued against
an un-constructed DebugLib, and also against a -- possibly underlying --
un-constructed SerialPortLib.
Some DebugLib instances can deal with this (see for example commit
91a5b13650, "OvmfPkg/PlatformDebugLibIoPort: fix port detection for
use in the DXE Core", 2018-08-06), while some others can't (see for
example the DebugLib instance
"MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf"
coupled with the SerialPortLib instance
"ArmVirtPkg/Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.inf").
Addressing this issue in a SerialPortLib instance that underlies
BaseDebugLibSerialPort seems wrong; either the DebugLib instance should
cope directly with being called un-constructed (see again commit
91a5b13650), or the DXE Core should log relevant information *at
least* after library instances have been constructed. This patch
implements the latter (only for the "BaseAddress" and "Length" values
calculated by CoreInitializeMemoryServices()).
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201103161557.30621-1-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
CoreInitializeMemoryServices was not checking for any existing memory
allocation created in the HOB producer phase. If there are memory
allocations outside of the region covered by the HOB List then Gcd could
select that region for memory which can result in the memory allocation
to not be handled and memory overwrites.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3028
The FirmwareVolume2Protocol->GetNextFile() produced by DXE Core can be used
to search for a file based on the value of *FileType input. However, this
service will always return EFI_NOT_FOUND if the input FileType is set to
EFI_FV_FILETYPE_MM_STANDALONE or EFI_FV_FILETYPE_MM_CORE_STANDALONE, Which
means user can't use this service to search any standalone MM image in that
FV.
This patch update the FirmwareVolume2Protocol->GetNextFile() service to
support searching standalone MM module.
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
OSs are now capable of treating SP and CRYPTO memory as true capabilities
and therefore these should be exposed. This requires usage of a separate
ACCESS_MASK to hide all page-access permission capabilities.
Change in masking and hiding of SP and CRYPTO was introduced in
3bd5c994c8
Signed-off-by: Malgorzata Kukiello <jacek.kukiello@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Oleksiy Yakovlev <oleksiyy@ami.com>
Cc: Ard Biesheuvel (ARM address) <ard.biesheuvel@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
GHCB pages must be mapped as shared pages, so modify the process of
creating identity mapped pagetable entries so that GHCB entries are
created without the encryption bit set. The GHCB range consists of
two pages per CPU, the first being the GHCB and the second being a
per-CPU variable page. Only the GHCB page is mapped as shared.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614
When we allocate pool to save the rebased PEIMs, the address will change
randomly, therefore the hash will change and result PCR0 change as well.
To avoid this, we save the raw PEIMs and use it to calculate hash.
The MigratedFvInfo HOB will never produce when
PcdMigrateTemporaryRamFirmwareVolumes is FALSE, because the PCD control
the total feature.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Harry Han <harry.han@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Guomin Jiang <guomin.jiang@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1614
Introduces new changes to PeiCore to move the contents of temporary
RAM visible to the PeiCore to permanent memory. This expands on
pre-existing shadowing support in the PeiCore to perform the following
additional actions:
1. Migrate pointers in PPIs installed in PeiCore to the permanent
memory copy of PeiCore.
2. Copy all installed firmware volumes to permanent memory.
3. Relocate and fix up the PEIMs within the firmware volumes.
4. Convert all PPIs into the migrated firmware volume to the corresponding
PPI address in the permanent memory location.
This applies to PPIs and PEI notifications.
5. Convert all status code callbacks in the migrated firmware volume to
the corresponding address in the permanent memory location.
6. Update the FV HOB to the corresponding firmware volume in permanent
memory.
7. Use PcdMigrateTemporaryRamFirmwareVolumes to control if enable the
feature or not. when disable the PCD, the EvacuateTempRam() will
never be called.
The function control flow as below:
PeiCore()
DumpPpiList()
EvacuateTempRam()
ConvertPeiCorePpiPointers()
ConvertPpiPointersFv()
MigratePeimsInFv()
MigratePeim()
PeiGetPe32Data()
LoadAndRelocatePeCoffImageInPlace()
MigrateSecModulesInFv()
ConvertPpiPointersFv()
ConvertStatusCodeCallbacks()
ConvertFvHob()
RemoveFvHobsInTemporaryMemory()
DumpPpiList()
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Debkumar De <debkumar.de@intel.com>
Cc: Harry Han <harry.han@intel.com>
Cc: Catharine West <catharine.west@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The MM communicate 2 protocol was introduced to factor out the mismatch
between traditional MM, which requires the physical address of the MM
buffer to be passed, and standalone MM, which copies the MM communicate
buffer data into a separate buffer, requiring the virtual address. For
this reason, MM communicate 2 carries both addresses, allowing the
implementation to decide which address it needs.
This hides this implementation detail from the callers of the protocol,
which simply passes both addresses without having to reason about what the
implementation of the protocol actually needs.
Note that the old version of the protocol is retained, in order to support
existing implementations that don't require this flexibility.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The memory attributes table handling code shared some parts of the
properties table handling code when it was introduced. The latter has
been dropped, and so we can merge the remaining pieces into the former.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
This is the minimal change required to stop exposing the EFI properties
table, which is deprecated. Given how the implementation is entangled
with the code that exposes the related memory attributes table, most of
the code is retained, and further cleanups are relegated to subsequent
patches.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
In the CoreStartImage() function [MdeModulePkg/Core/Dxe/Image/Image.c], if
the image entry point returns a failure code, then the DXE Core logs a
helpful DEBUG_ERROR message, with the following format string:
"Error: Image at %11p start failed: %r\n"
Do similarly in the SMM Core (update the message slightly).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Michael Kubacki
Ard Biesheuvel
Andrei Warkentin
Min M Xu
Dionna Glaze
Miki Demeter
Chao Li
Dun Tan
Liu, Zhiguang
Stacy Howell
Ray Ni
Kun Qin
Lou, Yun
Gerd Hoffmann
Michael D Kinney
Hua Ma
Marvin H?user
Yang Gang
Rebecca Cran
Vitaly Cheptsov
Laszlo Ersek
Jeff Brasen
Siyuan Fu
Malgorzata Kukiello
Tom Lendacky
Guomin Jiang
Michael Kubacki
Oleksiy Yakovlev
Ard Biesheuvel
Abner Chang