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. 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 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. > Either way, it sounds like we have some new conditions to spell out in > that comment. Agreed. /Jarkko
