linux-kernel - Re: [PATCH v20 00/28] Intel SGX1 support

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <op.z1tfjrj4wjvjmi@hhuan26-mobl.amr.corp.intel.com>
Date:   Wed, 15 May 2019 00:15:17 -0500
From:   "Haitao Huang" <haitao.huang@...ux.intel.com>
To:     "Andy Lutomirski" <luto@...nel.org>,
        "Xing, Cedric" <cedric.xing@...el.com>
Cc:     "Jethro Beekman" <jethro@...tanix.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Dr. Greg" <greg@...ellic.com>,
        "Jarkko Sakkinen" <jarkko.sakkinen@...ux.intel.com>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, "X86 ML" <x86@...nel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...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>,
        "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>
Subject: Re: [PATCH v20 00/28] Intel SGX1 support

On Tue, 14 May 2019 16:58:24 -0500, Xing, Cedric <cedric.xing@...el.com>  
wrote:

> Hi Everyone,
>
> I think we are talking about 2 different kinds of criteria for  
> determining the sanity of an enclave.
>
> The first kind determines an enclave's sanity by generally accepted good  
> practices. For example, no executable pages shall ever be writable.
>

We'll have to trust user space doing mmap with right permissions as  
SELinux does not enforce which segment to be RW and which to be RX. The  
file needs to have SELinux EXECUTE and WRITE both, if we need map some  
segments with RW and others with RX.

We could say EINIT would ensure user is doing the right thing because it  
would fail if user map permission wrongly. Then the extra mmaps are  
redundant of doing SIGSTRUCT verification.

Additionally, per Sean's comments, after EADD in current implementation,  
we will still need PROCESS_EXECMEM for mprotect on enclave fd to change  
some EPC pages PTE to RX before enclave can execute. So I don't think mmap  
the source enclave file would gain anything in addition to what your  
proposed security_sgx_initialize_enclave() does.

Since security_sgx_initialize_enclave() is a lot like launch control  
policy enforcement we discussed a lot and resolved, I tend to agree with  
Andy's assessment we can just do nothing for the initial merge and add  
hooks needed if someone wants them. And the initial merge would require  
the enclave hosting processes ask for PROCESS_EXECMEM permission to do  
mmap/mprotect with enclave fd.