From: Christopherson, Sean J
Sent: Monday, June 10, 2019 8:56 AM

quoted

quoted

As a result, LSM policies cannot be meaningfully applied, e.g. an
LSM can deny access to the EPC as a whole, but can't deny PROT_EXEC
on page that originated in a non-EXECUTE file (which is long gone by
the time
mprotect() is called).

I have hard time following what is paragraph is trying to say.

quoted

By hooking mprotect(), SGX can make explicit LSM upcalls while an
enclave is being built, i.e. when the kernel has a handle to origin
of each enclave page, and enforce the result of the LSM policy
whenever userspace maps the enclave page in the future.

"LSM policy whenever calls mprotect()"? I'm no sure why you mean by
mapping here and if there is any need to talk about future. Isn't this
needed now?

Future is referring to the timeline of a running kernel, not the future
of the kernel code.

Rather than trying to explain all of the above with words, I'll provide
code examples to show how ->may_protect() will be used by SGX and why it
is the preferred solution.

The LSM concept is to separate security policy enforcement from the rest of the kernel. For modules, the "official" way is to use VM_MAY* flags to limit allowable permissions, while LSM uses security_file_mprotect(). I guess that's why we didn't have .may_mprotect() in the first place. What you are doing is enforcing some security policy outside of LSM, which is dirty from architecture perspective.