From: Dave Hansen <dave.hansen@intel.com>
To: Jo Van Bulck <jo.vanbulck@cs.kuleuven.be>,
jarkko@kernel.org, linux-sgx@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: dave.hansen@linux.intel.com
Subject: Re: [PATCH v2 0/4] selftests/sgx: Harden test enclave
Date: Thu, 20 Jul 2023 17:24:53 -0700 [thread overview]
Message-ID: <da0cfb1e-e347-f7f2-ac72-aec0ee0d867d@intel.com> (raw)
In-Reply-To: <20230720221623.9530-1-jo.vanbulck@cs.kuleuven.be>
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.
next prev parent reply other threads:[~2023-07-21 0:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 22:16 [PATCH v2 0/4] selftests/sgx: Harden test enclave Jo Van Bulck
2023-07-20 22:16 ` [PATCH 1/4] selftests/sgx: Harden test enclave ABI Jo Van Bulck
2023-07-20 22:16 ` [PATCH 2/4] selftests/sgx: Store base address and size in test enclave Jo Van Bulck
2023-07-20 22:16 ` [PATCH 3/4] selftests/sgx: Harden test enclave API Jo Van Bulck
2023-07-20 22:16 ` [PATCH 4/4] selftests/sgx: Fix compiler optimizations in test enclave Jo Van Bulck
2023-07-21 0:24 ` Dave Hansen [this message]
2023-07-24 10:33 ` [PATCH v2 0/4] selftests/sgx: Harden " Jo Van Bulck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=da0cfb1e-e347-f7f2-ac72-aec0ee0d867d@intel.com \
--to=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jarkko@kernel.org \
--cc=jo.vanbulck@cs.kuleuven.be \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.