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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#105826): https://edk2.groups.io/g/devel/message/105826 Mute This Topic: https://groups.io/mt/99376023/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
