> From: Christopherson, Sean J
> Sent: Friday, May 31, 2019 4:32 PM
>
> To support LSM integration, SGX will require userspace to explicitly specify
> the allowed
> protections for each page. The allowed protections will be supplied to and
> modified by
> LSMs (based on their policies).
> To prevent userspace from circumventing the allowed protections, do not allow
> PROT_{READ,WRITE,EXEC} mappings to an enclave without an associated enclave
> page (which
> will track the allowed protections).
This is unnecessary.
For mprotect(), LSM shall validate @prot against existing pages with applicable
global flags (e.g. FILE__EXECMOD/PROCESS__EXECMEM in the case of SELinux).
For mmap(), SGX driver could invoke security_file_mprotect() explicitly to have
LSM validate requested protection.
In the case where there's no page associated with an VMA,
security_file_mprotect() shall still dictate whether to allow/deny the request.
LSM internally is able to track existence/nonexistence of enclave pages. If
there's no page, there's no conflict so the decision shall only depend on
global flags (if any). Afterwards, #PF may trigger SGX driver to EAUG, in which
case security_enclave_load() will be invoked and LSM could decide whether to
approve/decline EAUG request.
