I’m TF-A developer of MediaTek and have a situation of CVE patch (https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298) with CA73. In CA73 platform with 64-bit TF-A v2.4 and 64-bit OP-TEE v3.16, system will occur halt during boot flow after we applied fix(security): apply SMCCC_ARCH_WORKAROUND_3 to A73/A75/A72/A57https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298. We used ICE to trace boot flow step by step, and found S-EL1 will ask EL3 its SMC_VERSION. In the fastcall, TF-A will execute wa_cve_2017_5715_bpiall_vbar()https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298/11/lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S#18 which back up some setting and switch processor from AArch-64 to AArch-32 and does BPIALLhttps://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/14298/11/lib/cpus/aarch64/wa_cve_2017_5715_bpiall.S#113. But AArch32 cannot access and run over than 4G bus address without LPAE. (Suppose the TF-A and OP-TEE are locate on over than 4G bus address.)
Maybe can we replace AArch32_stub with IC IALLU ? Or add LPAE setting before do AArch32_stub? (I don’t know it make sense or not)
Hi, would it be possible to move the BL31 binary to a lower address so the aarch32 stub can run properly?
Hi~ Due to some reasons, it needs great effort to move the BL31 to lower address in our platform. Is there any other possible workaround to fix the issue for CA73?
Is there any better way to deal with this problem?