On Tue, 2018-11-06 at 15:45 +0200, Jarkko Sakkinen wrote:
> Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
> can be used by applications to set aside private regions of code and
> data. The code outside the enclave is disallowed to access the memory
> inside the enclave by the CPU access control.
>
> SGX driver provides a ioctl API for loading and initializing enclaves.
> Address range for enclaves is reserved with mmap() and they are
> destroyed with munmap(). Enclave construction, measurement and
> initialization is done with the provided the ioctl API.
...
> +struct sgx_encl {
> + unsigned int flags;
> + uint64_t attributes;
> + uint64_t xfrm;
> + unsigned int page_cnt;
> + unsigned int secs_child_cnt;
> + struct mutex lock;
> + struct mm_struct *mm;
> + struct file *backing;
Is there any particular reason why the kernel manages the backing for
the enclave and the PCMDs? Could we have userspace provide the backing
either through the ECREATE ioctl() or maybe a completely new ioctl(),
e.g. to give userspace the option to back the enclave with a NVDIMM
instead of RAM? A separate ioctl() with control flags might give us
some flexibility in the future, e.g. maybe there are use cases where
userspace would prefer to kill enclaves rather than swap EPC.
> + struct kref refcount;
> + unsigned long base;
> + unsigned long size;
> + unsigned long ssaframesize;
> + struct radix_tree_root page_tree;
> + struct list_head add_page_reqs;
> + struct work_struct add_page_work;
> + struct sgx_encl_page secs;
> + struct pid *tgid;
> + struct mmu_notifier mmu_notifier;
> + struct notifier_block pm_notifier;
> +};
