From: Stephen Smalley <sds@tycho.nsa.gov>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
"Xing, Cedric" <cedric.xing@intel.com>,
Andy Lutomirski <luto@kernel.org>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
LSM List <linux-security-module@vger.kernel.org>,
Paul Moore <paul@paul-moore.com>,
Eric Paris <eparis@parisplace.org>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
Jethro Beekman <jethro@fortanix.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Dr. Greg" <greg@enjellic.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"nhorman@redhat.com" <nhorman@redhat.com>,
"npmccallum@redhat.com" <npmccallum@redhat.com>,
"Ayoun, Serge" <serge.ayoun@intel.com>,
"Katz-zamir, Shay" <shay.katz-zamir@intel.com>,
"Huang, Haitao" <haitao.huang@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"Svahn, Kai" <kai.svahn@intel.com>,
Borislav Petkov <bp@alien8.de>,
Josh Triplett <josh@joshtriplett.org>,
"Huang, Kai" <kai.huang@intel.com>,
David Rientjes <rientjes@google.com>
Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
Date: Fri, 17 May 2019 16:34:43 -0400 [thread overview]
Message-ID: <1d152f34-e6ca-edf4-65e7-fa758187332e@tycho.nsa.gov> (raw)
In-Reply-To: <ED98AEC9-FFA3-4DA4-9B86-11D8AADC9151@amacapital.net>
On 5/17/19 4:14 PM, Andy Lutomirski wrote:
>
>> On May 17, 2019, at 1:09 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>>> On 5/17/19 3:28 PM, Sean Christopherson wrote:
>>>> On Fri, May 17, 2019 at 02:05:39PM -0400, Stephen Smalley wrote:
>>>>> On 5/17/19 1:12 PM, Andy Lutomirski wrote:
>>>>>
>>>>> How can that work? Unless the API changes fairly radically, users
>>>>> fundamentally need to both write and execute the enclave. Some of it will
>>>>> be written only from already executable pages, and some privilege should be
>>>>> needed to execute any enclave page that was not loaded like this.
>>>>
>>>> I'm not sure what the API is. Let's say they do something like this:
>>>>
>>>> fd = open("/dev/sgx/enclave", O_RDONLY);
>>>> addr = mmap(NULL, size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0);
>>>> stuff addr into ioctl args
>>>> ioctl(fd, ENCLAVE_CREATE, &ioctlargs);
>>>> ioctl(fd, ENCLAVE_ADD_PAGE, &ioctlargs);
>>>> ioctl(fd, ENCLAVE_INIT, &ioctlargs);
>>> That's rougly the flow, except that that all enclaves need to have RW and
>>> X EPC pages.
>>>> The important points are that they do not open /dev/sgx/enclave with write
>>>> access (otherwise they will trigger FILE__WRITE at open time, and later
>>>> encounter FILE__EXECUTE as well during mmap, thereby requiring both to be
>>>> allowed to /dev/sgx/enclave), and that they do not request PROT_WRITE to the
>>>> resulting mapping (otherwise they will trigger FILE__WRITE at mmap time).
>>>> Then only FILE__READ and FILE__EXECUTE are required to /dev/sgx/enclave in
>>>> policy.
>>>>
>>>> If they switch to an anon inode, then any mmap PROT_EXEC of the opened file
>>>> will trigger an EXECMEM check, at least as currently implemented, as we have
>>>> no useful backing inode information.
>>> Yep, and that's by design in the overall proposal. The trick is that
>>> ENCLAVE_ADD takes a source VMA and copies the contents *and* the
>>> permissions from the source VMA. The source VMA points at regular memory
>>> that was mapped and populated using existing mechanisms for loading DSOs.
>>> E.g. at a high level:
>>> source_fd = open("/home/sean/path/to/my/enclave", O_RDONLY);
>>> for_each_chunk {
>>> <hand waving - mmap()/mprotect() the enclave file into regular memory>
>>> }
>>> enclave_fd = open("/dev/sgx/enclave", O_RDWR); /* allocs anon inode */
>>> enclave_addr = mmap(NULL, size, PROT_READ, MAP_SHARED, enclave_fd, 0);
>>> ioctl(enclave_fd, ENCLAVE_CREATE, {enclave_addr});
>>> for_each_chunk {
>>> struct sgx_enclave_add ioctlargs = {
>>> .offset = chunk.offset,
>>> .source = chunk.addr,
>>> .size = chunk.size,
>>> .type = chunk.type, /* SGX specific metadata */
>>> }
>>> ioctl(fd, ENCLAVE_ADD, &ioctlargs); /* modifies enclave's VMAs */
>>> }
>>> ioctl(fd, ENCLAVE_INIT, ...);
>>> Userspace never explicitly requests PROT_EXEC on enclave_fd, but SGX also
>>> ensures userspace isn't bypassing LSM policies by virtue of copying the
>>> permissions for EPC VMAs from regular VMAs that have already gone through
>>> LSM checks.
>>
>> Is O_RDWR required for /dev/sgx/enclave or would O_RDONLY suffice? Do you do anything other than ioctl() calls on it?
>>
>> What's the advantage of allocating an anon inode in the above? At present anon inodes are exempted from inode-based checking, thereby losing the ability to perform SELinux ioctl whitelisting, unlike the file-backed /dev/sgx/enclave inode.
>>
>> How would SELinux (or other security modules) restrict the authorized enclaves that can be loaded via this interface? Would the sgx driver invoke a new LSM hook with the regular/source VMAs as parameters and allow the security module to reject the ENCLAVE_ADD operation? That could be just based on the vm_file (e.g. whitelist what enclave files are permitted in general) or it could be based on both the process and the vm_file (e.g. only allow specific enclaves to be loaded into specific processes).
>
> This is the idea behind the .sigstruct file. The driver could call a new hook to approve or reject the .sigstruct. The sigstruct contains a hash of the whole enclave and a signature by the author.
Ok, so same idea but moved to ENCLAVE_INIT and passing the vma or file
for the sigstruct instead of the enclave.
next prev parent reply other threads:[~2019-05-17 20:35 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8fe520bb-30bd-f246-a3d8-c5443e47a014@intel.com>
[not found] ` <358e9b36-230f-eb18-efdb-b472be8438b4@fortanix.com>
[not found] ` <960B34DE67B9E140824F1DCDEC400C0F4E886094@ORSMSX116.amr.corp.intel.com>
[not found] ` <6da269d8-7ebb-4177-b6a7-50cc5b435cf4@fortanix.com>
[not found] ` <CALCETrWCZQwg-TUCm58DVG43=xCKRsMe1tVHrR8vdt06hf4fWA@mail.gmail.com>
[not found] ` <20190513102926.GD8743@linux.intel.com>
[not found] ` <20190514104323.GA7591@linux.intel.com>
[not found] ` <CALCETrVbgTCnPo=PAq0-KoaRwt--urrPzn==quAJ8wodCpkBkw@mail.gmail.com>
[not found] ` <20190514204527.GC1977@linux.intel.com>
[not found] ` <CALCETrX6aL367mMJh5+Y1Seznfu-AvhPV6P7GkWF4Dhu0GV8cw@mail.gmail.com>
[not found] ` <20190515013031.GF1977@linux.intel.com>
2019-05-15 18:27 ` SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Andy Lutomirski
2019-05-15 19:58 ` James Morris
2019-05-15 20:35 ` Andy Lutomirski
2019-05-15 22:46 ` James Morris
2019-05-15 23:13 ` Andy Lutomirski
2019-05-16 3:03 ` Xing, Cedric
2019-05-16 4:40 ` Andy Lutomirski
2019-05-16 22:23 ` Xing, Cedric
2019-05-17 0:35 ` Andy Lutomirski
2019-05-17 1:06 ` Xing, Cedric
2019-05-17 1:21 ` Andy Lutomirski
2019-05-17 16:05 ` Sean Christopherson
2019-05-17 13:53 ` Stephen Smalley
2019-05-17 15:09 ` Sean Christopherson
2019-05-17 16:20 ` Stephen Smalley
2019-05-17 16:24 ` Andy Lutomirski
2019-05-17 16:37 ` Stephen Smalley
2019-05-17 17:12 ` Andy Lutomirski
2019-05-17 18:05 ` Stephen Smalley
2019-05-17 19:20 ` Stephen Smalley
2019-05-17 19:28 ` Sean Christopherson
2019-05-17 20:09 ` Stephen Smalley
2019-05-17 20:14 ` Andy Lutomirski
2019-05-17 20:34 ` Stephen Smalley [this message]
2019-05-17 21:36 ` Sean Christopherson
2019-05-17 17:29 ` Sean Christopherson
2019-05-17 17:42 ` Stephen Smalley
2019-05-17 17:50 ` Sean Christopherson
2019-05-17 18:16 ` Stephen Smalley
2019-05-17 17:43 ` Andy Lutomirski
2019-05-17 17:55 ` Sean Christopherson
2019-05-17 18:04 ` Linus Torvalds
2019-05-17 18:21 ` Sean Christopherson
2019-05-17 18:33 ` Linus Torvalds
2019-05-17 18:52 ` Sean Christopherson
2019-05-17 18:53 ` Andy Lutomirski
2019-05-16 7:24 ` James Morris
2019-05-16 21:00 ` Andy Lutomirski
2019-05-20 9:38 ` Dr. Greg
2019-05-15 21:38 ` Sean Christopherson
2019-05-16 1:19 ` Haitao Huang
2019-05-16 5:16 ` Jarkko Sakkinen
2019-05-16 21:02 ` Andy Lutomirski
2019-05-16 22:45 ` Sean Christopherson
2019-05-16 23:29 ` Xing, Cedric
2019-05-20 11:29 ` Jarkko Sakkinen
2019-05-20 11:33 ` Jarkko Sakkinen
2019-05-17 0:03 ` Sean Christopherson
2019-05-17 0:26 ` Andy Lutomirski
2019-05-17 15:41 ` Sean Christopherson
2019-05-20 11:42 ` Jarkko Sakkinen
2019-05-20 11:41 ` Jarkko Sakkinen
2019-05-21 15:19 ` Jarkko Sakkinen
2019-05-21 15:24 ` Jethro Beekman
2019-05-22 13:10 ` Jarkko Sakkinen
2019-05-21 15:51 ` Sean Christopherson
2019-05-22 13:20 ` Jarkko Sakkinen
2019-05-22 13:22 ` Jarkko Sakkinen
2019-05-22 13:56 ` Stephen Smalley
2019-05-22 15:38 ` Sean Christopherson
2019-05-22 22:42 ` Andy Lutomirski
2019-05-23 2:35 ` Sean Christopherson
2019-05-23 10:26 ` Jarkko Sakkinen
2019-05-23 14:17 ` Sean Christopherson
2019-05-23 15:38 ` Andy Lutomirski
2019-05-23 23:40 ` Sean Christopherson
2019-05-24 1:17 ` Andy Lutomirski
2019-05-24 7:24 ` Xing, Cedric
2019-05-24 15:41 ` Stephen Smalley
2019-05-24 16:57 ` Xing, Cedric
2019-05-24 17:42 ` Sean Christopherson
2019-05-24 17:54 ` Andy Lutomirski
2019-05-24 17:56 ` Sean Christopherson
2019-05-24 17:54 ` Sean Christopherson
2019-05-24 18:34 ` Xing, Cedric
2019-05-24 19:13 ` Sean Christopherson
2019-05-24 19:30 ` Andy Lutomirski
2019-05-24 20:42 ` Xing, Cedric
2019-05-24 21:11 ` Sean Christopherson
2019-05-24 19:37 ` Andy Lutomirski
2019-05-24 20:03 ` Sean Christopherson
2019-05-24 20:58 ` Xing, Cedric
2019-05-24 21:27 ` Andy Lutomirski
2019-05-24 22:41 ` Sean Christopherson
2019-05-24 23:42 ` Andy Lutomirski
2019-05-25 22:40 ` Xing, Cedric
2019-05-26 0:57 ` Andy Lutomirski
2019-05-26 6:09 ` Xing, Cedric
2019-05-28 20:24 ` Sean Christopherson
2019-05-28 20:48 ` Andy Lutomirski
2019-05-28 21:41 ` Sean Christopherson
2019-05-30 5:38 ` Xing, Cedric
2019-05-30 17:21 ` Sean Christopherson
2019-05-29 14:08 ` Stephen Smalley
2019-05-30 6:12 ` Xing, Cedric
2019-05-30 14:22 ` Stephen Smalley
2019-05-30 14:31 ` Andy Lutomirski
2019-05-30 15:04 ` Stephen Smalley
2019-05-30 16:14 ` Andy Lutomirski
2019-05-30 18:01 ` Sean Christopherson
2019-05-30 19:20 ` Andy Lutomirski
2019-05-30 21:16 ` Sean Christopherson
2019-05-30 21:23 ` Andy Lutomirski
2019-05-30 21:36 ` Sean Christopherson
2019-06-03 9:12 ` Dr. Greg
2019-06-03 21:08 ` Jarkko Sakkinen
2019-05-30 21:48 ` Xing, Cedric
2019-05-30 22:24 ` Sean Christopherson
2019-06-03 21:05 ` Jarkko Sakkinen
2019-06-03 20:54 ` Jarkko Sakkinen
2019-06-03 21:23 ` Sean Christopherson
2019-06-04 11:39 ` Jarkko Sakkinen
2019-06-03 21:37 ` Andy Lutomirski
2019-06-03 20:47 ` Jarkko Sakkinen
2019-06-03 20:43 ` Jarkko Sakkinen
2019-05-25 17:31 ` Dr. Greg
2019-05-24 16:43 ` Andy Lutomirski
2019-05-24 17:07 ` Sean Christopherson
2019-05-24 17:51 ` Andy Lutomirski
2019-05-24 14:44 ` Stephen Smalley
2019-05-27 13:48 ` Jarkko Sakkinen
2019-05-23 19:58 ` Sean Christopherson
2019-05-27 13:34 ` Jarkko Sakkinen
2019-05-27 13:38 ` Jarkko Sakkinen
2019-05-23 8:10 ` Jarkko Sakkinen
2019-05-23 8:23 ` Jarkko Sakkinen
2019-05-20 11:36 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d152f34-e6ca-edf4-65e7-fa758187332e@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=cedric.xing@intel.com \
--cc=dave.hansen@intel.com \
--cc=eparis@parisplace.org \
--cc=greg@enjellic.com \
--cc=haitao.huang@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jethro@fortanix.com \
--cc=jmorris@namei.org \
--cc=josh@joshtriplett.org \
--cc=kai.huang@intel.com \
--cc=kai.svahn@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=nhorman@redhat.com \
--cc=npmccallum@redhat.com \
--cc=paul@paul-moore.com \
--cc=rientjes@google.com \
--cc=sean.j.christopherson@intel.com \
--cc=selinux@vger.kernel.org \
--cc=serge.ayoun@intel.com \
--cc=serge@hallyn.com \
--cc=shay.katz-zamir@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).