Using Depex for Standalone MM drivers on ARM

Using Depex for Standalone MM drivers on ARM

[Kun Qin]

Hi all,

We found an issue a while back on ARM systems, where the Standalone MM
drivers with Depex specified will run into a hang when TFA hands off to
Standalone MM core. (https://bugzilla.tianocore.org/show_bug.cgi?id=3883)

After some debugging, the logic in the ticket still seems to be true
until today:

1. The UEFI Standalone MM partition needs to setup Standalone MM core to
be branched off that the beginning of this FV by manipulating the build
rules. Example:
https://github.com/tianocore/edk2-platforms/blob/93a71a67fd80bbc5baf0708ba75e73696b4a1c67/Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf#LL88C1-L89C1

2. During build time, the MM partition was initialized to code pages
through `ARM_SP_IMAGE_MMAP` as part of `plat_arm_mmap` see here:
https://github.com/ARM-software/arm-trusted-firmware/blob/a0f3b552cfa45258099170c83f79619b2dbd7b9b/include/plat/arm/common/arm_spm_def.h#LL36C11-L36C11,
which was later used for initial setup.

3. During BL31 setup step, the EL1 jump point will be updated to
`sp_image_base` from `plat_get_secure_partition_boot_info`:
https://github.com/ARM-software/arm-trusted-firmware/blob/a0f3b552cfa45258099170c83f79619b2dbd7b9b/services/std_svc/spm/spm_mm/spm_mm_setup.c#LL45C29-L45C42
which was initialized to `ARM_SP_IMAGE_BASE`.

4. After demoting to Secure EL1, the FD will first branch off to
standalone core entrypoint:
https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/StandaloneMmCoreEntryPoint.c#L319.
Standalone core entrypoint will execute in place of FV for the first few
lines. Then the core will locate itself in reported buffer SpImageBase
(which is also the FV image buffer location) and update the page
attribute accordingly
(https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/StandaloneMmCoreEntryPoint.c#LL386C12-L386C48).

5. The FV image buffer location (SpImageBase from UEFI, sp_image_base
from tf-a) is then published as an FV hob for further dispatches
(https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/Arm/CreateHobList.c#LL84C1-L84C75),
which was then used for Depex tracking/evaluation during driver discovery
and dispatching process in
https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Core/StandaloneMmCore.c#L646.

6. Depex discovered from FV during this process is cached in the
DriverEntry structure as pointers and added to the mDiscoveredList in
https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Core/Dispatcher.c#L864

7. Later during Standalone MM dispatching, this Depex pointer will be
updated in place:
https://github.com/tianocore/edk2/blob/ded0b489af09cde5afa05d74acdb12cd4b4f8394/StandaloneMmPkg/Core/Dependency.c#LL256C14-L256C14,
which causes memory violation as we are writing to the code pages.

Could you please let me know if there is anything I missed on this path?

To resolve this issue, I think any one of the following changes
could be considered:

1. Updating the incoming FV region to be Data pages, in TF-A;
2. Copying this incoming region to a separate data buffer;
3. Allocating designated copy pools for Depex sections during dispatching
(and free them once done).

We could work around this by compressing the FV, but I think we should
still fix the issue, correct?

Any thoughts or suggestions on this would be appreciated.

Regards,
Kun