[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <24447a03-139a-c7e0-9ad5-34e2019c4df5@intel.com>
Date: Thu, 2 Dec 2021 15:48:06 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>,
dave.hansen@...ux.intel.com, jarkko@...nel.org, tglx@...utronix.de,
bp@...en8.de, luto@...nel.org, 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 10/25] x86/sgx: Support enclave page permission changes
On 12/1/21 11:23 AM, Reinette Chatre wrote:
> + * EPCM permissions can be extended anytime directly from the enclave with
> + * no visibility from the OS. This is accomplished with ENCLU[EMODPE]
> + * run from within enclave. Accessing pages with the new, extended,
> + * permissions requires the OS to update the PTE to handle the subsequent
> + * #PF correctly.
Hi Reinette,
I really dislike the Intel nomenclature here. I know the Intel docs are
all written around permission "extension", but I find it ambiguous.
I've been looking at these instructions literally for years now and
permission extension to me can mean either:
1. The set of things you can do is extended
2. The set of things you can *NOT* do is extended
I much rather prefer nomenclature like:
EPCM permissions can be relaxed anytime directly from the
enclave with no visibility from the OS. This is accomplished
with ENCLU[EMODPE] run from within enclave. Accessing pages with
the new, relaxed permissions requires the OS to update the PTE
to handle the subsequent correctly.
"Relax" is less ambiguous. Relaxing a restriction and relaxing
permissions both mean doing things less strictly. Extending
restrictions and extending what is allowed are opposites.
Maybe it's just me and I need to get this through my thick skull at some
point. But, I do think it's OK to improve on the architecture names for
things when they go into the kernel. The XSAVE XSTATE_BV->xfeatures
rename comes to mind.
Anyway, I'd appreciate if you could keep this in mind and consider
changing it if a future revision is needed if you believe it is more clear.
Powered by blists - more mailing lists