lkml.org 
[lkml]   [2021]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 10/25] x86/sgx: Support enclave page permission changes
From
Date
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.

\
 
 \ /
  Last update: 2021-12-03 00:48    [W:0.350 / U:2.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site