On Thu, Jun 13, 2019 at 02:00:29PM -0400, Stephen Smalley wrote:

On 6/11/19 6:55 PM, Xing, Cedric wrote:

quoted

You are right that there are SGX specific stuff. More precisely, SGX
enclaves don't have access to anything except memory, so there are only 3
questions that need to be answered for each enclave page: 1) whether X is
allowed; 2) whether W->X is allowed and 3 whether WX is allowed. This
proposal tries to cache the answers to those questions upon creation of each
enclave page, meaning it involves a) figuring out the answers and b)
"remember" them for every page. #b is generic, mostly captured in
intel_sgx.c, and could be shared among all LSM modules; while #a is SELinux
specific. I could move intel_sgx.c up one level in the directory hierarchy
if that's what you'd suggest.

By "SGX", did you mean the SGX subsystem being upstreamed? It doesn’t track
that state. In practice, there's no way for SGX to track it because there's
no vm_ops->may_mprotect() callback. It doesn't follow the philosophy of
Linux either, as mprotect() doesn't track it for regular memory. And it
doesn't have a use without LSM, so I believe it makes more sense to track it
inside LSM.

Yes, the SGX driver/subsystem.  I had the impression from Sean that it does
track this kind of per-page state already in some manner, but possibly he
means it does under a given proposal and not in the current driver.

Yeah, under a given proposal.  SGX has per-page tracking, adding new flags
is fairly easy.  Philosophical objections aside, adding .may_mprotect() is
trivial.

Even the #b remembering might end up being SELinux-specific if we also have
to remember the original inputs used to compute the answer so that we can
audit that information when access is denied later upon mprotect().  At the
least we'd need it to save some opaque data and pass it to a callback into
SELinux to perform that auditing.