On Wed, Jun 05, 2019 at 06:10:18PM +0300, Jarkko Sakkinen wrote: > On Tue, Jun 04, 2019 at 01:25:10PM -0700, Andy Lutomirski wrote: > > On Tue, Jun 4, 2019 at 9:26 AM Jarkko Sakkinen > > <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, May 31, 2019 at 04:31:57PM -0700, Sean Christopherson wrote: > > > > Do not allow an enclave page to be mapped with PROT_EXEC if the source > > > > page is backed by a file on a noexec file system. > > > > > > > > Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> > > > > > > Why don't you just check in sgx_encl_add_page() that whether the path > > > comes from noexec and deny if SECINFO contains X? > > > > > > > SECINFO seems almost entirely useless for this kind of thing because > > of SGX2. I'm thinking that SECINFO should be completely ignored for > > anything other than its required architectural purpose. > > Not exactly sure why using it to pass the RWX bits to EADD ioctl would > cause anything to SGX2 support. Andy was pointing out that with SGX2 the enclave can do ENCLU[EMODPE] to make the page executable, e.g. add the page with SECINFO.R and then mprotect() the enclave VMA (whose vm_file == /dev/sgx/enclave) PROT_EXEC. We could hard enforce SECINFO, i.e. set the enclave page's protection bits directly from SECINFO, but that would neuter SGX2, e.g. would break converting RW to RX.
