> From: Andy Lutomirski [mailto:luto@xxxxxxxxxx] > Sent: Tuesday, June 04, 2019 1:25 PM > To: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> > > 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. For the purpose of allowing/denying EADD/EAUG, SECINFO is useless. But SECINFO contains also the page type. What's coming as new feature of SGX2 is CONFIGID, which is a 512-bit value inside SECS, provided by untrusted code at ECREATE. Usually CONFIGID is a hash of something that would affect the behavior of the enclave. For example, the "main" enclave could be a JVM with the actual applet being loaded hashed into SECS.CONFIGID. In that case the enclave's measurements (MRENCLAVE) will stay the same for all applets yet individual applet will have distinct CONFIGID and receive distinct keys. When it comes to LSM, a policy may want to whitelist/blacklist applets for a JVM so a hook at ECREATE may be desirable. We could either define a new hook, or overload security_enclave_load() by providing SECINFO as one of its parameters.
