On Mon, Jun 03, 2019 at 02:23:36PM -0700, Sean Christopherson wrote:
> Please read through the RFC, I think it address a lot of your questions.
> Hopefully that will help us avoid some thrash.
I promise to read it through with detail albeit I just said that as a
patch set it is broken :-)
On Thu, May 30, 2019 at 02:36:01PM -0700, Sean Christopherson wrote:
> Assuming MRENCLAVE generated by Graphene or any other hosting scheme are
> stable[1], then avoiding EXEC means the user can effectively
> whitelist what enclaves are runnable by Graphene, even if the kernel
> doesn't implement
On Thu, May 30, 2019 at 11:01:10AM -0700, Sean Christopherson wrote:
> - Requires enclave builder to mark enclave pages executable in the
> non-enclave VMAs, which may unnecessarily require EXECMOD on the
> source file, or even worse, EXECMEM, and potentially increases the
> attack
On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > What is the "source file" i.e. the target of the check? Enclave file,
> > sigstruct file, or /dev/sgx/enclave?
>
> Enclave file -- that is, the file backing the vma from which the data
> is loaded.
Wonder why KVM gets away
On Thu, May 30, 2019 at 07:31:14AM -0700, Andy Lutomirski wrote:
> - To create an X mapping of an enclave page that came from EADD, you
> need EXECUTE on the source file. Optionally, we could also permit
> this if you have EXECMOD.
Source file? EADD ioctl takes memory buffer in right now.
>
On Thu, May 30, 2019 at 11:04:24AM -0400, Stephen Smalley wrote:
> Does this occur for both setting initial permissions and runtime permissions
> or just runtime? Both userspace- and driver-initiated mmap/mprotect
> operations or just userspace-initiated ones? Does the driver use interfaces
>
On Mon, Jun 03, 2019 at 11:54:05PM +0300, Jarkko Sakkinen wrote:
> On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > What is the "source file" i.e. the target of the check? Enclave file,
> > > sigstruct file, or /dev/sgx/enclave?
> >
> > Enclave file -- that is, the file
On Mon, Jun 3, 2019 at 1:54 PM Jarkko Sakkinen
wrote:
>
> On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > What is the "source file" i.e. the target of the check? Enclave file,
> > > sigstruct file, or /dev/sgx/enclave?
> >
> > Enclave file -- that is, the file backing the
On Thu, May 30, 2019 at 02:36:01PM -0700, Sean Christopherson wrote:
Good morning, I hope everyone had a pleasant weekend.
> Assuming MRENCLAVE generated by Graphene or any other hosting scheme
> are stable[1], then avoiding EXEC means the user can
> effectively whitelist what enclaves are
On Thu, May 30, 2019 at 02:48:43PM -0700, Xing, Cedric wrote:
> So I think the same rationale applies to enclaves. Your original idea of
> MAXPERM is the policy set forth by system admin and shall *never* change at
> runtime. If an enclave is dynamically linked and needs to bring in code pages
>
On Thu, May 30, 2019 at 2:16 PM Sean Christopherson
wrote:
>
> On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote:
> > On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
> > wrote:
> > >
> > > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > > Enclave file --
Hi Andy,
I'm just curious how Sean convinced you that "MAXPERM doesn't work". More
specifically, I'm objecting to the statement of "the enclave loader won't know
at load time whether a given EAUG-ed page will ever be executed".
I'm still new to LSM so my understanding may not be correct. But I
On Thu, May 30, 2019 at 02:23:07PM -0700, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 2:16 PM Sean Christopherson
> wrote:
> >
> > On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote:
> > > On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
> > > wrote:
> > > >
> > > > On Thu,
On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
> wrote:
> >
> > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > Enclave file -- that is, the file backing the vma from which the data is
> > > loaded.
>
On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
wrote:
>
> On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > On Thu, May 30, 2019 at 8:04 AM Stephen Smalley wrote:
> > >
> > > On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > > > Hi all-
> > > >
> > > > After an offline
On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 8:04 AM Stephen Smalley wrote:
> >
> > On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > > Hi all-
> > >
> > > After an offline discussion with Sean yesterday, here are some updates
> > > to the user API
On Wed, May 29, 2019 at 10:38:06PM -0700, Xing, Cedric wrote:
> > From: Christopherson, Sean J
> > Sent: Tuesday, May 28, 2019 2:41 PM
> >
> > On Tue, May 28, 2019 at 01:48:02PM -0700, Andy Lutomirski wrote:
> > > On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
> > > wrote:
> > > >
> > > >
On Thu, May 30, 2019 at 8:04 AM Stephen Smalley wrote:
>
> On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > Hi all-
> >
> > After an offline discussion with Sean yesterday, here are some updates
> > to the user API parts of my proposal.
> >
> > Unfortunately, Sean convinced me that MAXPERM doesn't
On 5/30/19 10:31 AM, Andy Lutomirski wrote:
Hi all-
After an offline discussion with Sean yesterday, here are some updates
to the user API parts of my proposal.
Unfortunately, Sean convinced me that MAXPERM doesn't work the way I
described it because, for SGX2, the enclave loader won't know at
Hi all-
After an offline discussion with Sean yesterday, here are some updates
to the user API parts of my proposal.
Unfortunately, Sean convinced me that MAXPERM doesn't work the way I
described it because, for SGX2, the enclave loader won't know at load
time whether a given EAUG-ed page will
On 5/30/19 2:12 AM, Xing, Cedric wrote:
From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-ow...@vger.kernel.org]
On Behalf
Of Stephen Smalley
Sent: Wednesday, May 29, 2019 7:08 AM
On 5/28/19 4:24 PM, Sean Christopherson wrote:
On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric
> From: linux-sgx-ow...@vger.kernel.org
> [mailto:linux-sgx-ow...@vger.kernel.org] On Behalf
> Of Stephen Smalley
> Sent: Wednesday, May 29, 2019 7:08 AM
>
> On 5/28/19 4:24 PM, Sean Christopherson wrote:
> > On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote:
> >>> From: Andy
> From: Christopherson, Sean J
> Sent: Tuesday, May 28, 2019 2:41 PM
>
> On Tue, May 28, 2019 at 01:48:02PM -0700, Andy Lutomirski wrote:
> > On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
> > wrote:
> > >
> > > Actually, I think we do have everything we need from an LSM perspective.
> > >
On 5/28/19 4:24 PM, Sean Christopherson wrote:
On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote:
From: Andy Lutomirski [mailto:l...@kernel.org]
Sent: Saturday, May 25, 2019 5:58 PM
On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote:
If we think of EADD as a way of mmap()'ing an
On Tue, May 28, 2019 at 01:48:02PM -0700, Andy Lutomirski wrote:
> On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
> wrote:
> >
> > Actually, I think we do have everything we need from an LSM perspective.
> > LSMs just need to understand that sgx_enclave_load() with a NULL vma
> > implies a
On Tue, May 28, 2019 at 1:24 PM Sean Christopherson
wrote:
>
> On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote:
> > > From: Andy Lutomirski [mailto:l...@kernel.org]
> > > Sent: Saturday, May 25, 2019 5:58 PM
> > >
> > > On Sat, May 25, 2019 at 3:40 PM Xing, Cedric
> > > wrote:
> >
On Sat, May 25, 2019 at 11:09:38PM -0700, Xing, Cedric wrote:
> > From: Andy Lutomirski [mailto:l...@kernel.org]
> > Sent: Saturday, May 25, 2019 5:58 PM
> >
> > On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote:
> > >
> > > If we think of EADD as a way of mmap()'ing an enclave file into
On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote:
> On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
> wrote:
> >
> > On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
> > > > But actually,
On Mon, May 27, 2019 at 04:34:31PM +0300, Jarkko Sakkinen wrote:
> On Thu, May 23, 2019 at 07:17:52AM -0700, Sean Christopherson wrote:
> > 1. Do nothing. Userspace would essentially be required to mmap() the
> > enclave after EINIT, which is ugly but not breaking since userspace
> >
On Thu, May 23, 2019 at 07:17:52AM -0700, Sean Christopherson wrote:
> 1. Do nothing. Userspace would essentially be required to mmap() the
> enclave after EINIT, which is ugly but not breaking since userspace
> could mmap() the enclave with a placeholder VMA prior to building
>
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Saturday, May 25, 2019 5:58 PM
>
> On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote:
> >
> > > From: Andy Lutomirski [mailto:l...@amacapital.net]
> > > Sent: Friday, May 24, 2019 4:42 PM
> > >
> > > > On May 24, 2019, at 3:41 PM, Sean
On Sat, May 25, 2019 at 3:40 PM Xing, Cedric wrote:
>
> > From: Andy Lutomirski [mailto:l...@amacapital.net]
> > Sent: Friday, May 24, 2019 4:42 PM
> >
> > > On May 24, 2019, at 3:41 PM, Sean Christopherson
> > > wrote:
> > >
> > >> On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Friday, May 24, 2019 4:42 PM
>
> > On May 24, 2019, at 3:41 PM, Sean Christopherson
> > wrote:
> >
> >> On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski wrote:
> >> On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
> >>
On Fri, May 24, 2019 at 01:03:33PM -0700, Sean Christopherson wrote:
Good morning, I hope the weekend is going well for everyone. Skunky
holiday weather out here in West-Central Minnesota.
> On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> > If we go this route, the only
> On May 24, 2019, at 3:41 PM, Sean Christopherson
> wrote:
>
>> On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski wrote:
>> On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
>> wrote:
>>>
On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> On Fri, May 24,
On Fri, May 24, 2019 at 02:27:34PM -0700, Andy Lutomirski wrote:
> On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
> wrote:
> >
> > On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> > > On Fri, May 24, 2019 at 11:34 AM Xing, Cedric
> > > wrote:
> > > >
> > > > If "initial
On Fri, May 24, 2019 at 1:03 PM Sean Christopherson
wrote:
>
> On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> > On Fri, May 24, 2019 at 11:34 AM Xing, Cedric wrote:
> > >
> > > If "initial permissions" for enclaves are less restrictive than shared
> > > objects, then it'd
On Fri, May 24, 2019 at 01:42:13PM -0700, Xing, Cedric wrote:
> > From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> > ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> > Sent: Friday, May 24, 2019 12:14 PM
> >
> > My point is that enclaves have different properties than shared
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Friday, May 24, 2019 1:04 PM
>
> On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> > On Fri, May 24, 2019 at 11:34 AM Xing, Cedric
> wrote:
> > >
> > > If
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Friday, May 24, 2019 12:14 PM
>
> My point is that enclaves have different properties than shared objects.
>
> Normal LSM behavior with regard to executing files is to
On Fri, May 24, 2019 at 12:37:44PM -0700, Andy Lutomirski wrote:
> On Fri, May 24, 2019 at 11:34 AM Xing, Cedric wrote:
> >
> > If "initial permissions" for enclaves are less restrictive than shared
> > objects, then it'd become a backdoor for circumventing LSM when enclave
> > whitelisting is
On Fri, May 24, 2019 at 11:34 AM Xing, Cedric wrote:
>
> > From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> > ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> > Sent: Friday, May 24, 2019 10:55 AM
> >
> > On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson wrote:
> >
On Fri, May 24, 2019 at 12:13 PM Sean Christopherson
wrote:
>
> On Fri, May 24, 2019 at 11:34:32AM -0700, Xing, Cedric wrote:
> > > From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> > > ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> > > Sent: Friday, May 24, 2019 10:55 AM
> I
On Fri, May 24, 2019 at 11:34:32AM -0700, Xing, Cedric wrote:
> > From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> > ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> > Sent: Friday, May 24, 2019 10:55 AM
> >
> > On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson
> From: linux-sgx-ow...@vger.kernel.org [mailto:linux-sgx-
> ow...@vger.kernel.org] On Behalf Of Sean Christopherson
> Sent: Friday, May 24, 2019 10:55 AM
>
> On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson wrote:
> > Hmm, I've been thinking more about pulling permissions from the
On Fri, May 24, 2019 at 10:54:34AM -0700, Andy Lutomirski wrote:
>
> > On May 24, 2019, at 10:42 AM, Sean Christopherson
> > wrote:
> >
> > Hmm, I've been thinking more about pulling permissions from the source
> > page. Conceptually I'm not sure we need to meet the same requirements as
> >
On Fri, May 24, 2019 at 10:42:43AM -0700, Sean Christopherson wrote:
> Hmm, I've been thinking more about pulling permissions from the source
> page. Conceptually I'm not sure we need to meet the same requirements as
> non-enclave DSOs while the enclave is being built, i.e. do we really need
> to
> On May 24, 2019, at 10:42 AM, Sean Christopherson
> wrote:
>
>> On Fri, May 24, 2019 at 11:41:29AM -0400, Stephen Smalley wrote:
>>> On 5/24/19 3:24 AM, Xing, Cedric wrote:
>>> /**
>>> * Summary:
>>> * - The enclave file resembles a shared object that contains RO/RX/RW
>>> segments
>>> *
> On May 24, 2019, at 10:07 AM, Sean Christopherson
> wrote:
>
>> On Fri, May 24, 2019 at 09:43:27AM -0700, Andy Lutomirski wrote:
>>> On Fri, May 24, 2019 at 12:24 AM Xing, Cedric wrote:
>>> /**
>>> * Summary:
>>> * - The enclave file resembles a shared object that contains RO/RX/RW
>>>
On Fri, May 24, 2019 at 11:41:29AM -0400, Stephen Smalley wrote:
> On 5/24/19 3:24 AM, Xing, Cedric wrote:
> >/**
> > * Summary:
> > * - The enclave file resembles a shared object that contains RO/RX/RW
> > segments
> > * - FILE__* are assigned to /dev/sgx/enclave, to determine acceptable
> >
On Fri, May 24, 2019 at 09:43:27AM -0700, Andy Lutomirski wrote:
> On Fri, May 24, 2019 at 12:24 AM Xing, Cedric wrote:
> > /**
> > * Summary:
> > * - The enclave file resembles a shared object that contains RO/RX/RW
> > segments
> > * - FILE__* are assigned to /dev/sgx/enclave, to determine
Hi Stephen,
> On 5/24/19 3:24 AM, Xing, Cedric wrote:
> >
> > When we talk about EPC page permissions with SGX2 in mind, I think we
> should distinguish between initial permissions and runtime permissions.
> Initial permissions refer to the page permissions set at EADD. They are
> technically set
On Fri, May 24, 2019 at 12:24 AM Xing, Cedric wrote:
>
> Hi Andy,
>
> > From: Andy Lutomirski [mailto:l...@kernel.org]
> > Sent: Thursday, May 23, 2019 6:18 PM
> >
> > On Thu, May 23, 2019 at 4:40 PM Sean Christopherson
> >
> > wrote:
> > >
> > > On Thu, May 23, 2019 at 08:38:17AM -0700, Andy
On 5/24/19 3:24 AM, Xing, Cedric wrote:
Hi Andy,
From: Andy Lutomirski [mailto:l...@kernel.org]
Sent: Thursday, May 23, 2019 6:18 PM
On Thu, May 23, 2019 at 4:40 PM Sean Christopherson
wrote:
On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote:
On Thu, May 23, 2019 at 7:17 AM
On 5/23/19 11:38 AM, Andy Lutomirski wrote:
On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
wrote:
On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
But actually, there's no need to disallow mmap() after
Hi Andy,
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: Thursday, May 23, 2019 6:18 PM
>
> On Thu, May 23, 2019 at 4:40 PM Sean Christopherson
>
> wrote:
> >
> > On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote:
> > > On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
On Thu, May 23, 2019 at 4:40 PM Sean Christopherson
wrote:
>
> On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote:
> > On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
> > wrote:
> > >
> > > On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
> > > > On Wed, May 22,
On Thu, May 23, 2019 at 08:38:17AM -0700, Andy Lutomirski wrote:
> On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
> wrote:
> >
> > On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
> > > > But actually,
On Thu, May 23, 2019 at 07:17:52AM -0700, Sean Christopherson wrote:
> On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
> > On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
> > > But actually, there's no need to disallow mmap() after ECREATE since the
> > > LSM
On Thu, May 23, 2019 at 7:17 AM Sean Christopherson
wrote:
>
> On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
> > On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
> > > But actually, there's no need to disallow mmap() after ECREATE since the
> > > LSM checks
On Thu, May 23, 2019 at 01:26:28PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
> > But actually, there's no need to disallow mmap() after ECREATE since the
> > LSM checks also apply to mmap(), e.g. FILE__EXECUTE would be needed to
> > mmap()
On Wed, May 22, 2019 at 07:35:17PM -0700, Sean Christopherson wrote:
> But actually, there's no need to disallow mmap() after ECREATE since the
> LSM checks also apply to mmap(), e.g. FILE__EXECUTE would be needed to
> mmap() any enclave pages PROT_EXEC. I guess my past self thought mmap()
>
On Thu, May 23, 2019 at 11:10:48AM +0300, Jarkko Sakkinen wrote:
> On Wed, May 22, 2019 at 03:42:45PM -0700, Andy Lutomirski wrote:
> > As far as I know from this whole discussion, we still haven't come up
> > with any credible way to avoid tracking, per enclave page, whether
> > that page came
On Wed, May 22, 2019 at 03:42:45PM -0700, Andy Lutomirski wrote:
> As far as I know from this whole discussion, we still haven't come up
> with any credible way to avoid tracking, per enclave page, whether
> that page came from unmodified PROT_EXEC memory.
So is this in the context that the
On Wed, May 22, 2019 at 03:42:45PM -0700, Andy Lutomirski wrote:
> On Wed, May 22, 2019 at 8:38 AM Sean Christopherson
> wrote:
> >
> > And that straight up doesn't work with the v20 driver because mmap() with
> > the enclave_fd will run through sgx_get_unmapped_area(), which also does
> > the
On Wed, May 22, 2019 at 8:38 AM Sean Christopherson
wrote:
>
> On Wed, May 22, 2019 at 09:56:30AM -0400, Stephen Smalley wrote:
> > On 5/22/19 9:22 AM, Jarkko Sakkinen wrote:
> > >On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
> > >>On Tue, May 21, 2019 at 08:51:40AM -0700, Sean
On Wed, May 22, 2019 at 09:56:30AM -0400, Stephen Smalley wrote:
> On 5/22/19 9:22 AM, Jarkko Sakkinen wrote:
> >On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
> >>On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
> >>>Except that mmap() is more or less
On 5/22/19 9:22 AM, Jarkko Sakkinen wrote:
On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
Except that mmap() is more or less required to guarantee that ELRANGE
established by ECREATE is available. And we
On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
> > Except that mmap() is more or less required to guarantee that ELRANGE
> > established by ECREATE is available. And we want to disallow mmap() as
> > soon as
On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
> Except that mmap() is more or less required to guarantee that ELRANGE
> established by ECREATE is available. And we want to disallow mmap() as
> soon as the first EADD is done so that userspace can't remap the enclave's
> VMAs
On Tue, May 21, 2019 at 03:24:18PM +, Jethro Beekman wrote:
> On 2019-05-21 08:19, Jarkko Sakkinen wrote:
> > We could even disallow mmap() before EINIT done.
> This would be extremely annoying in software because now you have to save
> the all the page permissions somewhere between EADD and
On Tue, May 21, 2019 at 06:19:37PM +0300, Jarkko Sakkinen wrote:
> On Mon, May 20, 2019 at 02:41:05PM +0300, Jarkko Sakkinen wrote:
> > On Thu, May 16, 2019 at 05:26:15PM -0700, Andy Lutomirski wrote:
> > > Is userspace actually requred to mmap() the enclave prior to EADDing
> > > things?
> >
>
On 2019-05-21 08:19, Jarkko Sakkinen wrote:
We could even disallow mmap() before EINIT done.
This would be extremely annoying in software because now you have to
save the all the page permissions somewhere between EADD and mprotect.
--
Jethro Beekman | Fortanix
smime.p7s
Description:
On Mon, May 20, 2019 at 02:41:05PM +0300, Jarkko Sakkinen wrote:
> On Thu, May 16, 2019 at 05:26:15PM -0700, Andy Lutomirski wrote:
> > Is userspace actually requred to mmap() the enclave prior to EADDing things?
>
> Nope, not since v20. Here is what I wrote about API to the kernel
>
On Fri, May 17, 2019 at 08:41:28AM -0700, Sean Christopherson wrote:
> It was a requirement prior to the API rework in v20, i.e. unless someone
> was really quick on the draw after the v20 update all existing userspace
> implementations mmap() the enclave before ECREATE. Requiring a valid
>
On Thu, May 16, 2019 at 05:26:15PM -0700, Andy Lutomirski wrote:
> Is userspace actually requred to mmap() the enclave prior to EADDing things?
Nope, not since v20. Here is what I wrote about API to the kernel
documentation:
"The enclave life-cycle starts by opening `/dev/sgx/enclave`. After
On Thu, May 16, 2019 at 05:03:31PM -0700, Sean Christopherson wrote:
> The SGX ioctl() would need to take mmap_sem for write, but we can mitigate
> that issue by changing the ioctl() to take a range of memory instead of a
> single page. That'd also provide "EADD batching" that folks have
>
On Thu, May 16, 2019 at 02:02:58PM -0700, Andy Lutomirski wrote:
> That certainly *could* be done, and I guess the decision could be left
> to the LSMs, but I'm not convinced this adds value. What security use
> case does this cover that isn't already covered by requiring EXECUTE
> (e.g. lib_t)
On Thu, May 16, 2019 at 03:45:50PM -0700, Sean Christopherson wrote:
> On Thu, May 16, 2019 at 02:02:58PM -0700, Andy Lutomirski wrote:
> > > On May 15, 2019, at 10:16 PM, Jarkko Sakkinen
> > > wrote:
> > > There is a problem here though. Usually the enclave itself is just a
> > > loader that
On Thu, May 16, 2019 at 05:24:33PM +1000, James Morris wrote:
Good morning, I hope everyone had a pleasant weekend.
James, I believe the last time our paths crossed was at the Linux
Security Summit in Seattle, I trust you have been well since then.
> On Wed, 15 May 2019, Andy Lutomirski wrote:
On Fri, May 17, 2019 at 04:09:22PM -0400, Stephen Smalley wrote:
> On 5/17/19 3:28 PM, Sean Christopherson wrote:
> >On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote:
> >Yep, and that's by design in the overall proposal. The trick is that
> >ENCLAVE_ADD takes a source VMA and
On 5/17/19 4:14 PM, Andy Lutomirski wrote:
On May 17, 2019, at 1:09 PM, Stephen Smalley wrote:
On 5/17/19 3:28 PM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote:
On 5/17/19 1:12 PM, Andy Lutomirski wrote:
How can that work? Unless the API
> On May 17, 2019, at 1:09 PM, Stephen Smalley wrote:
>
>> On 5/17/19 3:28 PM, Sean Christopherson wrote:
>>> On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote:
On 5/17/19 1:12 PM, Andy Lutomirski wrote:
How can that work? Unless the API changes fairly radically,
On 5/17/19 3:28 PM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote:
On 5/17/19 1:12 PM, Andy Lutomirski wrote:
How can that work? Unless the API changes fairly radically, users
fundamentally need to both write and execute the enclave. Some of it
On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote:
> On 5/17/19 1:12 PM, Andy Lutomirski wrote:
> >
> >How can that work? Unless the API changes fairly radically, users
> >fundamentally need to both write and execute the enclave. Some of it will
> >be written only from already
On 5/17/19 2:05 PM, Stephen Smalley wrote:
On 5/17/19 1:12 PM, Andy Lutomirski wrote:
On May 17, 2019, at 9:37 AM, Stephen Smalley wrote:
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley
> On May 17, 2019, at 11:21 AM, Sean Christopherson
> wrote:
>
>> On Fri, May 17, 2019 at 11:04:22AM -0700, Linus Torvalds wrote:
>> On Fri, May 17, 2019 at 10:55 AM Sean Christopherson
>> wrote:
>>>
>>> In this snippet, IS_PRIVATE() is true for anon inodes, false for
>>> /dev/sgx/enclave.
On Fri, May 17, 2019 at 11:33:30AM -0700, Linus Torvalds wrote:
> On Fri, May 17, 2019 at 11:21 AM Sean Christopherson
> wrote:
> >
> > I agree that conceptually EPC is private memory, but because EPC is
> > managed as a separate memory pool, SGX tags it VM_PFNMAP and manually
> > inserts PFNs,
On Fri, May 17, 2019 at 11:21 AM Sean Christopherson
wrote:
>
> I agree that conceptually EPC is private memory, but because EPC is
> managed as a separate memory pool, SGX tags it VM_PFNMAP and manually
> inserts PFNs, i.e. EPC effectively it gets classified as IO memory.
>
> And
On Fri, May 17, 2019 at 11:04:22AM -0700, Linus Torvalds wrote:
> On Fri, May 17, 2019 at 10:55 AM Sean Christopherson
> wrote:
> >
> > In this snippet, IS_PRIVATE() is true for anon inodes, false for
> > /dev/sgx/enclave. Because EPC memory is always shared, SELinux will never
> > check
On 5/17/19 1:50 PM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 01:42:50PM -0400, Stephen Smalley wrote:
On 5/17/19 1:29 PM, Sean Christopherson wrote:
AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow
*any* enclave/process to map EPC as RWX. Moving to anon
On Fri, May 17, 2019 at 10:55 AM Sean Christopherson
wrote:
>
> In this snippet, IS_PRIVATE() is true for anon inodes, false for
> /dev/sgx/enclave. Because EPC memory is always shared, SELinux will never
> check PROCESS__EXECMEM for mprotect() on/dev/sgx/enclave.
Why _does_ the memory have to
On 5/17/19 1:12 PM, Andy Lutomirski wrote:
On May 17, 2019, at 9:37 AM, Stephen Smalley wrote:
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
On 5/16/19 6:23 PM, Xing, Cedric
On Fri, May 17, 2019 at 10:43:01AM -0700, Andy Lutomirski wrote:
>
> > On May 17, 2019, at 10:29 AM, Sean Christopherson
> > wrote:
> >
> > AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow
> > *any* enclave/process to map EPC as RWX. Moving to anon inodes and thus
>
On Fri, May 17, 2019 at 01:42:50PM -0400, Stephen Smalley wrote:
> On 5/17/19 1:29 PM, Sean Christopherson wrote:
> >AIUI, having FILE__WRITE and FILE__EXECUTE on /dev/sgx/enclave would allow
> >*any* enclave/process to map EPC as RWX. Moving to anon inodes and thus
> >PROCESS__EXECMEM achieves
> On May 17, 2019, at 10:29 AM, Sean Christopherson
> wrote:
>
>> On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote:
>>> On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
I think we may want to change the SGX API to alloc an
On 5/17/19 1:29 PM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote:
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
I think we may want to change the SGX API to alloc an anon inode for each
enclave instead
On Fri, May 17, 2019 at 12:37:40PM -0400, Stephen Smalley wrote:
> On 5/17/19 12:20 PM, Stephen Smalley wrote:
> >On 5/17/19 11:09 AM, Sean Christopherson wrote:
> >>I think we may want to change the SGX API to alloc an anon inode for each
> >>enclave instead of hanging every enclave off of the
> On May 17, 2019, at 9:37 AM, Stephen Smalley wrote:
>
>> On 5/17/19 12:20 PM, Stephen Smalley wrote:
>>> On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
> On 5/16/19 6:23 PM, Xing, Cedric wrote:
> I thought
On 5/17/19 12:20 PM, Stephen Smalley wrote:
On 5/17/19 11:09 AM, Sean Christopherson wrote:
On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote:
On 5/16/19 6:23 PM, Xing, Cedric wrote:
I thought EXECMOD applied to files (and memory mappings backed by
them) but
I was probably
1 - 100 of 198 matches
Mail list logo
