SGX is out there and being used. It's actually the solution to these problems, ultimately, because Intel CPUs are highly patchable via microcode and when you se

SGX is out there and being used. It's actually the solution to these problems, ultimately, because Intel CPUs are highly patchable via microcode and when you set up an enclave you're effectively opting in to better security for lower performance. For instance, a lot of the early attacks were blocked simply by making the CPU flush its state when entering or exiting an enclave. Intel could do that because an enclave is meant to be hardened, whereas other sorts of mitigations at e.g. syscall boundaries hit tough performance/security tradeoffs that are very different in different contexts. Also, I'll say, having read a lot of SGX related research papers that many of the attacks were not really practical on close examination, or were immediately patched. The researchers don't tend to mention these things but e.g. using ancient crypto libraries without any side channel mitigations is rather common in that field. For things like this, it'd probably make sense to use SGX more in the Linux kernel for holding secrets and doing other things. A lot of stuff in the kernel isn't really read sensitive (modulo generic secrets like KASLR slides). Having secrets like root hashes hanging around in kernel memory isn't a good idea but where to put them? One solution is to move stuff into enclaves. Unfortunately it would only help on server platforms.