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. /Jarkko
