On 09/27/2018 08:39 AM, Jarkko Sakkinen wrote: > On Thu, Sep 27, 2018 at 07:58:41AM -0700, Dave Hansen wrote: >> On 09/27/2018 06:42 AM, Jarkko Sakkinen wrote: >>>> This flag is 1 if the exception is unrelated to paging and >>>> resulted from violation of SGX-specific access-control >>>> requirements. ... such a violation can occur only if there >>>> is no ordinary page fault... >>>> >>>> This is pretty important. It means that *none* of the other >>>> paging-related stuff that we're doing applies. >>>> >>>> We also need to clarify how this can happen. Is it through something >>>> than an app does, or is it solely when the hardware does something under >>>> the covers, like suspend/resume. >>> When you change page permissions lets say with mprotect after the and >>> try to do an invalid access according to the EPCM permissions this can >>> happen. >> >> So, there are pages that are non-executable, non-readable, or >> non-writable both via the page tables and via underlying SGX >> permissions. Then, we allow an mprotect() and a later access will >> result in one of these SGX faults? > > The permissions are intersection of PTE and EPCM permissions. Right, but this *fault* bit is not. > EPCM permissions are part of the enclave measurement. For SGX1 they are > static. For SGX2 they can be changed with EMODPR/EACCEPT protocol (i.e. > measurement can be updated after enclave initialization). What does this all have to do with enclave measurement? >> What permissions are these, exactly? Is it even a good idea to let that >> mprotect() go through in the first place? > > You define RWX for each page when you do EADD. Are those permissions reflected into the VMAs mapping the enclave memory?
