ARM TrustZone is predicated on the Secure World being potentially able to monitor and modify the entire Non-Secure World, because it has control over the MMU (see TZASC, TZMA, TZPC). The reverse is clearly impossible.
SGX instead is defined as a "secure" sandbox, it has basically no privilege even over the process it runs in.
Having said that, researches demonstrated examples of SGX-based malware, which is ultimately rooted in the fact that SGX state is not fully observable (i.e. you can load encrypted code, though you need a lot scaffolding). However, such malware uses a lot of tricks whose side effects can be detected (notwithstanding the fundamental microarchs attacks).
> (i.e. you can load encrypted code, though you need a lot scaffolding)
precisely for this reason ... that it raises the cost of an attacker by also raising the cost for security researchers and making introspection impossible, ... it is snake-oil. It's a perfect hiding spot not despite but because of this!
The fact that it's designed to allow a smaller volume of trusted code doesn't really prevent you from putting the "normal" amount of malware in there...
ARM TrustZone is predicated on the Secure World being potentially able to monitor and modify the entire Non-Secure World, because it has control over the MMU (see TZASC, TZMA, TZPC). The reverse is clearly impossible.
SGX instead is defined as a "secure" sandbox, it has basically no privilege even over the process it runs in.
Having said that, researches demonstrated examples of SGX-based malware, which is ultimately rooted in the fact that SGX state is not fully observable (i.e. you can load encrypted code, though you need a lot scaffolding). However, such malware uses a lot of tricks whose side effects can be detected (notwithstanding the fundamental microarchs attacks).