From: Dave Hansen <dave.hansen@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
intel-sgx-kernel-dev@lists.01.org,
platform-driver-x86@vger.kernel.org
Subject: Re: [intel-sgx-kernel-dev] [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd()
Date: Tue, 24 Oct 2017 08:10:37 -0700 [thread overview]
Message-ID: <a42edcbb-b80c-ea2a-78c3-2d043457cc63@intel.com> (raw)
In-Reply-To: <20171024133913.jpyxdy2xymjuyd7n@linux.intel.com>
On 10/24/2017 06:39 AM, Jarkko Sakkinen wrote:
> On Sun, Oct 22, 2017 at 10:09:16PM -0700, Dave Hansen wrote:
>> On 10/22/2017 07:55 PM, Jarkko Sakkinen wrote:
>>> On Fri, Oct 20, 2017 at 07:32:42AM -0700, Dave Hansen wrote:
>>>> I've always been curious, and the changelog and thread are curiously
>>>> oblique on this topic: what the heck does this driver use pipes *for*?
>>> For communication with the process hosting the launch enclave.
>>
>> But, why pipes? Why does the kernel have to be the one setting these
>> up? Why is this communication necessary in the first place?
>
> 1. Kernel gives a SIGSTRUCT instance to the LE hosting process.
> 2. LE hosting process gives the SIGSTRUCT to the LE.
> 3. LE gives EINITTOKEN to the LE hosting process after generating it.
> 4. LE hosting process gives it back to the kernel.
Let me see if I can turn that into english. Enclaves are all rooted in
a chain of trust. To run an enclave, you need to have that enclave
blessed by the hardware or blessed by a "launch enclave" (aka. LE). The
LE is hosted inside a normal process, just as the enclave we are trying
to launch is hosted in a normal process. In order to launch a normal
enclave, we talk to the LE which gives us a token that allows us to
start a new enclave.
These pipes are the mechanism that we use so that the process starting
the new process can talk to the launch enclave.
How's that?
> I do not understand why using pipes for this is such a big crime to
> implement this. I do have an alternative proposal if it is.
The crime is not writing a good changelog to explain what you are doing
and why you need to do it.
> What I can do is to use one struct shmem_file instance and assing it
> to a file descriptor instead. Kernel and LE hosting process can then
> use that for communication.
Could you explain a bit about what kind of information needs to go back
and forth? Is it just "give me a launch key" followed by "here you go",
or is it more complicated than that?
next prev parent reply other threads:[~2017-10-24 15:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 19:18 [PATCH v4 00/12] Intel(R) SGX Driver Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 01/12] intel_sgx: updated MAINTAINERS Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 02/12] x86: add SGX definition to cpufeature Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 03/12] x86: define the feature control MSR's SGX enable bit Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 04/12] x86: define the feature control MSR's SGX launch control bit Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 05/12] x86: add SGX MSRs to msr-index.h Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 06/12] fs/pipe.c: export create_pipe_files() and replace_fd() Jarkko Sakkinen
2017-10-19 8:06 ` Christoph Hellwig
2017-10-19 12:36 ` Jarkko Sakkinen
2017-10-19 14:55 ` Christoph Hellwig
2017-10-20 10:14 ` Jarkko Sakkinen
2017-10-20 14:32 ` [intel-sgx-kernel-dev] " Dave Hansen
2017-10-23 2:55 ` Jarkko Sakkinen
2017-10-23 5:09 ` Dave Hansen
2017-10-24 13:39 ` Jarkko Sakkinen
2017-10-24 15:10 ` Dave Hansen [this message]
2017-10-24 16:40 ` Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 07/12] intel_sgx: driver for Intel Software Guard Extensions Jarkko Sakkinen
2017-10-18 15:21 ` Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 08/12] intel_sgx: ptrace() support Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 09/12] intel_sgx: driver documentation Jarkko Sakkinen
2017-10-17 0:51 ` Randy Dunlap
2017-10-18 14:25 ` Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 10/12] intel_sgx: in-kernel launch enclave Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 11/12] intel_sgx: glue code for in-kernel LE Jarkko Sakkinen
2017-10-16 19:18 ` [PATCH v4 12/12] intel_sgx: update IA32_SGXLEPUBKEYHASH* MSRs 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=a42edcbb-b80c-ea2a-78c3-2d043457cc63@intel.com \
--to=dave.hansen@intel.com \
--cc=hch@infradead.org \
--cc=intel-sgx-kernel-dev@lists.01.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.