linux-kernel - Re: [PATCH v38 10/24] mm: Add vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <4B39703F-280C-4AED-B4BB-047BD216B792@amacapital.net>
Date:   Mon, 26 Oct 2020 15:59:35 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     "Dr. Greg" <greg@...ellic.com>
Cc:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Haitao Huang <haitao.huang@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        linux-sgx@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Jethro Beekman <jethro@...tanix.com>,
        Darren Kenny <darren.kenny@...cle.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        asapek@...gle.com, Borislav Petkov <bp@...en8.de>,
        "Xing, Cedric" <cedric.xing@...el.com>, chenalexchen@...gle.com,
        Conrad Parker <conradparker@...gle.com>, cyhanish@...gle.com,
        "Huang, Haitao" <haitao.huang@...el.com>,
        Josh Triplett <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        "Svahn, Kai" <kai.svahn@...el.com>, Keith Moyer <kmoy@...gle.com>,
        Christian Ludloff <ludloff@...gle.com>,
        Neil Horman <nhorman@...hat.com>,
        Nathaniel McCallum <npmccallum@...hat.com>,
        Patrick Uiterwijk <puiterwijk@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>, yaozhangx@...gle.com
Subject: Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()


> On Oct 26, 2020, at 3:51 AM, Dr. Greg <greg@...ellic.com> 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.