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: <da0cfb1e-e347-f7f2-ac72-aec0ee0d867d@intel.com>
Date:   Thu, 20 Jul 2023 17:24:53 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jo Van Bulck <jo.vanbulck@...kuleuven.be>, jarkko@...nel.org,
        linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     dave.hansen@...ux.intel.com
Subject: Re: [PATCH v2 0/4] selftests/sgx: Harden test enclave

On 7/20/23 15:16, Jo Van Bulck wrote:
> While I understand that the bare-metal Intel SGX selftest enclave is
> certainly not intended as a full-featured independent production runtime,
> it has been noted on this mailing list before that "people are likely to
> copy this code for their own enclaves" and that it provides a "great
> starting point if you want to do things from scratch" [1].

I wholeheartedly agree with the desire to spin up enclaves without the
overhead or complexity of the SDK.  I think I'm the one that asked for
this test enclave in the first place.  There *IS* a gap here.  Those who
care about SGX would be wise to close this gap in _some_ way.

But I don't think the kernel should be the place this is done.  The
kernel should not be hosting a real-world (userspace) SGX reference
implementation.

I'd fully support if you'd like to take the selftest code, fork it, and
maintain it.  The SGX ecosystem would be better off if such a project
existed.  If I can help here in some way like (trying to) release the
SGX selftest under a different license, please let me know.

The only patches I want for the kernel are to make the test enclave more
*obviously* insecure.

So, it's a NAK from me for this series.  I won't support merging this
into the kernel.  But at the same time, I'm very sympathetic to your
cause, and I do appreciate your effort here.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ