Added SpiHc DXE and SMM drivers. This code receives bus transactions
from the SpiBus layer and passes them onto the SpiHcPlatformLib
Platform Initialization Spec 1.7 volume 5 section 18.1.7
Bugzilla #4753
Cc: Abner Chang <abner.chang@amd.com>
Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Signed-off-by: Brit Chesley <brit.chesley@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.com>
Adding NULL SpiHcPlatformLib instance. This library is responsible for
handling the low level details of the SPI host controller. Since this is
platform specific this library will be dependent on OEM SPI
implementation. The SPI host controller layer will utilize this library
for SPI bus transactions.
Bugzilla #4753
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Signed-off-by: Brit Chesley <brit.chesley@amd.com>
Acked-by: Abner Chang <abner.chang@amd.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Added SpiBus DXE and SMM drivers. This code translates SPI requests from
the application layer into SPI Bus transactions on the SPI host
controller. The code is responsible for checking if the transaction is
valid, then setting up the SPI clock and chip select properly before
passing the bus transaction to the host controller.
Platform Initialization Spec 1.7 volume 5 section 18.1.6
Bugzilla #4753
Cc: Abner Chang <abner.chang@amd.com>
Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Signed-off-by: Brit Chesley <brit.chesley@amd.com>
Reviewed-by: Abner Chang <abner.chang@amd.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>
UEFI spec defined ACPI Tables at boot time can be contained in memory of
type EfiACPIReclaimMemory or EfiAcpiMemoryNVS, although InstallAcpiTable
with AcpiTableProtocol will only allocate memory with type
EfiACPIReclaimMemory (Except FACS).
This patch provides an optional method controlled by PCD to avoid using
EfiACPIReclaimMemory, by setting the PCD PcdNoACPIReclaimMemory to TRUE,
all ACPI allocated memory will use EfiAcpiMemoryNVS instead.
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Liu Yun <yun.y.liu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Aaron Li <aaron.li@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-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 instances of code create image
records. ImagePropertiesRecordLib was created to only have
this code in one place. Update the lib to use additional
logic from the copy in MemoryProtection.c before converging
that code to use the lib.
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>
When an ImageRecord is stored by ImagePropertiesRecordLib, it reports the
CodeSegmentSize as the SizeOfRawData from the image. However, the image
as loaded into memory is aligned to the SectionAlignment, so
SizeOfRawData is under the actual size in memory. This is important,
because the memory attributes table uses these image records to create
its entries and it will report that the alignment of an image is
incorrect, even though the actual image is correct.
This was discovered on ARM64, which has a 64k runtime page granularity
alignment, which is backed by a 64k section alignment for
DXE_RUNTIME_DRIVERs. The runtime code and data was correctly being
loaded into memory, however the memory attribute table was incorrectly
reporting misaligned ranges to the OS, causing attributes to be
ignored for these sections for OSes using greater than 4k pages.
This patch correctly aligns the CodeSegmentSize to the SectionAlignment
and the corresponding memory attribute table entries are now correctly
aligned and pointing to the right places in memory.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
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>
Reviewed-by: Marvin H?user <mhaeuser@posteo.de>
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>
AtaBusDxe, NvmExpressDxe, ScsiDiskDxe and EmmcDxe is used to back the
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL, update the parameter 'MediaId'
description for the protocol function ReceiveData and SendData as
described in UEFI Spec 2.10 section 13.14.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Qingyu Shang <qingyu.shang@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Resolves a new CodeQL error due to the value being incremented in the
loop being a narrower type than the variable it is being compared
against.
The variable is changed to a UINT32 type so it has the same width as
the type it is being compared against.
Issue explanation: In a loop condition, comparison of a value of a
narrow type with a value of a wide type may result in unexpected
behavior if the wider value is sufficiently large (or small). This
is because the narrower value may overflow. This can lead to an
infinite loop.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Gua Guo <gua.guo@intel.com>
Cc: Prakashan Krishnadas Veliyathuparambil <krishnadas.veliyathuparambil.prakashan@intel.com>
Cc: K N Karthik <karthik.k.n@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Gua Guo <gua.guo@intel.com>
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: UEFI_Spec_2_10_Aug29.pdf page 1695.
In 35.5.4 EFI_HII_CONFIG_ACCESS_PROTOCOL.CallBack():
If the callback function returns with the ActionRequest set to
_QUESTION_APPLY, then the Forms Browser will write the current modified
question value on the selected form to storage.
Update the DriverSampleDxe, add a new question "Question apply test".
Signed-off-by: Ming Tan <ming.tan@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: UEFI_Spec_2_10_Aug29.pdf page 1695.
In 35.5.4 EFI_HII_CONFIG_ACCESS_PROTOCOL.CallBack():
If the callback function returns with the ActionRequest set to
_QUESTION_APPLY, then the Forms Browser will write the current modified
question value on the selected form to storage.
Update the SetupBrowserDxe, if callback function return
EFI_BROWSER_ACTION_REQUEST_QUESTION_APPLY, then call SetQuestionValue
with GetSetValueWithHiiDriver to apply the change immediately.
Signed-off-by: Ming Tan <ming.tan@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
ResetSystem runtime call allows for sending reset data that
starts with a NULL terminated string. Add support to print
that string on console.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
This patch is to use the Context to indicate SMM Debug Agent support or
not if InitFlag is DEBUG_AGENT_INIT_SMM. Context must point to a
BOOLEAN if it's not NULL.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@Intel.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>
Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
However, the introduction of Platform Recovery in UEFI 2.5 makes it
necessary to signal ReadyToBoot when a Platform Recovery boot loader
runs because otherwise it may lead to the execution of a boot loader
that has similar requirements to a regular one that is not launched
as a Boot Manager option.
This is especially critical to ensuring that the graphical console is
actually usable during platform recovery, as some platforms do rely on
the ConsolePrefDxe driver, which only performs console initialization
after ReadyToBoot is triggered.
This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
in EfiBootManagerProcessLoadOption () when invoking platform recovery,
which is the function that sets up the platform recovery boot process.
The expected behavior has been clarified in the UEFI 2.10 specification
to explicitly indicate this behavior is required for correct operation.
This is a rebased version of the patch originally written by Pete Batard.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831
Co-authored-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Neal Gompa <ngompa@fedoraproject.org>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The DXE & MM standalone variant of AcpiTimerLib defines a global
named mPerformanceCounterFrequency. A global with an identical
name is also present in MdeModulePkg/Bus/Pci/XhciDxe/Xhci.c
Since XhciDxe has a dependency on TimerLib, this can cause link
errors due to the same symbol being defined twice if the platform
DSC chooses to use AcpiTimerLib as the TimerLib implementation for
any given platform.
To resolve this, I noted that some of the globals in Xhci.c are not
used outside of the Xhci.c compilation unit:
- mPerformanceCounterStartValue
- mPerformanceCounterEndValue
- mPerformanceCounterFrequency
- mPerformanceCounterValuesCached
I have changed the definition for all of these to static and added
an Xhci prefix. Since they are not used outside of the Xhci.c
compilation unit, there is no reason to have them exported as
globals.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@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>
