Check that the next map entry is valid before dereferencing to merge the
guard pages. If the final entry is at the end of a page with no valid page
following it, then this can cause an access violation.
Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
Comments out a redundant call to RestoreTpl(). While this does not
technically violate spec on raise/restore TPL, TPL should already be at
the specified level. This extra call introduces an asymmetry between
RaiseTpl and RestoreTpl calls, which makes analysis of TPL correctness
more difficult and hampers certain non-standard TPL usages that some
platforms require. Additionally, the two TPL variables were renamed to
provide context for each of them.
Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
REF : https://bugzilla.tianocore.org/show_bug.cgi?id=4817
Before entering BIOS setup, CoreValidateHandle function executed
over 600,000 times during BDS phase on latest 8S server platform.
In CoreValidateHandle function, current implementation will go
through the doubly-linked list handle database in each call, and
this will have big impact on boot performance.
The optimization is using Red-black tree to store the EFI handle
address when insert each EFI handle into the handle database, and
remove the handle from Red-black tree if the handle is removed
from the handle database. CoreValidateHandle function changed to
go through the Red-black tree.
After verification on latest 8S server platform, BDS boot time can
save 20s+ after this change.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Andrew Fish <afish@apple.com>
Tested-by: Xiaoqiang Zhang <xiaoqiang.zhang@intel.com>
Currently whenever gDS->SetMemorySpaceCapabilities() is called, it
attempts to set the corresponding attributes in the gMemoryMap
descriptor. However, gMemoryMap only contains entries from GCD types
EfiGcdMemoryTypeSystemMemory and EfiGcdMemoryTypeMoreReliable, so
for all other types a failure is reported in the code. This is a
failure that is expected, so it does not provide value and can
lead to real failures being ignored.
This patch updates the gDS->SetMemorySpaceCapabilities() code to
only call into updating gMemoryMap if the GCD type is SystemMemory
or MoreReliable, to avoid spurious errors being reported. This
also avoids the expensive operation of searching through gMemoryMap
for entries we know we will fail to find.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Per UEFI spec 2.10 section 4.6.3 EFI_MEMORY_ATTRIBUTES_TABLE,
"The Memory Attributes Table is currently used to describe memory
protections that may be applied to the EFI Runtime code and data
by an operating system or hypervisor. Consumers of this table must
currently ignore entries containing any values for Type except for
EfiRuntimeServicesData and EfiRuntimeServicesCode to ensure
compatibility with future uses of this table."
However, the current MAT code also enforces attributes for
EfiMemoryMappedIo and EfiMemoryMappedIoPortSpace, which it should
not be. Per
https://edk2.groups.io/g/devel/topic/patch_v1_mdemodulepkg/105570114?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105570114,
it was suggested to remove these types from the MAT logic.
This patch removes EfiMemoryMappedIo and EfiMemoryMappedIoPortSpace
from the MAT logic in accordance with the UEFI spec.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
REF : https://bugzilla.tianocore.org/show_bug.cgi?id=4750
Migrate the FV that doesn't contain the currently executing PEI Core
when permanent memory is initialized but PEI Core is still potentially
running from faster memory (Tepmorary RAM). This may reduce the time
required to migrate FVs to permanent memory. The FV containing PEI
Core is migrated after the PEI Core reentry when it is executed from
permanent memory.
This may or may not improve performance depending on the behavior of
temporary RAM and the actual performance changes must be measured with
the feature enabled and disabled.
This migration algorithm is only used for FVs specified in the
gEdkiiMigrationInfoGuid HOB and built with flag
FLAGS_FV_MIGRATE_BEFORE_PEI_CORE_REENTRY.
Signed-off-by: Awiral Shrivastava <awiral.shrivastava@intel.com>
Now that all of the EFI_MEMORY_* defines live in the
EFI_MEMORY_TYPE enum, remove the old defines.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2411
With Use-After-Free heap guard feature enabled, the DxeCore would blindly
attempt to "level-up" when the `GuardAllFreedPages` inspect a non-max
level table entry from the last loop. This could cause the next round of
inspection to dereference a potentially null pointer and as such causing
a page fault.
This change adds a null pointer check to prevent such case from happening.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Kun Qin <kun.qin@microsoft.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4653
In DxeIplFindDxeCore function, there exists different behavior between
Debug and Release built BIOS. This change is used to unify both of
the code flow and fix the potential overflow of "Instance" variable.
In this change,
[1] Move the ASSERT_EFI_ERROR (Status) in failure to find DxeCore
in any firmware volume condition.
[2] Break the while-loop when not found required DxeCore.
This would make the Instance variable not overflow in while-loop.
[3] Add the CpuDeadLoop () in the end of the function and do not
return since DxeCore is mandatory for the following booting
to hand-off the PEI phase to DXE phase.
[4] In case of the CpuDeadLoop () is de-assert by debugger,
return the NULL pointer.
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
Removes an assert if PeiAllocatePool() fails to allocate memory to
defer error handling to the caller so the error can be handled
gracefully or asserted at that location which is more specific to
the call that led to the allocation.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
HBM/CXL memory systems are treated as special purpose memories. In many
cases it is desirable not to use special purpose memory for regular edk2
usages as these memories (HBm/CXL) are either meant for special purposes
or are less reliable to be used. Until such memory systems evolve and
we have better clarity from UEFI spec, avoid using them for edk2
boot memory purposes.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Oliver Smith-Denny <osde@linux.microsoft.com>
Signed-off-by: Dhaval Sharma <dhaval@rivosinc.com>
Co-authored-by: Tim Wawrzynczak <tim@rivosinc.com>
Add a new entry into GCD attribute conversion table to convert
EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE to EFI_MEMORY_SP.
Signed-off-by: Du Lin <du.lin@intel.com>
The local variable 'WillReturn' was being used without prior
initialization in some code paths.
This patch ensures that 'WillReturn' is properly initialized
to prevent undefined behavior.
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
This patch fix a use-after-free issue where unregistering an
SMI handler could lead to the deletion of the SMI_HANDLER while it is
still in use by SmiManage(). The fix involves modifying
SmiHandlerUnRegister() to detect whether it is being called from
within the SmiManage() stack. If so, the removal of the SMI_HANDLER
is deferred until SmiManage() has finished executing.
Additionally, due to the possibility of recursive SmiManage() calls,
the unregistration and subsequent removal of the SMI_HANDLER are
ensured to occur only after the outermost SmiManage() invocation has
completed.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
The functionality to create and delete Image Records has been
consolidated in a library and ensured that MemoryProtection.c's
usage is encapsulated there.
This patch moves MemoryProtection.c to reuse the code in the lib
and to prevent issues in the future where code is updated in one
place but not the other.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Taylor Beebe <taylor.d.beebe@gmail.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Currently, there are multiple issues when page or pool guards are
allocated for runtime memory regions that are aligned to
non-EFI_PAGE_SIZE alignments. Multiple other issues have been fixed for
these same systems (notably ARM64 which has a 64k runtime page
allocation granularity) recently. The heap guard system is only built to
support 4k guard pages and 4k alignment.
Today, the address returned to a caller of AllocatePages will not be
aligned correctly to the runtime page allocation granularity, because
the heap guard system does not take non-4k alignment requirements into
consideration.
However, even with this bug fixed, the Memory Allocation Table cannot be
produced and an OS with a larger than 4k page granularity will not have
aligned memory regions because the guard pages are reported as part of
the same memory allocation. So what would have been, on an ARM64 system,
a 64k runtime memory allocation is actually a 72k memory allocation as
tracked by the Page.c code because the guard pages are tracked as part
of the same allocation. This is a core function of the current heap
guard architecture.
This could also be fixed with rearchitecting the heap guard system to
respect alignment requirements and shift the guard pages inside of the
outer rounded allocation or by having guard pages be the runtime
granularity. Both of these approaches have issues. In the former case,
we break UEFI spec 2.10 section 2.3.6 for AARCH64, which states that
each 64k page for runtime memory regions may not have mixed memory
attributes, which pushing the guard pages inside would create. In the
latter case, an immense amount of memory is wasted to support such large
guard pages, and with pool guard many systems could not support an
additional 128k allocation for all runtime memory.
The simpler and safer solution is to disallow page and pool guards for
runtime memory allocations for systems that have a runtime granularity
greater than the EFI_PAGE_SIZE (4k). The usefulness of such guards is
limited, as OSes do not map guard pages today, so there is only boot
time protection of these ranges. This also prevents other bugs from
being exposed by using guards for regions that have a non-4k alignment
requirement, as again, multiple have cropped up because the heap guard
system was not built to support it.
This patch adds both a static assert to ensure that either the runtime
granularity is the EFI_PAGE_SIZE or that the PCD bits are not set to
enable heap guard for runtime memory regions. It also adds a check in
the page and pool allocation system to ensure that at runtime we are not
allocating a runtime region and attempt to guard it (the PCDs are close
to being removed in favor of dynamic heap guard configurations).
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4674
Github PR: https://github.com/tianocore/edk2/pull/5382
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Per the UEFI spec 2.10, section 2.3.6 (for the AARCH64 arch, other
architectures in section two confirm the same) the memory types that
need runtime page allocation granularity are EfiReservedMemoryType,
EfiACPIMemoryNVS, EfiRuntimeServicesCode, and EfiRuntimeServicesData.
However, legacy code was setting runtime page allocation granularity for
EfiACPIReclaimMemory and not EfiReservedMemoryType. This patch fixes
that error.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Suggested-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
CodeQL flags the Free Pages logic for not ensuring that
Entry is non-null before using it. Add a check for this
and appropriately bail out if we hit this case.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
RuntimeDxe is used to back the runtime services time functions,
so align the description of the function return values with the
defined values for these services as described in UEFI Spec 2.10.
REF: UEFI spec 2.10 section 8 Services ? Runtime Services
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Suqiang Ren <suqiangx.ren@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
CoreConnectSingleController() searches for the Driver Family Override
Protocol drivers by looping and checking each Driver Binding Handles.
This loop can be skipped by checking if any Driver Family Override
Protocol installed in the platform first, to improve the performance.
Cc: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
CoreGetProtocolInterface() is called by CoreOpenProtocol(),
CoreCloseProtocol() and CoreOpenProtocolInformation().
Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input
parameter UserHandle has been already checked for validation. So does
CoreCloseProtocol().
Removing the handle validation check in CoreGetProtocolInterface()
could improve the performance, as CoreOpenProtocol() is called very
frequently.
To ensure the assumption that the caller of CoreGetProtocolInterface()
must pass in a valid UserHandle that is checked with CoreValidateHandle(),
add the parameter check in CoreOpenProtocolInformation(), and declare
CoreGetProtocolInterface() as static.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
Provide an optional method for PEI to declare a specific address
range to use for the Memory Type Information bins. The current
algorithm uses heuristics that tends to place the Memory Type
Information bins in the same location, but memory configuration
changes across boots or algorithm changes across a firmware
updates could potentially change the Memory Type Information bin
location. If the bin locations move across an S4 save/resume
cycle, then the S4 resume may fail. Enabling this feature
increases the number of scenarios that an S4 resume operation
may succeed.
If the HOB List contains a Resource Descriptor HOB that
describes tested system memory and has an Owner GUID of
gEfiMemoryTypeInformationGuid, then use the address range
described by the Resource Descriptor HOB as the preferred
location of the Memory Type Information bins. If this HOB is
not detected, then the current behavior is preserved.
The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
is ignored for the following conditions:
* The HOB with an Owner GUID of gEfiMemoryTypeInformationGuid
is smaller than the Memory Type Information bins.
* The HOB list contains more than one Resource Descriptor HOB
with an owner GUID of gEfiMemoryTypeInformationGuid.
* The Resource Descriptor HOB with an Owner GUID of
gEfiMemoryTypeInformationGuid is the same Resource Descriptor
HOB that that describes the PHIT memory range.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Aaron Li <aaron.li@intel.com>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4533
There are use cases which not all FVs need be migrated from TempRam to
permanent memory before TempRam tears down. This new guid is introduced
to avoid unnecessary FV migration to improve boot performance. Platform
can publish MigrationInfo hob with this guid to customize FV migration
info, and PeiCore will only migrate FVs indicated by this Hob info.
This is a backwards compatible change, PeiCore will check MigrationInfo
hob before migration. If MigrationInfo hobs exists, only migrate FVs
recorded by hobs. If MigrationInfo hobs not exists, migrate all FVs to
permanent memory.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Guomin Jiang <guomin.jiang@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Cheng Sun <chengx.sun@intel.com>
CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to
check if a Device Path Protocol instance with the same device path is
alreay installed.
CoreLocateDevicePath is a generic API, and would introduce some
unnecessary overhead for such usage.
The optimization is:
1. Implement IsDevicePathInstalled to loop all the Device Path
Protocols installed and check if any of them matchs the given device
path.
2. Replace CoreLocateDevicePath with IsDevicePathInstalled in
CoreInstallMultipleProtocolInterfaces.
This optimization could save several seconds in PCI enumeration on a
system with many PCI devices.
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: Zhi Jin <zhi.jin@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|4K PAGE|DATA|CODE|DATA|CODE|DATA|4K PAGE|
Say the above memory region is currently one memory map descriptor.
The above image memory layout example contains two code sections
oriented in a way that maximizes the number of descriptors which
would be required to describe each section.
NOTE: It's unlikely that a data section would ever be between
two code sections, but it's still handled by the below formula
for correctness.
There are two code sections (let's say CodeSegmentMax == 2),
three data sections, and two unrelated memory regions flanking the
image. The number of required descriptors to describe this layout
will be 2 * 2 + 3 == 7. This patch updates the calculations to account
for the worst-case scenario.
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: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Add PCD to control if modules with start addresses in PE/COFF > 0x100000
attempt to load at specified address.
If a module has an address in this range and there is untested memory
DxeCore will attempt to promote all memory to tested which bypasses any
memory testing that would occur later in boot.
There are several existing AARCH64 option roms that have base addresses
of 0x180000000.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
Message-Id: <bd36c9c24158590db2226ede05cb8c2f50c93a37.1684194452.git.jbrasen@nvidia.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
When finding a free page range for allocation, if the found range
starts below the tracked memory bin address range, the lowest
memory bin address is updated which will not include the guard page if
present. When CoreConvertPagesWithGuard() is called on the range
being allocated, the memory range is adjusted to include guard
pages which can push it out of the memory bin address range and
cause the memory type statistics to be unaltered.
This patch updates the lowest memory bin address range to account for
the guard page if NeedGuard is TRUE so the memory type statistics
are updated correctly.
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: Taylor Beebe <t@taylorbeebe.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
