From: "Haitao Huang" <haitao.huang@linux.intel.com>
To: "Sean Christopherson" <sean.j.christopherson@intel.com>,
"Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com>
Cc: "Andy Lutomirski" <luto@kernel.org>, "X86 ML" <x86@kernel.org>,
linux-sgx@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Jethro Beekman" <jethro@fortanix.com>,
"Darren Kenny" <darren.kenny@oracle.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
asapek@google.com, "Borislav Petkov" <bp@alien8.de>,
"Xing, Cedric" <cedric.xing@intel.com>,
chenalexchen@google.com,
"Conrad Parker" <conradparker@google.com>,
cyhanish@google.com, "Dave Hansen" <dave.hansen@intel.com>,
"Huang, Haitao" <haitao.huang@intel.com>,
"Josh Triplett" <josh@joshtriplett.org>,
"Huang, Kai" <kai.huang@intel.com>,
"Svahn, Kai" <kai.svahn@intel.com>,
"Keith Moyer" <kmoy@google.com>,
"Christian Ludloff" <ludloff@google.com>,
"Neil Horman" <nhorman@redhat.com>,
"Nathaniel McCallum" <npmccallum@redhat.com>,
"Patrick Uiterwijk" <puiterwijk@redhat.com>,
"David Rientjes" <rientjes@google.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
yaozhangx@google.com
Subject: Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
Date: Thu, 24 Sep 2020 14:11:37 -0500 [thread overview]
Message-ID: <op.0rgp5h0hwjvjmi@mqcpg7oapc828.gar.corp.intel.com> (raw)
In-Reply-To: <20200923135056.GD5160@linux.intel.com>
On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> On Tue, Sep 22, 2020 at 09:43:02AM -0700, Sean Christopherson wrote:
>> On Tue, Sep 22, 2020 at 08:35:15AM +0300, Jarkko Sakkinen wrote:
>> > On Tue, Sep 22, 2020 at 08:30:06AM +0300, Jarkko Sakkinen wrote:
>> > > On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
>> > > > Userspace can add the page without EXEC permissions in the EPCM,
>> and thus
>> > > > avoid the noexec/VM_MAYEXEC check. The enclave can then do
>> EMODPE to gain
>> > > > EXEC permissions in the EPMC. Without the ->mprotect() hook, we
>> wouldn't
>> > > > be able to detect/prevent such shenanigans.
>> > >
>> > > Right, the VM_MAYEXEC in the code is nested under VM_EXEC check.
>> > >
>> > > I'm only wondering why not block noexec completely with any
>> permissions,
>> > > i.e. why not just have unconditional VM_MAYEXEC check?
>> >
>> > I.e. why not this:
>> >
>> > static int __sgx_encl_add_page(struct sgx_encl *encl,
>> > struct sgx_encl_page *encl_page,
>> > struct sgx_epc_page *epc_page,
>> > struct sgx_secinfo *secinfo, unsigned long src)
>> > {
>> > struct sgx_pageinfo pginfo;
>> > struct vm_area_struct *vma;
>> > struct page *src_page;
>> > int ret;
>> >
>> > vma = find_vma(current->mm, src);
>> > if (!vma)
>> > return -EFAULT;
>> >
>> > if (!(vma->vm_flags & VM_MAYEXEC))
>> > return -EACCES;
>> >
>> > I'm not seeing the reason for "partial support" for noexec partitions.
>> >
>> > If there is a good reason, fine, let's just then document it.
>>
>> There are scenarios I can contrive, e.g. loading an enclave from a
>> noexec
>> filesystem without having to copy the entire enclave to anon memory, or
>> loading a data payload from a noexec FS.
>>
>> They're definitely contrived scenarios, but given that we also want the
>> ->mprotect() hook/behavior for potential LSM interaction, supporting
>> said
>> contrived scenarios costs is "free".
>
> For me this has caused months of confusion and misunderstanding of this
> feature. I only recently realized that "oh, right, we invented this".
>
> They are contrived scenarios enough that they should be considered when
> the workloads hit.
>
> Either we fully support noexec or not at all. Any "partial" thing is a
> two edged sword: it can bring some robustness with the price of
> complexity and possible unknown uknown scenarios where they might become
> API issue.
>
> I rather think later on how to extend API in some way to enable such
> contrivid scenarios rather than worrying about how this could be abused.
>
> The whole SGX is complex beast already so lets not add any extra when
> there is no a hard requirement to do so.
>
> I'll categorically deny noexec in the next patch set version.
>
> /Jarkko
There are use cases supported currently in which enclave binary is
received via IPC/RPC and held in buffers before EADD. Denying noexec
altogether would break those, right?
next prev parent reply other threads:[~2020-09-24 19:12 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200915112842.897265-1-jarkko.sakkinen@linux.intel.com>
2020-09-15 11:28 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Jarkko Sakkinen
2020-09-18 12:44 ` Borislav Petkov
2020-09-18 15:09 ` Andy Lutomirski
2020-09-18 23:24 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect()' Jarkko Sakkinen
2020-09-18 23:53 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() Sean Christopherson
2020-09-19 0:15 ` Andy Lutomirski
2020-09-22 12:58 ` Jarkko Sakkinen
2020-09-22 15:11 ` Dave Hansen
2020-09-23 13:30 ` Jarkko Sakkinen
2020-09-23 13:43 ` Jarkko Sakkinen
2020-09-23 14:33 ` Jarkko Sakkinen
2020-09-24 14:50 ` Dave Hansen
2020-09-24 16:27 ` Sean Christopherson
2020-09-24 19:35 ` Jarkko Sakkinen
2020-09-21 12:49 ` Jarkko Sakkinen
2020-09-21 12:51 ` Jarkko Sakkinen
2020-09-21 13:14 ` Jarkko Sakkinen
2020-09-21 16:57 ` Sean Christopherson
2020-09-21 21:07 ` Jarkko Sakkinen
2020-09-21 21:18 ` Sean Christopherson
2020-09-22 5:29 ` Jarkko Sakkinen
2020-09-22 5:35 ` Jarkko Sakkinen
2020-09-22 16:43 ` Sean Christopherson
2020-09-23 13:50 ` Jarkko Sakkinen
2020-09-24 19:11 ` Haitao Huang [this message]
2020-09-24 19:28 ` Sean Christopherson
2020-09-24 19:39 ` Dave Hansen
2020-09-24 20:01 ` Sean Christopherson
2020-09-24 20:10 ` Dave Hansen
2020-09-24 20:25 ` Sean Christopherson
2020-09-24 20:54 ` Dave Hansen
2020-09-24 22:10 ` Jarkko Sakkinen
2020-09-24 23:05 ` Sean Christopherson
2020-09-24 23:09 ` Dave Hansen
2020-09-25 0:00 ` Sean Christopherson
2020-09-25 17:18 ` Dave Hansen
2020-09-25 19:43 ` Sean Christopherson
2020-09-25 19:53 ` Dave Hansen
2020-09-26 4:15 ` Andy Lutomirski
2020-09-28 0:53 ` Jarkko Sakkinen
2020-09-28 14:04 ` Dave Hansen
2020-09-28 16:19 ` Jarkko Sakkinen
2020-09-28 16:48 ` Dave Hansen
2020-09-28 19:32 ` Jarkko Sakkinen
2020-09-28 19:45 ` Dave Hansen
2020-09-28 20:19 ` Jarkko Sakkinen
2020-09-29 1:37 ` Andy Lutomirski
2020-09-29 4:05 ` Jarkko Sakkinen
2020-09-29 14:24 ` Dave Hansen
2020-09-30 0:20 ` Jarkko Sakkinen
2020-09-30 14:35 ` Dave Hansen
2020-09-28 20:18 ` Jarkko Sakkinen
2020-10-18 8:49 ` Dr. Greg
2020-10-19 21:31 ` Sean Christopherson
2020-10-20 10:01 ` Dr. Greg
2020-10-20 16:40 ` Sean Christopherson
2020-10-24 14:37 ` Dr. Greg
2020-10-24 15:33 ` Andy Lutomirski
2020-10-26 10:51 ` Dr. Greg
2020-10-26 22:59 ` Andy Lutomirski
2020-10-27 0:40 ` Sean Christopherson
2020-09-24 22:07 ` Jarkko Sakkinen
2020-09-24 21:58 ` Jarkko Sakkinen
2020-09-24 21:55 ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 11/24] x86/sgx: Add SGX enclave driver Jarkko Sakkinen
2020-09-21 9:30 ` Borislav Petkov
2020-09-21 12:09 ` Jarkko Sakkinen
2020-10-01 17:36 ` Sean Christopherson
2020-10-01 18:49 ` Jarkko Sakkinen
2020-09-15 11:28 ` [PATCH v38 16/24] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-09-22 10:45 ` Borislav Petkov
2020-09-22 14:03 ` Jarkko Sakkinen
2020-09-22 14:24 ` Borislav Petkov
2020-09-23 14:52 ` Jarkko Sakkinen
2020-09-29 1:14 ` Sean Christopherson
2020-09-29 3:50 ` Jarkko Sakkinen
2020-09-29 8:35 ` Sean Christopherson
2020-09-22 16:24 ` Sean Christopherson
2020-09-22 18:02 ` Borislav Petkov
2020-09-23 15:25 ` Jarkko Sakkinen
[not found] <20200915110522.893152-1-jarkko.sakkinen@linux.intel.com>
2020-09-15 11:05 ` [PATCH v38 10/24] mm: Add vm_ops->mprotect() 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=op.0rgp5h0hwjvjmi@mqcpg7oapc828.gar.corp.intel.com \
--to=haitao.huang@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=asapek@google.com \
--cc=bp@alien8.de \
--cc=cedric.xing@intel.com \
--cc=chenalexchen@google.com \
--cc=conradparker@google.com \
--cc=cyhanish@google.com \
--cc=darren.kenny@oracle.com \
--cc=dave.hansen@intel.com \
--cc=haitao.huang@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jethro@fortanix.com \
--cc=josh@joshtriplett.org \
--cc=kai.huang@intel.com \
--cc=kai.svahn@intel.com \
--cc=kmoy@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-sgx@vger.kernel.org \
--cc=ludloff@google.com \
--cc=luto@kernel.org \
--cc=nhorman@redhat.com \
--cc=npmccallum@redhat.com \
--cc=puiterwijk@redhat.com \
--cc=rientjes@google.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=yaozhangx@google.com \
/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).