On 09/26/2018 11:12 AM, Andy Lutomirski wrote:
>> e omniscient.
>>
>> How about this? With formatting changes since it's long-winded...
>>
>> /*
>> * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
>> * access is allowed by the PTE but not the EPCM. This usually
>> happens
>> * when the EPCM is yanked out from under us, e.g. by hardware after a
>> * suspend/resume cycle. In any case, software, i.e. the kernel,
>> can't
>> * fix the source of the fault as the EPCM can't be directly modified
>> * by software. Handle the fault as an access error in order to
>> signal
>> * userspace, e.g. so that userspace can rebuild their enclave(s),
>> even
>> * though userspace may not have actually violated access permissions.
>> */
>>
> Looks good to me.
Including the actual architectural definition of the bit might add some
clarity. The SDM explicitly says (Vol 3a section 4.7):
The fault resulted from violation of SGX-specific access-control
requirements.
Which totally squares with returning true from access_error().
There's also a tidbit that says:
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.
