> From: Christopherson, Sean J > Sent: Monday, June 10, 2019 8:56 AM > > > > 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. > > > > > 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.
