On Mon, Apr 25, 2016 at 01:01:06PM -0700, Andy Lutomirski wrote: > 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. I'm not sure why you would want to do this especially when you can use your own key pair for launch control in future. This would degrade the security of the SGX to the level of the running kernel binary. > 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.) Generating EINITTOKEN requires to have a launch enclave i.e. enclave that is signed with the private key of the launch control policy. > 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. I think that the key point is that you can define your own key pair in order to have your own launch control policy. This will be eventually enabled as it is documented in the SDM. > --Andy /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
