From: Christopherson, Sean J
Sent: Thursday, June 13, 2019 12:49 PM

quoted

quoted

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.

As I pointed out in an earlier email, protection flags are associated with ranges. They could of course be duplicated to every page but that will hurt performance because every page within the range would have to be tested individually.

Furthermore, though .may_protect()is able to make the decision, I don't think it can do the audit log as well, unless it is coded in an SELinux specific way. Then I wonder how it could work with LSM modules other than SELinux.

quoted

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.