REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4736
In UEFI_Spec_2_10_Aug29.pdf page 1694 section 35.5.4 for
EFI_BROWSER_ACTION_FORM_OPEN:
NOTE: EFI_FORM_BROWSER2_PROTOCOL.BrowserCallback() cannot be used with
this browser action because question values have not been retrieved yet.
So should not call HiiGetBrowserData() and HiiSetBrowserData() in FORM_OPEN
call back function.
Now use wifi list key and enroll cert key instead of the connect action key,
move wifi info display from open action to close action.
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Felix Polyudov <Felixp@ami.com>
Signed-off-by: Liqi Liu <liqi.liu@intel.com>
Reviewed-by: Zachary Clark-williams <zachary.clark-williams@intel.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
On a multi-processor system, if the BSP dose not know how many APs are
online or cannot wake up the AP via broadcast, it can collect AP
resouces before wakeing up the AP and add a new HOB to save the
processor resouces.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This patch fix a use-after-free issue where unregistering an
MMI handler could lead to the deletion of the MMI_HANDLER while it is
still in use by MmiManage(). The fix involves modifying
MmiHandlerUnRegister() to detect whether it is being called from
within the MmiManage() stack. If so, the removal of the MMI_HANDLER
is deferred until MmiManage() has finished executing.
Additionally, due to the possibility of recursive MmiManage() calls,
the unregistration and subsequent removal of the MMI_HANDLER are
ensured to occur only after the outermost MmiManage() 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>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
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>
When collecting the required library instances for modules and
libraries, included libraries will be recursed to ensure the module is
built with all the libraries directly linked to it and indirectly
linked to it via included libraries.
Using the following scenario as an example:
[LibraryClasses.common.DXE_CORE]
NULL|Path/To/Library1.inf // Includes DebugLib
[LibraryClasses.common.DXE_DRIVER]
NULL|Path/To/Library2.inf // Includes DebugLib
[LibraryClasses.common.DXE_CORE, LibraryClasses.common.DXE_DRIVER]
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
[Components]
MdeModulePkg/Core/Dxe/DxeMain.inf // Includes DebugLib
The DXE_CORE NULL library will be assigned a fake library class like
NULL1 and the DXE_DRIVER will be assigned NULL2. The recursion logic
will see NULL1 as a directly linked and will add an instance of it to
the list of libraries which need to be included in the module. When
DebugLib is evaluated, the recursion logic will add the libraries
DebugLib depends on to the queue which includes both NULL1 and NULL2.
When NULL2 is unqueued, an instance of it will also be added to the
list of libraries needed to build DxeMain which now means that both
NULL1 and NULL2 have been linked.
NULL includes outside of module overrides are not supported according
to the spec, but we do it anyways so this seems like a case which
should be fixed. This change updates the recursion logic to skip
evaluating NULL libraries unless they are linked directly to the
module/library being evaluated.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Yuwei Chen <yuwei.chen@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4731
TCG2 configuration UI shows all the hash algorithms that TPM hardware
supports in the checkbox. If user only selects one algorithm that is
supported by TPM hardware but not supported by BIOS and uncheck the
others, the SyncPcrAllocationsAndPcrMask in Tcg2Pei will not be able
to decide a viable PCR to activate, then an assert occurs.
Add check against PcdTcg2HashAlgorithmBitmap when deciding whether
to suppress the hash algorithm checkbox to avoid user to select the
hash algorithm which may cause an assert.
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Rahul Kumar <rahul1.kumar@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4713
In UEFI_Spec_2_10_Aug29.pdf page 1694 section 35.5.4 for
EFI_BROWSER_ACTION_FORM_OPEN:
NOTE: EFI_FORM_BROWSER2_PROTOCOL.BrowserCallback() cannot be used with
this browser action because question values have not been retrieved yet.
So should not call HiiGetBrowserData() and HiiSetBrowserData() in FORM_OPEN
call back function.
Now call SecureBootExtractConfigFromVariable() and update
IfrNvData->ListCount to save the change to EFI variable, then HII use EFI
variable to control the UI.
Cc: Min Xu <min.m.xu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Felix Polyudov <Felixp@ami.com>
Signed-off-by: Ming Tan <ming.tan@intel.com>
Reviewed-by: Felix Polyudov <Felixp@ami.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
"MenuPath" is the attribute in BIOS attribute registry. To support
reporting this attribute, we need to include the formset without
x-uefi-redfish support in database. So driver can find menu path to
target attribute in BIOS menu.
Signed-off-by: Nickle Wang <nicklew@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
Add the condition check when delete HII string.
Only when the HiiStatement operand equal to "EFI_IFR_STRING_OP"
and the statement value type = EFI_IFR_TYPE_STRING.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Co-authored-by: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Reviewed-by: Nickle Wang <nicklew@nvidia.com>
Reviewed-by: Igor Kulchytskyy <igork@ami.com>
