On 20.07.23 19:25, Jarkko Sakkinen wrote:
There's a lot of source code in kselftest, which probably has at least some security issues. I'm not sure, at least based on this motivation, why would we care?
I'd argue that, in general, code examples are often used as templates and may thus inherit any vulnerabilities therein. This may be especially relevant here as your selftest enclave is in my knowledge the only available truly minimal SGX enclave that can be built and extended while only relying on standard tools and no heavy frameworks like the Intel SGX SDK. Thus, as noted before on this mailing list, it may be an attractive start for people who want to build things from scratch.
IMHO the example enclave should do a best effort to reasonably follow SGX coding best practices and not have _known_ security vulnerabilities in it. Note that these are not advanced microarchitectural attacks with ugly LFENCE defenses, but plain, architectural memory-safety exploit preventions with minimal sanitization checks, not unlike the existing protections against buffer overflow where best practices are followed for op->type.
Apart from that, the added checks only enforce correct behavior in the test framework, only validating that things are sane and as expected. Thus, to some extent, the added checks may even increase resilience of the test framework.
Best, Jo
