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
