Re: [PATCH 05/25] x86/sgx: Introduce runtime protection bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux