linux-kernel - Re: [PATCH v22 00/24] Intel SGX foundations

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20191002234247.GA16314@linux.intel.com>
Date:   Thu, 3 Oct 2019 02:42:47 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        linux-sgx@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        nhorman@...hat.com, npmccallum@...hat.com,
        "Ayoun, Serge" <serge.ayoun@...el.com>,
        "Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Svahn, Kai" <kai.svahn@...el.com>, Borislav Petkov <bp@...en8.de>,
        Josh Triplett <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        David Rientjes <rientjes@...gle.com>,
        "Xing, Cedric" <cedric.xing@...el.com>
Subject: Re: [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