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

[Reinette Chatre]

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