Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()

[Andy Lutomirski]

> On Oct 26, 2020, at 3:51 AM, Dr. Greg <greg@xxxxxxxxxxxx> wrote:
> 
> On Sat, Oct 24, 2020 at 08:33:21AM -0700, Andy Lutomirski wrote:
> 
> The easiest way to generically block dynamic code loading is to not
> allow the ENCLS[EAUG] instruction to be executed, the purpose of which
> is to augment a defined but sparse ELRANGE with additional physical
> pages from the EPC.  It doesn't require ->mprotect or anything else,
> just a physical decision by the OS to not allow execution of that
> instruction.

I’m pretty sure that one can dynamically load code without EAUG. It
would require preallocation, but I can’t see why EAUG changes anything from a security policy perspective.

> 
> All of which is consistent with my recomendation for a global disable
> knob on the kernel command-line for sites that do not want to tolerate
> completely anonymous code execution.
> 
> Since this driver does not yet support EDMM, the most immediate
> situation that we are dealing with are the potential security
> implications of SGX2 ENCLU instructions being executed inside of an
> enclave.  The most principal issue is the ENCLU[EMODPE] instruction
> that allows a running enclave to extend the current permissions of a
> page.
> 
> I've been assuming that Sean's desire for ->mprotect is to block the
> ability of an initialized enclave, on a non-EDMM enabled driver, to
> collaborate with its untrusted component to self-modify its page
> permissions and thus allow execution of code that the operating system
> has no visibility into.  That would make far more sense then the
> notion of someone trying to create an LSM that makes page by page
> security decisions.

If you remove every mention of EDMM from that description, and you realize that the ability for LSMs to implement this sort of policy is basically the same as for the core SGX code to do so, then I agree.

The addition of EDMM will not change anything here per se, except that we’re a lot more likely to encounter enclaves doing interesting things with EMODPE once EDMM is enabled.

> 
> The open question in all of this is that the EDMM paper, as well as
> the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside
> of a running enclave.  I'm assuming that this does NOT mean that once
> a context of execution is running in enclave mode it would be capable
> of evading standard page protections but the 'immediate' is somewhat
> disquieting and probably deserves clarification, despite Dave Hansen's
> adament concerns about discussing the instruction... :-)

If EMODPE writes an entry into the TLB that violates PTE permissions, then we have a real problem. I would be very surprised if this were to be the case.