[lkml]   [2020]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >> That means that the intent argument (SGX_PROT_*) is currently unused.
> > No, the intent argument is used (eventually) by SGX's ->mprotect()
> > implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> > subset of the declared/intended protections.
> >
> > If ->mprotect() is not merged, then it yes, it will be unused.
> OK, I think I've got it.
> I think I'm OK with adding ->mprotect(). As long as folks buy into the
> argument that intent needs to be checked at mmap() time, they obviously
> need to be checked at mprotect() too.
> Jarkko, if you want to try and rewrite the changelog, capturing the
> discussion here and reply, I think I can ack the resulting patch. I
> don't know if that will satisfy the request from Boris from an ack from
> a "mm person", but we can at least start there. :)

I think what it needs, based on what I've read, is the step by step
description of the EMODPE scenarion without this callback and with it.

I think other important thing to underline is that an LSM or any other
security measure can only do a sane decision when the enclave is loaded.
At that point we know the source (vm_file).

I.e. when you are doing mmap() or mprotect() you don't have that
information. The permissions kind of describe the contact made at that
point of time.

> Please be judicious in what you include in the changelog. There's been
> a lot of detritus in them. Let's keep it as short, sweet, simple and on
> topic as we can.

Of course.


 \ /
  Last update: 2020-09-28 02:54    [W:0.145 / U:1.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site