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