Re: [PATCH 0/4] selftests/sgx: Harden test enclave

[Jarkko Sakkinen]

On Thu Jul 20, 2023 at 7:12 PM UTC, Jo Van Bulck wrote:
> 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.

If you use this code as a template,  you have a legal risk in your hands
because of GPLv2 licensing.

> 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.

I'm not sure what are the "best practices" behavior in the context of a
kselftest instance.

> 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.

I'm not sure what is "correct" behavior in the context of a kselftest
instance.

> Best,
> Jo

This code is not meant for production. I implemented it specifically for
kselftest, and that is exactly its scope.

BR, Jarkko