[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <960B34DE67B9E140824F1DCDEC400C0F65503F51@ORSMSX116.amr.corp.intel.com>
Date: Fri, 14 Jun 2019 00:31:07 +0000
From: "Xing, Cedric" <cedric.xing@...el.com>
To: "Christopherson, Sean J" <sean.j.christopherson@...el.com>
CC: Stephen Smalley <sds@...ho.nsa.gov>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"selinux@...r.kernel.org" <selinux@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
"jarkko.sakkinen@...ux.intel.com" <jarkko.sakkinen@...ux.intel.com>,
"luto@...nel.org" <luto@...nel.org>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"serge@...lyn.com" <serge@...lyn.com>,
"paul@...l-moore.com" <paul@...l-moore.com>,
"eparis@...isplace.org" <eparis@...isplace.org>,
"jethro@...tanix.com" <jethro@...tanix.com>,
"Hansen, Dave" <dave.hansen@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"pmccallum@...hat.com" <pmccallum@...hat.com>,
"Ayoun, Serge" <serge.ayoun@...el.com>,
"Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
"Huang, Haitao" <haitao.huang@...el.com>,
"andriy.shevchenko@...ux.intel.com"
<andriy.shevchenko@...ux.intel.com>,
"Svahn, Kai" <kai.svahn@...el.com>, "bp@...en8.de" <bp@...en8.de>,
"josh@...htriplett.org" <josh@...htriplett.org>,
"Huang, Kai" <kai.huang@...el.com>,
"rientjes@...gle.com" <rientjes@...gle.com>,
"Roberts, William C" <william.c.roberts@...el.com>,
"Tricca, Philip B" <philip.b.tricca@...el.com>
Subject: RE: [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in
SELinux
> From: Christopherson, Sean J
> Sent: Thursday, June 13, 2019 4:18 PM
>
> On Thu, Jun 13, 2019 at 04:03:24PM -0700, Xing, Cedric wrote:
> > > From: Stephen Smalley [mailto:sds@...ho.nsa.gov]
> > > Sent: Thursday, June 13, 2019 10:02 AM
> > >
> > > > My RFC series[1] implements #1. My understanding is that Andy
> > > > (Lutomirski) prefers #2. Cedric's RFC series implements #3.
> > > >
> > > > Perhaps the easiest way to make forward progress is to rule out
> the
> > > > options we absolutely *don't* want by focusing on the potentially
> > > > blocking issue with each option:
> > > >
> > > > #1 - SGX UAPI funkiness
> > > >
> > > > #2 - Auditing complexity, potential enclave lock contention
> > > >
> > > > #3 - Pushing SGX details into LSMs and complexity of kernel
> > > > implementation
> > > >
> > > >
> > > > [1]
> > > > https://lkml.kernel.org/r/20190606021145.12604-1-
> sean.j.christopherson
> > > > @intel.com
> > >
> > > Given the complexity tradeoff, what is the clear motivating example
> for
> > > why #1 isn't the obvious choice? That the enclave loader has no way
> of
> > > knowing a priori whether the enclave will require W->X or WX? But
> > > aren't we better off requiring enclaves to be explicitly marked as
> > > needing such so that we can make a more informed decision about
> whether
> > > to load them in the first place?
> >
> > Are you asking this question at a) page granularity, b) file
> granularity or
> > c) enclave (potentially comprised of multiple executable files)
> granularity?
> >
> > #b is what we have on regular executable files and shared objects (i.e.
> > FILE__EXECMOD). We all know how to do that.
> >
> > #c is kind of new but could be done via some proxy file (e.g.
> sigstruct file)
> > hence reduced to #b.
> >
> > #a is problematic. It'd require compilers/linkers to generate such
> > information, and proper executable image file format to carry that
> > information, to be eventually picked up the loader. SELinux doesn't
> have
> > PAGE__EXECMOD I guess is because it is generally considered
> impractical.
> >
> > Option #1 however requires #a because the driver doesn't track which
> page was
> > loaded from which file, otherwise it can no longer be qualified
> "simple". Or
> > we could just implement #c, which will make all options simpler. But I
> guess
> > #b is still preferred, to be aligned with what SELinux is enforcing
> today on
> > regular memory pages.o
>
> Option #1 doesn't require (a). The checks will happen for every page,
> but in the RFCs I sent, the policies are still attached to files and
> processes, i.e. (b).
I was talking at the UAPI level - i.e. your ioctl requires ALLOW_* at page granularity, hence #a.
Powered by blists - more mailing lists