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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
