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: <960B34DE67B9E140824F1DCDEC400C0F4E886073@ORSMSX116.amr.corp.intel.com>
Date:   Fri, 10 May 2019 18:44:56 +0000
From:   "Xing, Cedric" <cedric.xing@...el.com>
To:     "Hansen, Dave" <dave.hansen@...el.com>,
        Jethro Beekman <jethro@...tanix.com>,
        Andy Lutomirski <luto@...nel.org>
CC:     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

Hi Dave,

> On 5/10/19 10:37 AM, Jethro Beekman wrote:
> > It does assume a specific format, namely, that the memory layout
> > (including page types/permissions) of the enclave can be represented
> in
> > a "flat file" on disk, or at least that the enclave memory contents
> > consist of 4096-byte chunks in that file.
> 
> I _think_ Cedric's point is that, to the kernel,
> /lib/x86_64-linux-gnu/libc.so.6 is a "flat file" because the kernel
> doesn't have any part in parsing the executable format of a shared
> library.
> 
> I actually don't know how it works, though.  Do we just just trust that
> the userspace parsing of the .so format is correct?  Do we just assume
> that any part of a file passing IMA checks can be PROT_EXEC?

The key idea here is for enclave files to "inherit" the checks applicable to regular shared objects. And how we are going to do it is for user process to map every loadable segment of the enclave file into its address space using *multiple* mmap() calls, just in the same way as dlopen() would do for loading regular shared objects. Then those open()/mmap() syscalls will trigger all applicable checks (by means of security_file_open(), security_mmap_file() and ima_file_mmap() hooks) transparently. That said, IMA/LSM implementations/policies will dictate the success/failure of those open()/mmap() syscalls. And by depending EPCM attributes on permissions of source VMAs, no EXEC page could be ever created unless the source page (which has to be EXEC, btw) has passed IMA/LSM checks (as if it were loaded from a regular shared object file).

-Cedric