Hi Andy,
On 12/3/2021 4:38 PM, Andy Lutomirski wrote:
On 12/3/21 14:12, Reinette Chatre wrote:
Hi Andy,
On 12/3/2021 11:28 AM, Andy Lutomirski wrote:
On 12/1/21 11:23, Reinette Chatre wrote:
Enclave creators declare their paging permission intent at the time
the pages are added to the enclave. These paging permissions are
vetted when pages are added to the enclave and stashed off
(in sgx_encl_page->vm_max_prot_bits) for later comparison with
enclave PTEs.
I'm a bit confused here. ENCLU[EMODPE] allows the enclave to change
the EPCM permission bits however it likes with no oversight from the
kernel. So we end up with a whole bunch of permission masks:
Before jumping to the permission masks I would like to step back and
just confirm the context. We need to consider the following three
permissions:
EPCM permissions: the enclave page permissions maintained in the SGX
hardware. The OS is constrained here in that it cannot query the
current EPCM permissions. Even so, the OS needs to ensure PTEs are
installed appropriately (we do not want a RW PTE for a read-only
enclave page)
Why not? What's wrong with an RW PTE for a read-only enclave page?
If you convince me that this is actually important, then I'll read all
the stuff below.
Perhaps it is my misunderstanding/misinterpretation of the current
implementation? From what I understand the current requirement, as
enforced in the current mmap(), mprotect() as well as fault() hooks, is
that mappings are required to have identical or weaker permission than
the enclave permission.
Could you please elaborate how you envision PTEs should be managed in
this implementation?
Thank you
Reinette
