[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81308f67-a4d1-1774-f58b-223d4e81f8db@intel.com>
Date: Mon, 6 Dec 2021 13:16:17 -0800
From: Reinette Chatre <reinette.chatre@...el.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
CC: <dave.hansen@...ux.intel.com>, <tglx@...utronix.de>,
<bp@...en8.de>, <luto@...nel.org>, <mingo@...hat.com>,
<linux-sgx@...r.kernel.org>, <x86@...nel.org>, <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 03/25] x86/sgx: Support VMA permissions exceeding enclave
permissions
Hi Jarkko,
On 12/4/2021 2:27 PM, Jarkko Sakkinen wrote:
> On Sun, Dec 05, 2021 at 12:25:59AM +0200, Jarkko Sakkinen wrote:
>> On Wed, Dec 01, 2021 at 11:23:01AM -0800, Reinette Chatre wrote:
>>> === Summary ===
>>>
>>> An SGX VMA can only be created if its permissions are the same or
>>> weaker than the Enclave Page Cache Map (EPCM) permissions. After VMA
>>> creation this rule continues to be enforced by the page fault handler.
>>>
>>> With SGX2 the EPCM permissions of a page can change after VMA
>>> creation resulting in the VMA exceeding the EPCM permissions and the
>>> page fault handler incorrectly blocking access.
>>>
>>> Enable the VMA's pages to remain accessible while ensuring that
>>> the page table entries are installed to match the EPCM permissions
>>> without exceeding the VMA perms issions.
>>
>> I don't understand what the short summary means in English, and the
>> commit message is way too bloated to make any conclusions. It really
>> needs a rewrite.
>>
>> These were the questions I could not find answer for:
>>
>> 1. Why it would be by any means safe to remove a permission check?
The permission check is redundant for SGX1 and incorrect for SGX2.
In the current SGX1 implementation the permission check in
sgx_encl_load_page() is redundant because an SGX VMA can only be created
if its permissions are the same or weaker than the EPCM permissions.
In SGX2 a user is able to change EPCM permissions during runtime (while
VMA has the memory mapped). A RW VMA may thus originally have mapped an
enclave page with RW EPCM permissions but since then the enclave page
may have its permissions changed to read-only. The VMA should still be
able to read those enclave pages but the check in sgx_encl_load_page()
will prevent that.
>> 2. Why not re-issuing mmap()'s is unfeasible? I.e. close existing
>> VMA's and mmap() new ones.
User is not prevented from closing existing VMAs and creating new ones.
> 3. Isn't this an API/ABI break?
Could you please elaborate where you see the API/ABI break? The rule
that new VMAs cannot exceed EPCM permissions is untouched.
Reinette
Powered by blists - more mailing lists