[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4f50b3b3-2cd5-30a4-5715-3350ef2174d9@kernel.org>
Date: Fri, 3 Dec 2021 16:38:06 -0800
From: Andy Lutomirski <luto@...nel.org>
To: Reinette Chatre <reinette.chatre@...el.com>,
dave.hansen@...ux.intel.com, jarkko@...nel.org, tglx@...utronix.de,
bp@...en8.de, mingo@...hat.com, linux-sgx@...r.kernel.org,
x86@...nel.org
Cc: seanjc@...gle.com, kai.huang@...el.com, cathy.zhang@...el.com,
cedric.xing@...el.com, haitao.huang@...el.com,
mark.shanahan@...el.com, hpa@...or.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/25] x86/sgx: Introduce runtime protection bits
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.
Powered by blists - more mailing lists