Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
Date:   Sat, 24 Oct 2020 08:33:21 -0700
Message-Id: <3655FF47-15D7-4433-81B7-FC070E32B541@amacapital.net>
References: <20201024143744.GA17727@wind.enjellic.com>
Cc:     Sean Christopherson <sean.j.christopherson@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        Haitao Huang <haitao.huang@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
        linux-sgx@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Jethro Beekman <jethro@fortanix.com>,
        Darren Kenny <darren.kenny@oracle.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        asapek@google.com, Borislav Petkov <bp@alien8.de>,
        "Xing, Cedric" <cedric.xing@intel.com>, chenalexchen@google.com,
        Conrad Parker <conradparker@google.com>, cyhanish@google.com,
        "Huang, Haitao" <haitao.huang@intel.com>,
        Josh Triplett <josh@joshtriplett.org>,
        "Huang, Kai" <kai.huang@intel.com>,
        "Svahn, Kai" <kai.svahn@intel.com>, Keith Moyer <kmoy@google.com>,
        Christian Ludloff <ludloff@google.com>,
        Neil Horman <nhorman@redhat.com>,
        Nathaniel McCallum <npmccallum@redhat.com>,
        Patrick Uiterwijk <puiterwijk@redhat.com>,
        David Rientjes <rientjes@google.com>,
        Thomas Gleixner <tglx@linutronix.de>, yaozhangx@google.com
In-Reply-To: <20201024143744.GA17727@wind.enjellic.com>
To:     "Dr. Greg" <greg@enjellic.com>
Precedence: bulk


> On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@enjellic.com> wrote:
>=20

>=20
> I can't bring myself to believe that LSM's are going to be written
> that will be making enclave security decisions on a page by page
> basis.  Given what I have written above, I think all of this comes
> down to giving platform administrators one of three decisions, in
> order of most to least secure:
>=20
> 1.) Block dynamic code loading and execution.
>=20

I don=E2=80=99t understand what you=E2=80=99re trying to say. Unless we=E2=80=
=99re going to split enclaves into multiple VMAs with different permissions,=
 how do you expect to block dynamic code loading unless you have separate RW=
 and RX pages?  That would be =E2=80=9Cpage-by-page=E2=80=9D, right?

> 2.) Block access to RWX pages.
>=20
> 3.) The wild west - no restrictions on enclave page protection manipulatio=
n.
>=20
> =46rom a security perspective I would argue for the wisdom of making
> option 1 unconditional via a kernel command-line parameter.
>=20
> It may be that ->mprotect is the right mechanism to implement this.
> If that is the case, frame the discussion and documentation so that it
> reflects the actual security threat and the consideration and means
> for dealing with it.
>=20
> Hopefully all of this is useful to the stakeholders in this
> technology.
>=20
> Have a good weekend.
>=20
> Dr. Greg
>=20
> As always,
> Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
> Enjellic Systems Development, LLC     IOT platforms and edge devices.
> 4206 19th Ave. N.
> Fargo, ND  58102
> PH: 701-281-1686                      EMAIL: greg@enjellic.com
> --------------------------------------------------------------------------=
----
> "Politics is the business of getting power and privilege without possessin=
g
> merit."
>                                -- P.J. O'Rourke