Makes changes to comply with alerts raised by CodeQL.
Most of the issues here fall into the following two categories:
1. Potential use of uninitialized pointer
2. Inconsistent integer width used in loop comparison
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
If a Memory Allocation Hob with EfiBootServicesData memory type is
reported into MM Hob List and it also has a non-zero GUID name, then the
HOB is used by MM driver and needs to migrate the memory into MMRAM.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
The MM memory attribute table is ported from SMM Core.
The new file StandaloneMmPkg/Core/MemoryAttributesTable.c, the new code
in StandaloneMmPkg/Core/Page.c and StandaloneMmPkg/Core/Pool.c are
almost identical to MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c,
MdeModulePkg/Core/PiSmmCore/Page.c and
MdeModulePkg/Core/PiSmmCore/Pool.c, but changing the word 'SMM' to 'MM'.
Different from SMM Core, Standalone MM Core produces MM MemoryAttributes
table at the end of MmDriverDispatchHandler() when all the drivers are
dispatched, rather than at the MmEndOfDxe event.
Then the MM CPU driver will consumes the table to set memory attribute
in page table.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
When the EndOfPei event is signaled, installs the MM EndOfPei Protocol
so MM Drivers are informed that EndOfPei event is signaled.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Add the support using gEfiSmmSmramMemoryGuid to get MMRAM ranges.
If gEfiSmmSmramMemoryGuid HOB is not found, then try to get MMRAM ranges
from gEfiMmPeiMmramMemoryReserveGuid HOB.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Defer the dispatch of the remaining MM drivers once the CPU driver has
been dispatched.
In MmDispatcher, return immediately if the MM Entry Point was registered.
Then the MM IPL will reinvoke the MM Core Dispatcher. This is required
so MM Mode may be enabled as soon as all the dependent MM Drivers for MM
Mode have been dispatched.
Introduce a FeatureFlag PCD to control if MmDispatcher returns or not
when MmEntryPointPoint is registered. Default value is FALSE.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
mMmramRanges and mMmramRangeCount are the global variables that are
used to cache the MMRAM Ranges info, but they are not used in MM Core.
Therefore, remove mMmramRanges and mMmramRangeCount.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
MM_CORE_PRIVATE_DATA is not used as shared structures between MM IPL
and MM Core, therefore clean up the code related to gMmCorePrivate.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Get the MM Communication context from the MM Communication Buffer,
instead of the pointer inside gMmCorePrivate.
In the MmEntryPoint, check IsCommBufferValid from MM_COMM_BUFFER to
decide whether the MMI is Synchronous MMI or Asynchronous MMI. If it
is a Synchronous MMI, MM Core shadows the communication buffer into
a internal copy, then invokes the MMI handlers, lastly copies data
back to the MM Communication Buffer and set the return status.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Switch to MM HobList as soon as MM HostList is initialized to avoid
StandaloneMmCore still using the HobList which is outside of MMRAM.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Retrieves the MM Core image info from Memory Allocation HOB reported
by MM IPL. Then install Loaded Image Protocol for MM Core with the
image info from HOB.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Install Loaded Image Protocol into MM handle database for each MM
driver.
Change EFI_MM_DRIVER_ENTRY structure definition to hold the Loaded
Image Protocol data directly, instead a pointer to the protocol, to
avoid allocating pool for each MM driver.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
StandaloneMmCore should not support dispatching traditional MM
driver which has dependency on UEFI services. Therefore, remove
the related code that supports traditional MM driver.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Print HOB information at top of StandaloneMmMain().
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@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
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>
In last patch, we add code support to unregister MMI handler inside
itself. However, the code doesn't support unregister MMI handler
insider other MMI handler. While this is not a must-have usage.
So add check to disallow unregister MMI handler in other MMI handler.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: 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>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
Message-Id: <20240301030133.628-5-zhiguang.liu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
To support unregister MMI handler inside MMI handler itself,
get next node before MMI handler is executed, since LIST_ENTRY that
Link points to may be freed if unregister MMI handler in MMI handler
itself.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: 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>
Message-Id: <20240301030133.628-4-zhiguang.liu@intel.com>
Currently, if a MMI handler returns an unexpected failure status code,
ASSERT (FALSE) is used. It is more useful to use ASSERT_EFI_ERROR()
which also outputs the status code value.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The current dependency evaluator violates the memory access permission
when patching depex grammar directly in the read-only depex memory area.
Laszlo pointed out the optimization issue in the thread (1) "Memory
Attribute for depex section" and provided suggested patch to remove the
perf optimization.
In my testing, removing the optimization does not make significant perf
reduction. That makes sense that StandaloneMM dispatcher only searches
in MM protocol database and does not depend on UEFI/DXE protocol
database. Also, we don't have many protocols in StandaloneMM like
UEFI/DXE.
From Laszlo,
"The patch removes the EFI_DEP_REPLACE_TRUE handling altogether, plus it
CONST-ifies the Iterator pointer (which points into the DEPEX section),
so that the compiler catch any possible accesses at *build time* that
would write to the write-protected DEPEX memory area."
(1) https://edk2.groups.io/g/devel/message/113531
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Tested-by: levi.yun <yeoreum.yun@arm.com>
Reviewed-by: levi.yun <yeoreum.yun@arm.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Load-module-at-fixed-address feature does not work in standalone MM core.
The patch removes the 2 dead functions and related global variables
that are related to the feature.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
The MmCoreFfsFindMmDriver only checks for encapsulated compressed FVs.
When an inner FV is uncompressed, StandaloneMmCore will miss the FV and
all the MM drivers in the FV will not be dispatched.
Add checks for uncompressed inner FV to fix this issue.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MmCoreFfsFindMmDriver() assumes FileHeader is EFI_FFS_FILE_HEADER.
If FileHeader is an EFI_FFS_FILE_HEADER2, 'FileHeader + 1' will get a
wrong section address. Use FfsFindSection to get the section directly,
instead of 'FileHeader + 1' to avoid this issue.
MmCoreFfsFindMmDriver() also assumes section is EFI_COMMON_SECTION_HEADER.
If Section is EFI_COMMON_SECTION_HEADER2, 'Section + 1' will get a wrong
wrong InnerFvHeader adress. Add section head detection and calculate the
address accordingly.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In MmCoreFfsFindMmDriver(),
- ScratchBuffer is not freed in the error return path that DstBuffer page
allocation fails. Free ScratchBuffer before return with error.
- If the decoded buffer is identical to the data in InputSection,
ExtractGuidedSectionDecode() will change the value of DstBuffer rather
than changing the contents of the buffer that DstBuffer points at, in
which case freeing DstBuffer is wrong. Introduce a local variable
AllocatedDstBuffer for buffer free, free AllocatedDstBuffer immediately
if it is not used.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MmCoreFfsFindMmDriver() 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 MmCoreFfsFindMmDriver()
track the section nesting depth against that PCD.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the StandaloneMmPkg 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: Sami Mujawar <sami.mujawar@arm.com>
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: Sami Mujawar <sami.mujawar@arm.com>
Currently, the flag "-fpie" is passed for all builds with a GCC
family toolchain, including CLANGPDB. CLANGPDB however does not
support this flag as it generates PE/COFF files directly.
As the flag is mostly required for ARM-specific self-relocation, drop
it for other architectures and document the limitation to enable e.g.
X64 CLANGPDB builds of StandaloneMmCore.
Signed-off-by: Marvin Häuser <mhaeuser@posteo.de>
Acked-by: Shi Steven <steven.shi@intel.com>
This change allows to build StandaloneMmPkg components for 32bit Arm
StandaloneMm firmware.
This change mainly moves AArch64/ source files to Arm/ side directory
for several components: StandaloneMmCpu, StandaloneMmCoreEntryPoint
and StandaloneMmMemLib. The source file is built for both 32b and 64b
Arm targets.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3445
This change fixed a misspelling that was not caught by spell check.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3204
Fixes the following compiler warning in VS2019 by changing defining
the MmramRangeCount variable to be UINTN and type casting prior
to value assignment.
\edk2\StandaloneMmPkg\Core\StandaloneMmCore.c(570): error C2220:
the following warning is treated as an error
\edk2\StandaloneMmPkg\Core\StandaloneMmCore.c(570): warning C4244:
'=': conversion from 'UINT64' to 'UINT32', possible loss of data
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Bugzilla: 3150 (https://bugzilla.tianocore.org/show_bug.cgi?id=3150)
Add doxygen style function documentation headers to fix the ECC
reported errors:
- [4002] Function header doesn't exist.
- [9002] The function headers should follow Doxygen special
documentation blocks in section 2.3.5.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3150 (https://bugzilla.tianocore.org/show_bug.cgi?id=3150)
Fix ECC error "[5007] There should be no initialization of a variable
as part of its declaration Variable."
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3150 (https://bugzilla.tianocore.org/show_bug.cgi?id=3150)
Fix the following error reported by the Ecc tool:
[1001] 'TAB' character is not allowed in source code, please
replace each 'TAB' with two spaces.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3150 (https://bugzilla.tianocore.org/show_bug.cgi?id=3150)
Fix the ECC reported error "[9002] The function headers should follow
Doxygen special documentation blocks in section 2.3.5 in Comment"
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3150 (https://bugzilla.tianocore.org/show_bug.cgi?id=3150)
Fix the spelling mistakes reported by the spell check utility
that is run as part of the Core CI.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
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.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The Standalone core uses gEfiHobMemoryAllocModuleGuid, but failed to
declare this in its INF.
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>
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>
Update the reference to MM communicate to refer to the MM communicate 2
protocol instead. This makes no difference for the MM side of the
implementation, but is more accurate nonetheless, since the original MM
protocol does not work in combination with standalone MM.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Fix few typos in comments.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-76-philmd@redhat.com>
Fix a typo in a comment.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-75-philmd@redhat.com>
An extra 's' slipped into the FvIsBeingProcessed function
name. Drop it to fix the typo.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
that every firmware volume is processed only once (every driver in every
firmware volume should be discovered only once). For this, the functions
use a linked list.
In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
those firmware volumes that have been processed is the EFI_HANDLE on which
the DXE or SMM firmware volume protocol is installed. In the
StandaloneMmPkg core however, the key is the address of the firmware
volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
(EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
EFI_HANDLE just happens to be specified as (VOID*), and therefore the
conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
(The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
conversion.)
We should not exploit this circumstance. Represent the key type faithfully
instead.
This is a semantic fix; there is no change in operation.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Michael Kubacki
Wei6 Xu
Zhiguang Liu
Laszlo Ersek
Ray Ni
Michael D Kinney
Marvin Häuser
Etienne Carriere
Sean Brogan
Sami Mujawar
Ard Biesheuvel
Antoine Coeur
Philippe Mathieu-Daudé
Ard Biesheuvel