[lkml]   [2019]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v20 00/28] Intel SGX1 support
On Tue, 14 May 2019 16:58:24 -0500, Xing, Cedric <>  

> Hi Everyone,
> I think we are talking about 2 different kinds of criteria for
> determining the sanity of an enclave.
> The first kind determines an enclave's sanity by generally accepted good
> practices. For example, no executable pages shall ever be writable.

We'll have to trust user space doing mmap with right permissions as
SELinux does not enforce which segment to be RW and which to be RX. The
file needs to have SELinux EXECUTE and WRITE both, if we need map some
segments with RW and others with RX.

We could say EINIT would ensure user is doing the right thing because it
would fail if user map permission wrongly. Then the extra mmaps are
redundant of doing SIGSTRUCT verification.

Additionally, per Sean's comments, after EADD in current implementation,
we will still need PROCESS_EXECMEM for mprotect on enclave fd to change
some EPC pages PTE to RX before enclave can execute. So I don't think mmap
the source enclave file would gain anything in addition to what your
proposed security_sgx_initialize_enclave() does.

Since security_sgx_initialize_enclave() is a lot like launch control
policy enforcement we discussed a lot and resolved, I tend to agree with
Andy's assessment we can just do nothing for the initial merge and add
hooks needed if someone wants them. And the initial merge would require
the enclave hosting processes ask for PROCESS_EXECMEM permission to do
mmap/mprotect with enclave fd.

 \ /
  Last update: 2019-05-15 07:15    [W:0.183 / U:13.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site