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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <CU8WIZGB01DT.2YX12UG6QRTA@seitikki>
Date:   Sat, 22 Jul 2023 18:10:42 +0000
From:   "Jarkko Sakkinen" <jarkko@...nel.org>
To:     "Jo Van Bulck" <jo.vanbulck@...kuleuven.be>,
        <linux-sgx@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Cc:     <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 0/4] selftests/sgx: Harden test enclave

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