lkml.org 
[lkml]   [2019]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v22 00/24] Intel SGX foundations
On Wed, Sep 25, 2019 at 05:32:04PM +0300, Jarkko Sakkinen wrote:
> On Tue, Sep 24, 2019 at 10:20:09AM -0700, Andy Lutomirski wrote:
> > > I think either can be considered post-upstreaming.
> >
> > Indeed, as long as the overall API is actually compatible with these
> > types of restrictions.
>
> I include LSM changes to the follow up versions of the patch set. This
> is done to help verify that the API is compatible (or make it easy to
> review).
>
> I think they should be merged only after SGX is in the upstream beause
> this will make testing and reviewing smaller details of the changes less
> edgy the for LSM maintainers when one can just grab the LSM changes and
> try them out with the mainline.

I added the following to the driver commit message:

"The permissions, which enclave page is added will set the limit for maximum
permissions that can be set for mmap() and mprotect(). This will
effectively allow to build different security schemes between producers and
consumers of enclaves. Later on we can increase granularity with LSM hooks
for page addition (i.e. for producers) and mapping of the enclave (i.e. for
consumers)"

Is this sufficient? I do not want to fuzz already large patch set with
LSM patches, which anyway could not be merged before other stuff is in
the mainline. I think my description nails how we make the overall API
to be "LSM ready", doesn't it? Or at minimum gives enough information to
argue whether or not the API is "LSM ready"...

I also added CC to linux-security-module to the driver commit.

/Jarkko

\
 
 \ /
  Last update: 2019-10-03 01:43    [W:0.095 / U:4.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site