In theory it would be possible for a program in non-secure world to train the branch predictor to trick the secure monitor to speculatively read secure memory and as a consequence of that leak information to the cache that can be observed by a less privileged process. To exploit this an attacker needs to find a gadget that can be used as a trampoline to get access kernel memory (from a Trusted Application for example). The mitigation here is to invalidate the branch predictor when: - Going from non-secure to the secure environment. - When doing syscall from S-EL0 to S-EL1. Patches - For Armv8-A builds we are typically running OP-TEE with Trusted Firmware A, patches can be found here: - trusted-firmware-a.git - PR#1214: Workarounds for CVE-2017-5715 on Cortex A57/A72/A73 and A75 - For builds where we are not using TF-A (typically Armv7-A builds) we have implemented mitigations that can be found here: - optee_os.git - PR#2047: core: arm32: sm: invalidate branch predictor - PR#2065: Secure monitor spectre updates - For SVC calls, we have mitigation patches here: - optee_os.git - PR#2055: Cve 2017 5715 2 (Armv7-A, AArch32) - PR#2072: CVE-2017-5715 AArch64 (AArch64) - PR#2229: SMCCC_ARCH_WORKAROUND_1 (AArch64) Workarounds N/A References All details about the attacks has been thoroughly described in the whitepapers that can found at the Meltdown and Spectre page. A blog post (Implications of Meltdown and Spectre : Part 1) is also available on the Linaro website. OP-TEE ID OP-TEE-2018-0002 Reported by - Google Project Zero - University of Pennsylvania - University of Maryland - Rambus - Graz University of Technology - University of Adelaide - Data61 For more information For more information regarding the security incident process in OP-TEE, please read the information that can be found when going to the "Security" page at https://www.trustedfirmware.org.