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: <a6e26927-acb0-c967-10c4-90a41d9a8cad@cs.kuleuven.be>
Date:   Thu, 20 Jul 2023 21:12:17 +0200
From:   Jo Van Bulck <jo.vanbulck@...kuleuven.be>
To:     Jarkko Sakkinen <jarkko@...nel.org>, 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 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ