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?
