On 20.07.23 21:56, Dave Hansen wrote:
On the other hand, if we don't leave glaring, known "security" vulnerabilities in it, even more people will be fooled into trying to use our example code for something that needs actual security.
I see the reasoning, but I'm afraid it's generally hard to stop people from copying good examples as templates for their own projects..
I do believe in the value of clean, minimal open-source example enclave code. In this respect, I personally (and others on the past mailing list as well, it seems) really like the minimal self-contained Linux selftest enclave! I think, with the fixes in this patch series, the Linux selftest enclave can continue to bring value to the community and help in further diversifying the open-source SGX ecosystem.
FWIW, I'd not call these "glaring" security holes, but rather subtle oversights that I think most people who would copy the code today may well not be aware of and inherit unknowingly (e.g., reference [2] from my original message did a wide-scale study of the open-source SGX ecosystem as of 2019 and showed exactly these kinds of ABI/API vulnerabilities were widespread and re-occurring in several SGX production projects).
I personally don't know the first thing about writing a secure enclave. I just know it's _really_ hard and I honestly don't expect someone to do it without the help of the SDK.
Agreed, it _is_ hard indeed. And it has been a moving target over the years, especially with software/compiler defenses for different waves of microarchitectural vulnerabilities (Spectre, LVI, etc.). That being said, I do think that we learned a lot as a community and we have a much better grasp on how to write (reasonably) secure enclave software these days. Sanitizing the ABI and API remains a core enclave software responsibility (whereas microarchitectural attacks can arguably be mostly mitigated through hardware silicon/ucode patches and/or automatic compiler mitigations).
I do agree that sane end users should use a shielding runtime to abstract away most of these concerns, where the Intel SGX SDK is just one of many in a growing open-source SGX ecosystem (see for instance earlier references [2,3] for an overview).
But there may be good reasons to want to do things from scratch when building your own SGX shielding runtime, e.g., support for custom languages (Rust, Go) or library OSs. I think the Linux selftest enclave helps in further diversifying the open-source SGX ecosystem and can provide an excellent starting point (with the fixes in this patch series).
Best, Jo
