[lkml]   [2021]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 05/25] x86/sgx: Introduce runtime protection bits
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


 \ /
  Last update: 2021-12-04 02:15    [W:0.115 / U:2.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site