There’s a pretty straightforward mitigation to this: only allow enclaves from software authors you trust. The kernel does not have to allow usermode to run enclaves, which is very much by design.
> This solution works, with its own caveats
Yeah, how does one verify the trust of e.g. all the authors of the Linux kernel? The caveat seems that it isn't realistic.
Huh? why is this an issue at all. The most memory SGX can directly use is 128MB. So partition it off-- it's a small cost if it's likely that you'll use it.
Enclaves are not limited to 128MB in total, since the OS can page in and out SGX pages...
I think you missed my point. I was talking specifically about providing SGX to VM guests on multi-tenant machines. The difficulty is not insurmountable, but other than some experimental Intel patches, KVM doesn’t support it yet.
That doesn't seem right. How is the OS supposed to page SGX in/out without being able to read its memory?
To the best of my knowledge, all SGX attack research papers disable checks and run unsigned SGX code to demonstrate a proof of concept.
Not saying vendors won't run horrid things in SGX enclaves, just saying malware authors are gonna need to steal a private key first :P
While interesting, papers like these usually have titles that are disingenuous at best. I’ve seen the media report on papers with scary titles and make it sound like the sky is falling, but the scenario is generally (not always) contrived.