jkrh
commented
3 years ago I verified this from a couple of systems and it appears that the EL3 programmers are awake. The EL3 does not map the memory in linear blocks over the entire RAM base, it only maps the regions it actually recognizes and uses. In other words, the only attack that I could think of to be possible should involve managing to declare a new trusted application area on top of the hypervisor. Writing over the hyp from any broken struct argument would not work as the areas are not mapped at all.
That said, this appears (to me) to be an EL3 configuration issue such that the TA application loads / saves only happen via exact landing pads.
EL3 Kernel (Trustzone and Secure Montor) has protections in place when it receives an SMC call so that non of the arguments of an SMC call points to the EL3 and EL2 proprietary memory regions. This is to prevent HLOS to pass a pointer pointing to EL2 and EL3 memory. But this protection is only in place to solely protect proprietary EL3 and EL2 regions on most android chipsets. Since we are running our own hypervisor in EL2 alongside a proprietary TrustZone and Hypervisor, when we trap SMC calls, we need to verify if it's arguments point to our code (kvms EL2). This check must be rigorous and specific to each SMC ID to match its argument types. For example, if we pass 2 arguments a1 and a2, if a1 is trated as a pointer and a2 is size, then we need to check if a1 till a1 + a2 falls outside of our memory regions (kvms EL2). Each SMC call is specific and requires its own due diligence.
If we leave the SMC call arguments unchecked, an attacker can issue a handcrafted SMC call with the intention to overwrite EL2 code regions belonging to KVMS by abusing an innocent SMC function in EL3. This can lead to a guest EL1 to EL2 privilege escalation. There's no need for a bug in EL3, just a convenient function to do the job and finding one is trivial.