On Mon, Jun 10, 2019 at 11:29 AM Xing, Cedric <cedric.xing@xxxxxxxxx> wrote: > > > From: Christopherson, Sean J > > Sent: Wednesday, June 05, 2019 7:12 PM > > > > +/** > > + * sgx_map_allowed - check vma protections against the associated > > enclave page > > + * @encl: an enclave > > + * @start: start address of the mapping (inclusive) > > + * @end: end address of the mapping (exclusive) > > + * @prot: protection bits of the mapping > > + * > > + * Verify a userspace mapping to an enclave page would not violate the > > +security > > + * requirements of the *kernel*. Note, this is in no way related to > > +the > > + * page protections enforced by hardware via the EPCM. The EPCM > > +protections > > + * can be directly extended by the enclave, i.e. cannot be relied upon > > +by the > > + * kernel for security guarantees of any kind. > > + * > > + * Return: > > + * 0 on success, > > + * -EACCES if the mapping is disallowed > > + */ > > +int sgx_map_allowed(struct sgx_encl *encl, unsigned long start, > > + unsigned long end, unsigned long prot) { > > + struct sgx_encl_page *page; > > + unsigned long addr; > > + > > + prot &= (VM_READ | VM_WRITE | VM_EXEC); > > + if (!prot || !encl) > > + return 0; > > + > > + mutex_lock(&encl->lock); > > + > > + for (addr = start; addr < end; addr += PAGE_SIZE) { > > + page = radix_tree_lookup(&encl->page_tree, addr >> > > PAGE_SHIFT); > > + > > + /* > > + * Do not allow R|W|X to a non-existent page, or protections > > + * beyond those of the existing enclave page. > > + */ > > + if (!page || (prot & ~page->prot)) > > + return -EACCES; > > In SGX2, pages will be "mapped" before being populated. > > Here's a brief summary for those who don't have enough background on how new EPC pages could be added to a running enclave in SGX2: > - There are 2 new instructions - EACCEPT and EAUG. > - EAUG is used by SGX module to add (augment) a new page to an existing enclave. The newly added page is *inaccessible* until the enclave *accepts* it. > - EACCEPT is the instruction for an enclave to accept a new page. > > And the s/w flow for an enclave to request new EPC pages is expected to be something like the following: > - The enclave issues EACCEPT at the linear address that it would like a new page. > - EACCEPT results in #PF, as there's no page at the linear address above. > - SGX module is notified about the #PF, in form of its vma->vm_ops->fault() being called by kernel. > - SGX module EAUGs a new EPC page at the fault address, and resumes the enclave. > - EACCEPT is reattempted, and succeeds at this time. This seems like an odd workflow. Shouldn't the #PF return back to untrusted userspace so that the untrusted user code can make its own decision as to whether it wants to EAUG a page there as opposed to, say, killing the enclave or waiting to keep resource usage under control?