| Subject | Re: [PATCH v11 12/13] intel_sgx: driver documentation | From | Jethro Beekman <> | Date | Fri, 8 Jun 2018 11:32:17 -0700 |
| |
On 2018-06-08 10:09, Jarkko Sakkinen wrote: > +Launching enclaves > +------------------ > + > +For privileged enclaves the launch is performed simply by submitting the > +SIGSTRUCT for that enclave to ENCLS(EINIT). For unprivileged enclaves the > +driver hosts a process in ring-3 that hosts a launch enclave signed with a key > +supplied for kbuild. > + > +The current implementation of the launch enclave generates a token for any > +enclave. In the future it could be potentially extended to have ways to > +configure policy what can be lauched. > + > +The driver will fail to initialize if it cannot start its own launch enclave. > +A user space application can submit a SIGSTRUCT instance through the ioctl API. > +The kernel will take care of the rest. > + > +This design assures that the Linux kernel has always full control, which > +enclaves get to launch and which do not, even if the public key MSRs are
As discussed previously at length, since the kernel needs to execute ENCLS[EINIT], it has full control to deny the launching of enclaves regardless of any launch enclave implementation. Please change this misleading statement.
> +read-only. Having launch intrinsics inside the kernel also enables easy > +development of enclaves without necessarily needing any heavy weight SDK. > +Having a low-barrier to implement enclaves could make sense for example for > +system daemons where amount of dependecies ought to be minimized.
-- Jethro Beekman | Fortanix
[unhandled content-type:application/pkcs7-signature] |