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
--
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
