Re: [RFC PATCH v2 4/5] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

2019-06-10 Thread Sean Christopherson
On Fri, Jun 07, 2019 at 03:58:34PM -0400, Stephen Smalley wrote: > On 6/5/19 10:11 PM, Sean Christopherson wrote: > >enclave_load() is roughly analogous to the existing file_mprotect(). > > > >Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave > >VMAs are backed by a single

Re: [RFC PATCH v2 4/5] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

2019-06-10 Thread Jarkko Sakkinen
On Wed, Jun 05, 2019 at 07:11:44PM -0700, Sean Christopherson wrote: > enclave_load() is roughly analogous to the existing file_mprotect(). > > Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave > VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be >

Re: [RFC PATCH v2 4/5] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

2019-06-07 Thread Stephen Smalley
On 6/5/19 10:11 PM, Sean Christopherson wrote: enclave_load() is roughly analogous to the existing file_mprotect(). Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be MAP_SHARED. Furthermore, all enclaves

[RFC PATCH v2 4/5] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

2019-06-05 Thread Sean Christopherson
enclave_load() is roughly analogous to the existing file_mprotect(). Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be MAP_SHARED. Furthermore, all enclaves need read, write and execute VMAs. As a result,