lkml.org 
[lkml]   [2019]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2019-06-04 00:06    [W:0.390 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site