[RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM
cedric.xing at intel.com
Tue Jul 9 20:41:28 UTC 2019
On 7/9/2019 10:09 AM, Sean Christopherson wrote:
> On Tue, Jul 09, 2019 at 07:22:03PM +0300, Jarkko Sakkinen wrote:
>> On Mon, Jul 08, 2019 at 10:29:30AM -0700, Sean Christopherson wrote:
>>> On Fri, Jul 05, 2019 at 07:05:49PM +0300, Jarkko Sakkinen wrote:
>>>> On Wed, Jun 19, 2019 at 03:23:49PM -0700, Sean Christopherson wrote:
>>>> I still don't get why we need this whole mess and do not simply admit
>>>> that there are two distinct roles:
>>>> 1. Creator
>>>> 2. User
>>> Because SELinux has existing concepts of EXECMEM and EXECMOD.
>> What is the official documentation for those? I've only found some
>> explanations from discussions and some RHEL sysadmin guides.
> No clue. My knowledge was gleaned from the code and from Stephen's
> The high level breakdown:
> - FILE__EXECUTE: required to gain X on a mapping to a regular file
> - FILE__EXECUTE + FILE__WRITE: required to gain WX or W->X on a shared
> mapping to a regular file
> - FILE__EXECMOD: required to gain W->X on a private mapping of a regular
> - PROCESS__EXECMEM: required to gain WX on a private mapping to a regular
> file, OR to gain X on an anonymous mapping.
> Translating those to SGX, with a lot of input from Stephen, I ended up
> with the following:
> - FILE__ENCLAVE_EXECUTE: equivalent to FILE__EXECUTE, required to gain X
> on an enclave page loaded from a regular file
> - PROCESS2__ENCLAVE_EXECDIRTY: hybrid of EXECMOD and EXECUTE+WRITE,
> required to gain W->X on an enclave page
EXECMOD basically indicates a file containing self-modifying code. Your
ENCLAVE_EXECDIRTY is however a process permission, which is illogical.
> - PROCESS2__ENCLAVE_EXECANON: subset of EXECMEM, required to gain X on
> an enclave page that is loaded from an
> anonymous mapping
> - PROCESS2__ENCLAVE_MAPWX: subset of EXECMEM, required to gain WX on an
> enclave page
>>> That being said, we can do so without functional changes to the SGX uapi,
>>> e.g. add reserved fields so that the initial uapi can be extended *if* we
>>> decide to go with the "userspace provides maximal protections" path, and
>>> use the EPCM permissions as the maximal protections for the initial
>>> That'd give us a minimal implemenation for initial upstreaming and would
>>> eliminate Cedric's blocking complaint. The "whole mess" of whitelisting,
>>> blacklisting and SGX2 support would be deferred until post-upstreaming.
>> I'd like that approach more too.
More information about the Linux-security-module-archive