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>
Remove the support that permits calls into the MM context to dispatch
firmware volumes that are not part of the initial standalone MM firmware
volume.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Instead of deferring dispatch of the remaining MM drivers once the
CPU driver has been dispatched, proceed and dispatch all drivers.
This makes sense for standalone MM, since all dispatchable drivers
should be present in the initial firmware volume anyway: dispatch
of additional FVs originating in the non-secure side is not supported.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Standalone MM requires 4 KB section alignment for all images, so that
strict permissions can be applied. Unfortunately, this results in a
lot of wasted space, which is usually costly in the secure world
environment that standalone MM is expected to operate in.
So let's permit the standalone MM drivers (but not the core) to be
delivered in a compressed firmware volume.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
The dispatcher uses the PE/COFF loader to load images into the heap,
but only does so after copying the entire image first, leading to
two copies being made for no good reason.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Management Mode (MM) is a generic term used to describe a secure
execution environment provided by the CPU and related silicon that is
entered when the CPU detects a MMI. For x86 systems, this can be
implemented with System Management Mode (SMM). For ARM systems, this can
be implemented with TrustZone (TZ).
A MMI can be a CPU instruction or interrupt. Upon detection of a MMI, a
CPU will jump to the MM Entry Point and save some portion of its state
(the "save state") such that execution can be resumed.
The MMI can be generated synchronously by software or asynchronously by
a hardware event. Each MMI source can be detected, cleared and disabled.
Some systems provide for special memory (Management Mode RAM or MMRAM)
which is set aside for software running in MM. Usually the MMRAM is
hidden during normal CPU execution, but this is not required. Usually,
after MMRAM is hidden it cannot be exposed until the next system reset.
The MM Core Interface Specification describes three pieces of the PI
Management Mode architecture:
1. MM Dispatch
During DXE, the DXE Foundation works with the MM Foundation to
schedule MM drivers for execution in the discovered firmware volumes.
2. MM Initialization
MM related code opens MMRAM, creates the MMRAM memory map, and
launches the MM Foundation, which provides the necessary services to
launch MM-related drivers. Then, sometime before boot, MMRAM is
closed and locked. This piece may be completed during the
SEC, PEI or DXE phases.
3. MMI Management
When an MMI generated, the MM environment is created and then the MMI
sources are detected and MMI handlers called.
This patch implements the MM Core.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Mikhail Krichanov
Zhiguang Liu
Michael Kubacki
Laszlo Ersek
Ray Ni
Wei6 Xu
Michael D Kinney
Marvin Häuser
Etienne Carriere
Sean Brogan
Sami Mujawar
Ard Biesheuvel
Antoine Coeur
Philippe Mathieu-Daudé
Ard Biesheuvel
Supreeth Venkatesh