From: Andy Lutomirski <luto@kernel.org>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
gregkh@linuxfoundation.org
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@vger.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
Borislav Petkov <bpetkov@suse.de>
Subject: Re: [PATCH 5/6] intel_sgx: driver documentation
Date: Mon, 25 Apr 2016 13:01:06 -0700 [thread overview]
Message-ID: <571E7782.80107@kernel.org> (raw)
In-Reply-To: <1461605698-12385-6-git-send-email-jarkko.sakkinen@linux.intel.com>
On 04/25/2016 10:34 AM, Jarkko Sakkinen wrote:
> +SGX_IOCTL_ENCLAVE_INIT
> +
> +Initializes an enclave given by SIGSTRUCT and EINITTOKEN. Executes EINIT leaf
> +instruction that will check that the measurement matches the one SIGSTRUCT and
> +EINITTOKEN. EINITTOKEN is a data blob given by a special enclave called Launch
> +Enclave and it is signed with a CPU's Launch Key.
>
Having thought about this for ten minutes, I have the following thought:
I think that we should seriously consider not allowing user code to
supply EINITTOKEN at all. Here's why:
1. The nominal purpose of this thing is "launch control." I think that
the decision of whether to launch an enclave belongs in the kernel to
the extent that the kernel has the ability to control this.
2. I think that launch control is actively insecure (assuming that the
use case is what I think it is). Since the kernel might have some
interest in controlling whether an enclave can launch (I think this is
entirely reasonable) and since that policy might reasonably be expressed
in the form of a launch enclave, I think that the *kernel* should
generate the actual EINITTOKEN object. (I also reported, off-list, what
I think is a significant security issue under some usage models that is
mitigated if the user isn't allowed to supply their own EINITTOKEN of
unknown provenance.)
3. On a CPU with unlocked IA32_SGXLEPUBKEYHASH, I think that the kernel
should ship, *in the kernel image*, a binary corresponding to an
open-source "launch anything" enclave. The kernel should, when
appropriate, use this thing to generate EINITTOKEN objects. User code
should *not* have to think about where this "launch anything" enclave
comes from or whether it's the same on all kernels. (I think that the
best way to do this would be to try to build it deterministically using
a well-known key pair. This should be very easy to do.) If someone
wants to turn this feature off, let them do so via sysctl.
If someone wants to supply their own launch enclave, then let them
either feed it to the kernel or enable some non-default privileged
option to allow them to supply EINITTOKEN directly.
Actually implementing this is going to be interesting, because the
kernel will have to call out to CPL 3 to do it. It's not *that* hard,
though, as the exiting kernel thread API should be more or less adequate.
--Andy
next prev parent reply other threads:[~2016-04-25 20:01 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-25 17:34 [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen
2016-04-25 17:34 ` [PATCH 1/6] x86: add SGX definition to cpufeature Jarkko Sakkinen
2016-04-25 19:31 ` Andy Lutomirski
2016-04-25 19:48 ` Andi Kleen
2016-04-25 17:34 ` [PATCH 2/6] x86, sgx: common macros and definitions Jarkko Sakkinen
2016-04-25 17:34 ` [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions Jarkko Sakkinen
2016-04-25 17:55 ` Greg KH
2016-04-25 19:04 ` Jarkko Sakkinen
2016-04-27 6:49 ` Jethro Beekman
2016-04-27 12:40 ` Jarkko Sakkinen
2016-04-27 23:32 ` Jethro Beekman
2016-04-29 20:04 ` Jarkko Sakkinen
2016-04-29 22:22 ` Jethro Beekman
2016-05-09 5:29 ` Jarkko Sakkinen
2016-05-09 7:06 ` Jarkko Sakkinen
2016-04-25 17:34 ` [PATCH 4/6] intel_sgx: ptrace() support for the driver Jarkko Sakkinen
2016-04-25 17:34 ` [PATCH 5/6] intel_sgx: driver documentation Jarkko Sakkinen
2016-04-25 20:01 ` Andy Lutomirski [this message]
2016-05-05 22:45 ` Jarkko Sakkinen
2016-05-06 0:52 ` Andy Lutomirski
2016-05-06 11:35 ` Jarkko Sakkinen
2016-05-06 16:24 ` Andy Lutomirski
2016-04-25 17:34 ` [PATCH 6/6] intel_sgx: TODO file for the staging area Jarkko Sakkinen
2016-04-25 17:54 ` Greg KH
2016-04-25 18:56 ` Jarkko Sakkinen
2016-04-25 19:06 ` One Thousand Gnomes
2016-04-25 20:01 ` Andi Kleen
2016-04-26 11:23 ` Jarkko Sakkinen
2016-04-27 6:38 ` Jethro Beekman
2016-05-17 9:38 ` Jarkko Sakkinen
2016-04-25 17:53 ` [PATCH 0/6] Intel Secure Guard Extensions Greg KH
2016-04-25 19:03 ` Jarkko Sakkinen
2016-04-25 19:20 ` Andy Lutomirski
2016-04-26 19:00 ` Pavel Machek
2016-04-26 19:05 ` Andy Lutomirski
2016-04-26 19:41 ` Pavel Machek
2016-04-26 19:56 ` Andy Lutomirski
2016-04-26 20:11 ` Pavel Machek
2016-04-26 20:59 ` One Thousand Gnomes
2016-04-26 21:52 ` Pavel Machek
2016-04-26 22:35 ` Andy Lutomirski
2016-04-26 22:33 ` Andy Lutomirski
2016-04-27 7:32 ` Pavel Machek
2016-04-27 8:18 ` Ingo Molnar
2016-04-27 14:05 ` Andy Lutomirski
2016-05-06 11:23 ` Jarkko Sakkinen
2016-05-06 16:21 ` Andy Lutomirski
2016-04-26 20:16 ` One Thousand Gnomes
2016-04-26 20:19 ` One Thousand Gnomes
2016-04-29 20:17 ` Jarkko Sakkinen
2016-05-01 9:40 ` Pavel Machek
2016-05-02 15:37 ` Austin S. Hemmelgarn
2016-05-03 9:06 ` Dr. Greg Wettstein
2016-05-03 15:38 ` Pavel Machek
2016-05-04 9:04 ` Dr. Greg Wettstein
2016-05-04 11:07 ` Pavel Machek
2016-05-06 11:39 ` Jarkko Sakkinen
2016-05-06 11:54 ` Thomas Gleixner
2016-05-09 5:38 ` Jarkko Sakkinen
2016-05-09 6:27 ` Thomas Gleixner
2016-05-09 9:20 ` Jarkko Sakkinen
2016-05-12 8:50 ` Dr. Greg Wettstein
2016-05-09 7:04 ` Greg KH
2016-05-09 9:13 ` Jarkko Sakkinen
2016-05-08 9:58 ` Dr. Greg Wettstein
2016-05-09 1:32 ` Andy Lutomirski
2016-05-13 9:42 ` Dr. Greg Wettstein
2016-05-13 14:09 ` Andy Lutomirski
2016-05-05 22:52 ` Jarkko Sakkinen
2016-05-06 7:14 ` Pavel Machek
2016-05-06 11:27 ` Jarkko Sakkinen
2016-04-29 22:08 ` Jarkko Sakkinen
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=571E7782.80107@kernel.org \
--to=luto@kernel.org \
--cc=bpetkov@suse.de \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).