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.z1saqpzxwjvjmi@hhuan26-mobl.amr.corp.intel.com>
Date:   Tue, 14 May 2019 09:33:51 -0500
From:   "Haitao Huang" <haitao.huang@...ux.intel.com>
To:     "Jethro Beekman" <jethro@...tanix.com>,
        "Andy Lutomirski" <luto@...nel.org>
Cc:     "Xing, Cedric" <cedric.xing@...el.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 Fri, 10 May 2019 14:22:34 -0500, Andy Lutomirski <luto@...nel.org>  
wrote:

> On Fri, May 10, 2019 at 12:04 PM Jethro Beekman <jethro@...tanix.com>  
> wrote:
>>
>> On 2019-05-10 11:56, Xing, Cedric wrote:
>> > Hi Jethro,
>> >
>> >> ELF files are explicitly designed such that you can map them (with  
>> mmap)
>> >> in 4096-byte chunks. However, sometimes there's overlap and you will
>> >> sometimes see that a particular offset is mapped twice because the  
>> first
>> >> half of the page in the file belongs to an RX range and the second  
>> half
>> >> to an R-only range. Also, ELF files don't (normally) describe stack,
>> >> heap, etc. which you do need for enclaves.
>> >
>> > You have probably misread my email. By mmap(), I meant the enclave  
>> file would be mapped via *multiple* mmap() calls, in the same way as  
>> what dlopen() would do in loading regular shared object. The intention  
>> here is to make the enclave file subject to the same checks as regular  
>> shared objects.
>>
>> No, I didn't misread your email. My original point still stands:
>> requiring that an enclave's memory is created from one or more mmap
>> calls of a file puts significant restrictions on the enclave's on-disk
>> representation.
>>
>
> For a tiny bit of background, Linux (AFAIK*) makes no effort to ensure
> the complete integrity of DSOs.  What Linux *does* do (if so
> configured) is to make sure that only approved data is mapped
> executable.  So, if you want to have some bytes be executable, those
> bytes have to come from a file that passes the relevant LSM and IMA
> checks.

Given this, I just want to step back a little to understand the exact  
issue that SGX is causing here for LSM/IMA. Sorry if I missed points  
discussed earlier.

By the time of EADD, enclave file is opened and should have passed IMA and  
SELinux policy enforcement gates if any. We really don't need extra mmaps  
on the enclave files to be IMA and SELinux compliant. We are loading  
enclave files as RO and copying those into EPC. An IMA policy can enforce  
RO files (or any file). And SELinux policy can say which processes can  
open the file for what permissions. No extra needed here.

And sgx enclaves are always signed and integrity protected and verified at  
the time of EINIT. So if EINIT passes, we know the content loaded  
(including permission flags) is matching the sigstruct.  But  
sigstruct/signature is part of the file, should be accounted for in IMA  
measurement of the whole file, so it is also verified by IMA during file  
open, right?

The only potential gap/difference comparing to regular ELF executable or  
DSOs:for enclaves, we need mmap portions of enclave linear range with RW  
to do EADD IOC, then mprotect those pages to RX after EINIT. But this is  
operated on enclave fd provided by driver. So we can have an SELinux  
policy say: only this type of processes is allowed to open enclave fd, and  
allowed to do mmap/mprotect with read, write, execute on it. Wouldn't that  
be enough?

Thanks
Haitao