Messages in this thread | | | Date | Mon, 3 Jun 2019 23:43:53 +0300 | From | Jarkko Sakkinen <> | Subject | Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) |
| |
On Thu, May 30, 2019 at 07:31:14AM -0700, Andy Lutomirski wrote: > - To create an X mapping of an enclave page that came from EADD, you > need EXECUTE on the source file. Optionally, we could also permit > this if you have EXECMOD.
Source file? EADD ioctl takes memory buffer in right now.
> And I have two design proposals. One is static and one is dynamic. > To implement either one, we will probably need a new .may_mprotect vm > operation, and that operation can call an LSM hook. Or we can give > LSMs a way to detect that a given vm_area_struct is an enclave. As I > see it, this is an implementation detail that is certainly solveable.
Why VM operation and not file operation?
> EADD takes an execute_intent flag. It calls a new hook: > > int security_enclave_load(struct vm_area_struct *source, bool execute_intent); > > This hook will fail if execute_intent==true and the caller has neither > EXECUTE, EXECMOD, nor EXECMEM. > > EAUG sets execute_intent = false. > > EINIT takes a sigstruct pointer. SGX can (when initially upstreamed > or later on once there's demand) call a new hook: > > security_enclave_init(struct sigstruct *sigstruct, struct > vm_area_struct *source);
What is the source VMA in these callbacks? Why is @execute_intent needed anyway as a ioctl arugment and not deduced from SECINFO?
/Jarkko
| |