Re: [edk2-devel] Using Depex for Standalone MM drivers on ARM

["Kun Qin" <kuqin12@gmail.com>]

Forgot to add applicable maintainers earlier..

It would be great if StandaloneMmPkg maintainers could shed some light here.

Thanks,
Kun

On 6/6/2023 5:57 PM, Kun Qin via groups.io wrote:
> 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
>
>
>
> 
>
>