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

2019-06-05 Thread Sean Christopherson
On Tue, Jun 04, 2019 at 02:43:09PM -0700, Xing, Cedric wrote: > > From: Christopherson, Sean J > > Sent: Tuesday, June 04, 2019 1:37 PM > > > > On Tue, Jun 04, 2019 at 01:29:10PM -0700, Andy Lutomirski wrote: > > > On Fri, May 31, 2019 at 4:32 PM Sean Christopherson > > > wrote: > > > > static i

RE: [RFC PATCH 8/9] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

2019-06-04 Thread Xing, Cedric
> From: Christopherson, Sean J > Sent: Tuesday, June 04, 2019 1:37 PM > > On Tue, Jun 04, 2019 at 01:29:10PM -0700, Andy Lutomirski wrote: > > On Fri, May 31, 2019 at 4:32 PM Sean Christopherson > > wrote: > > > static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long > > > addr, diff -

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

2019-06-04 Thread Andy Lutomirski
On Fri, May 31, 2019 at 4:32 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. Furt

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

2019-06-04 Thread Sean Christopherson
On Tue, Jun 04, 2019 at 01:29:10PM -0700, Andy Lutomirski wrote: > On Fri, May 31, 2019 at 4:32 PM Sean Christopherson > wrote: > > static int sgx_encl_add_page(struct sgx_encl *encl, unsigned long addr, > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > > index 47f58cfb6a19

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

2019-06-03 Thread Dave Hansen
... >>> What ensures that the mapping referenced by src can't be changed >>> to an entirely different one (with a different vm_file) between >>> the time of check (here) and the time of use? >> >> Nothing. Holding mmap_sem across copy_from_user() would suffice, >> correct? > > I don't believe y

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

2019-06-03 Thread Stephen Smalley
On 6/3/19 10:42 AM, Sean Christopherson wrote: On Mon, Jun 03, 2019 at 10:19:18AM -0400, Stephen Smalley wrote: On 5/31/19 7:31 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 enc

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

2019-06-03 Thread Sean Christopherson
On Mon, Jun 03, 2019 at 10:19:18AM -0400, Stephen Smalley wrote: > On 5/31/19 7:31 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

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

2019-06-03 Thread Stephen Smalley
On 5/31/19 7:31 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

RE: [RFC PATCH 8/9] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX

2019-06-02 Thread Xing, Cedric
> From: Christopherson, Sean J > Sent: Friday, May 31, 2019 4:32 PM > > diff --git a/include/linux/security.h b/include/linux/security.h index > 659071c2e57c..2f7925eeef7e 100644 > --- a/include/linux/security.h > +++ b/include/linux/security.h > @@ -392,6 +392,8 @@ void security_inode_invalidate_