Hardware enclaves, such as Intel Software Guard Extension (SGX), are hardware security features of recent CPUs which allow the isolated execution of critical code. The typical threat model of hardware enclaves includes the totally isolated execution of trusted code in the enclave, considering all the rest of the code and data, operating system included, un-trusted. Software running in a hardware enclave has limited access to all data outside the enclave, whereas everything else does not have any access to what is inside the enclave, hypervisor, operating system and anti-virus included. Hardware enclaves can manage with very high security applications as password and secret-key managers, crypto-currency wallets, DRM etc.

But what could happen if a malware, for example a ransomware, is loaded in a hardware enclave?

First of all, a malware hidden in a hardware enclave cannot be detected since neither the hypervisor, operating system nor any kind of anti-virus can access it. The software to be loaded in a hardware enclave must be signed by a trusted entity, for example for SGX by Intel itself or by a trusted developer. This makes it more difficult to distribute hardware enclave malware, but not completely impossible. Finally, applications running inside a hardware enclave have very constrained access to the outside resources and it was believed that malware could use a hardware enclave (that is part of it could run in a hardware enclave) but that it was not possible for a malware to fully run inside an enclave without any component outside it.

M. Schwarz, S. Weiser and D. Gruss have instead recently shown in this paper that, at least theoretically, it is possible to create a super-malware run entirely from within a hardware enclave. This super-malware would be undetectable and could act as a normal malware on the rest of the system. At the moment countermeasures are not available, but similarly to the case of Spectre and Meltdown they could require hardware modification and/or have impact on the speed of the CPUs.