diff mbox series

[v38,10/24] mm: Add vm_ops->mprotect()

Message ID 20200915112842.897265-11-jarkko.sakkinen@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series None | expand

Commit Message

Jarkko Sakkinen Sept. 15, 2020, 11:28 a.m. UTC
From: Sean Christopherson <sean.j.christopherson@intel.com>

Add vm_ops()->mprotect() for additional constraints for a VMA.

Intel Software Guard eXtensions (SGX) will use this callback to add two
constraints:

1. Verify that the address range does not have holes: each page address
   must be filled with an enclave page.
2. Verify that VMA permissions won't surpass the permissions of any enclave
   page within the address range. Enclave cryptographically sealed
   permissions for each page address that set the upper limit for possible
   VMA permissions. Not respecting this can cause #GP's to be emitted.

Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 include/linux/mm.h | 3 +++
 mm/mprotect.c      | 5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

Comments

Borislav Petkov Sept. 18, 2020, 12:44 p.m. UTC | #1
On Tue, Sep 15, 2020 at 02:28:28PM +0300, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
> 
> Add vm_ops()->mprotect() for additional constraints for a VMA.
> 
> Intel Software Guard eXtensions (SGX) will use this callback to add two
> constraints:
> 
> 1. Verify that the address range does not have holes: each page address
>    must be filled with an enclave page.
> 2. Verify that VMA permissions won't surpass the permissions of any enclave
>    page within the address range. Enclave cryptographically sealed
>    permissions for each page address that set the upper limit for possible
>    VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> Cc: linux-mm@kvack.org
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Acked-by: Jethro Beekman <jethro@fortanix.com>
> Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Co-developed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  include/linux/mm.h | 3 +++
>  mm/mprotect.c      | 5 ++++-
>  2 files changed, 7 insertions(+), 1 deletion(-)

Needs an ACK from an mm person.
Andy Lutomirski Sept. 18, 2020, 3:09 p.m. UTC | #2
On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> From: Sean Christopherson <sean.j.christopherson@intel.com>
>
> Add vm_ops()->mprotect() for additional constraints for a VMA.
>
> Intel Software Guard eXtensions (SGX) will use this callback to add two
> constraints:
>
> 1. Verify that the address range does not have holes: each page address
>    must be filled with an enclave page.
> 2. Verify that VMA permissions won't surpass the permissions of any enclave
>    page within the address range. Enclave cryptographically sealed
>    permissions for each page address that set the upper limit for possible
>    VMA permissions. Not respecting this can cause #GP's to be emitted.

It's been awhile since I looked at this.  Can you remind us: is this
just preventing userspace from shooting itself in the foot or is this
something more important?

--Andy
Jarkko Sakkinen Sept. 18, 2020, 11:24 p.m. UTC | #3
On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> >
> > Add vm_ops()->mprotect() for additional constraints for a VMA.
> >
> > Intel Software Guard eXtensions (SGX) will use this callback to add two
> > constraints:
> >
> > 1. Verify that the address range does not have holes: each page address
> >    must be filled with an enclave page.
> > 2. Verify that VMA permissions won't surpass the permissions of any enclave
> >    page within the address range. Enclave cryptographically sealed
> >    permissions for each page address that set the upper limit for possible
> >    VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> It's been awhile since I looked at this.  Can you remind us: is this
> just preventing userspace from shooting itself in the foot or is this
> something more important?
> 
> --Andy

Haitao found this:

https://patchwork.kernel.org/patch/10978327/

The way I understand it, for an LSM hook it makes sense that the
mprotect() can deduce a single permission for an enclave address range.
With those constraints it is possible.

/Jarkko
Sean Christopherson Sept. 18, 2020, 11:53 p.m. UTC | #4
On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > From: Sean Christopherson <sean.j.christopherson@intel.com>
> >
> > Add vm_ops()->mprotect() for additional constraints for a VMA.
> >
> > Intel Software Guard eXtensions (SGX) will use this callback to add two
> > constraints:
> >
> > 1. Verify that the address range does not have holes: each page address
> >    must be filled with an enclave page.
> > 2. Verify that VMA permissions won't surpass the permissions of any enclave
> >    page within the address range. Enclave cryptographically sealed
> >    permissions for each page address that set the upper limit for possible
> >    VMA permissions. Not respecting this can cause #GP's to be emitted.

Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
that's technically an errata.  But this isn't the real motivation, e.g.
userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
simply adds another flavor.

> It's been awhile since I looked at this.  Can you remind us: is this
> just preventing userspace from shooting itself in the foot or is this
> something more important?

Something more important, it's used to prevent userspace from circumventing
a noexec filesystem by loading code into an enclave, and to give the kernel the
option of adding enclave specific LSM policies in the future.

The source file (if one exists) for the enclave is long gone when the enclave
is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
permissions for a given page are snapshotted when the page is added to the
enclave, i.e. when the enclave is built.  Enclave pages that will be executable
must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
noexec file system.

The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
permissions beyond what are allowed, e.g. trying to map an enclave page with
EXEC permissions when the page was added to the enclave without EXEC.

Future LSM policies have a similar need due to vm_file always pointing at
/dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave.
->mprotect() again allows enforcing permissions at map time that were checked
at enclave build time, e.g. via an LSM hook.

Deferring ->mprotect() until LSM support is added (if it ever is) would be
problematic due to SGX2.  With SGX2, userspace can extend permissions of an
enclave page (for the CPU's EPC Map entry, not the kernel's page tables)
without bouncing through the kernel.  Without ->mprotect () enforcement.
userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X.  We
want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so
that the hypothetical LSM hook would have all information at EADD(), i.e.
would be aware of the EXEC permission, without creating divergent behavior
based on whether or not an LSM is active.
Andy Lutomirski Sept. 19, 2020, 12:15 a.m. UTC | #5
> On Sep 18, 2020, at 4:53 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> 
> On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
>>> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
>>> <jarkko.sakkinen@linux.intel.com> wrote:
>>> 
>>> From: Sean Christopherson <sean.j.christopherson@intel.com>
>>> 
>>> Add vm_ops()->mprotect() for additional constraints for a VMA.
>>> 
>>> Intel Software Guard eXtensions (SGX) will use this callback to add two
>>> constraints:
>>> 
>>> 1. Verify that the address range does not have holes: each page address
>>>   must be filled with an enclave page.
>>> 2. Verify that VMA permissions won't surpass the permissions of any enclave
>>>   page within the address range. Enclave cryptographically sealed
>>>   permissions for each page address that set the upper limit for possible
>>>   VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
> that's technically an errata.  But this isn't the real motivation, e.g.
> userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
> simply adds another flavor.
> 
>> It's been awhile since I looked at this.  Can you remind us: is this
>> just preventing userspace from shooting itself in the foot or is this
>> something more important?
> 
> Something more important, it's used to prevent userspace from circumventing
> a noexec filesystem by loading code into an enclave, and to give the kernel the
> option of adding enclave specific LSM policies in the future.
> 
> The source file (if one exists) for the enclave is long gone when the enclave
> is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> permissions for a given page are snapshotted when the page is added to the
> enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> noexec file system.
> 
> The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
> permissions beyond what are allowed, e.g. trying to map an enclave page with
> EXEC permissions when the page was added to the enclave without EXEC.
> 
> Future LSM policies have a similar need due to vm_file always pointing at
> /dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave.
> ->mprotect() again allows enforcing permissions at map time that were checked
> at enclave build time, e.g. via an LSM hook.
> 
> Deferring ->mprotect() until LSM support is added (if it ever is) would be
> problematic due to SGX2.  With SGX2, userspace can extend permissions of an
> enclave page (for the CPU's EPC Map entry, not the kernel's page tables)
> without bouncing through the kernel.  Without ->mprotect () enforcement.
> userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X.  We
> want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so
> that the hypothetical LSM hook would have all information at EADD(), i.e.
> would be aware of the EXEC permission, without creating divergent behavior
> based on whether or not an LSM is active.

That’s what I thought. Can we get this in the changelog?
Jarkko Sakkinen Sept. 21, 2020, 12:49 p.m. UTC | #6
On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> > On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> > <jarkko.sakkinen@linux.intel.com> wrote:
> > >
> > > From: Sean Christopherson <sean.j.christopherson@intel.com>
> > >
> > > Add vm_ops()->mprotect() for additional constraints for a VMA.
> > >
> > > Intel Software Guard eXtensions (SGX) will use this callback to add two
> > > constraints:
> > >
> > > 1. Verify that the address range does not have holes: each page address
> > >    must be filled with an enclave page.
> > > 2. Verify that VMA permissions won't surpass the permissions of any enclave
> > >    page within the address range. Enclave cryptographically sealed
> > >    permissions for each page address that set the upper limit for possible
> > >    VMA permissions. Not respecting this can cause #GP's to be emitted.
> 
> Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
> that's technically an errata.  But this isn't the real motivation, e.g.
> userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
> simply adds another flavor.
> 
> > It's been awhile since I looked at this.  Can you remind us: is this
> > just preventing userspace from shooting itself in the foot or is this
> > something more important?
> 
> Something more important, it's used to prevent userspace from circumventing
> a noexec filesystem by loading code into an enclave, and to give the kernel the
> option of adding enclave specific LSM policies in the future.
> 
> The source file (if one exists) for the enclave is long gone when the enclave
> is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> permissions for a given page are snapshotted when the page is added to the
> enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> noexec file system.

noexec check is done in __sgx_encl_add_page(), not in this callback.
sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
addresses, checks that permissions are not surpassed and there are
no holes.

> The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
> permissions beyond what are allowed, e.g. trying to map an enclave page with
> EXEC permissions when the page was added to the enclave without EXEC.

For my ear this is tautological because if user space would use
differing permissions, it would exactly soot itself in the foot.

What really should be documented is to answer why we consider an enclave
mappable, if and only if the conditions are that I described about
sgx_encl_may_map() functioning.

This is obviously part of the answer [*], i.e. with pharsing LSM hook
requires an enclave to have a state, which is compatible with the mmap
permissions and is fully populated.

The 2nd part of the answer is the answer to the question: why we want to
feed LSM hooks enclaves exactly in this state.

What would you answer to that?

[*] https://lore.kernel.org/linux-sgx/20200918232458.GA6175@linux.intel.com/T/#u

/Jarkko
Jarkko Sakkinen Sept. 21, 2020, 12:51 p.m. UTC | #7
On Mon, Sep 21, 2020 at 03:49:56PM +0300, Jarkko Sakkinen wrote:
> What really should be documented is to answer why we consider an enclave
                                      ~~
				      the (editing mistake)

/Jarkko
Jarkko Sakkinen Sept. 21, 2020, 1:14 p.m. UTC | #8
On Mon, Sep 21, 2020 at 03:49:56PM +0300, Jarkko Sakkinen wrote:
> The 2nd part of the answer is the answer to the question: why we want to
> feed LSM hooks enclaves exactly in this state.

The question can be further refined as why: why this is the best
possible set of substates to filter in?

"no holes" part is obvious as the consequence of not surpassing
permissions of any of the pages in range, as you could otherwise
break the state with ioctl(SGX_ENCLAVE_ADD_PAGES) with permssions
that are below the mmap permissions.

/Jarkko
Sean Christopherson Sept. 21, 2020, 4:57 p.m. UTC | #9
On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> > > On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > >
> > > > From: Sean Christopherson <sean.j.christopherson@intel.com>
> > > >
> > > > Add vm_ops()->mprotect() for additional constraints for a VMA.
> > > >
> > > > Intel Software Guard eXtensions (SGX) will use this callback to add two
> > > > constraints:
> > > >
> > > > 1. Verify that the address range does not have holes: each page address
> > > >    must be filled with an enclave page.
> > > > 2. Verify that VMA permissions won't surpass the permissions of any enclave
> > > >    page within the address range. Enclave cryptographically sealed
> > > >    permissions for each page address that set the upper limit for possible
> > > >    VMA permissions. Not respecting this can cause #GP's to be emitted.
> > 
> > Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
> > that's technically an errata.  But this isn't the real motivation, e.g.
> > userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
> > simply adds another flavor.
> > 
> > > It's been awhile since I looked at this.  Can you remind us: is this
> > > just preventing userspace from shooting itself in the foot or is this
> > > something more important?
> > 
> > Something more important, it's used to prevent userspace from circumventing
> > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > option of adding enclave specific LSM policies in the future.
> > 
> > The source file (if one exists) for the enclave is long gone when the enclave
> > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > permissions for a given page are snapshotted when the page is added to the
> > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > noexec file system.
> 
> noexec check is done in __sgx_encl_add_page(), not in this callback.
> sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> addresses, checks that permissions are not surpassed and there are
> no holes.

Yes, that's what I said.

> > The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
> > permissions beyond what are allowed, e.g. trying to map an enclave page with
> > EXEC permissions when the page was added to the enclave without EXEC.
> 
> For my ear this is tautological because if user space would use
> differing permissions, it would exactly soot itself in the foot.

Not on SGX2 hardware.  The kernel can't disable ENCLU[MODPE].

> What really should be documented is to answer why we consider an enclave
> mappable, if and only if the conditions are that I described about
> sgx_encl_may_map() functioning.
> 
> This is obviously part of the answer [*], i.e. with pharsing LSM hook
> requires an enclave to have a state, which is compatible with the mmap
> permissions and is fully populated.
> 
> The 2nd part of the answer is the answer to the question: why we want to
> feed LSM hooks enclaves exactly in this state.
> 
> What would you answer to that?

I would copy-paste the part of the response that was snipped...
 
> [*] https://lore.kernel.org/linux-sgx/20200918232458.GA6175@linux.intel.com/T/#u
> 
> /Jarkko
Jarkko Sakkinen Sept. 21, 2020, 9:07 p.m. UTC | #10
On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > option of adding enclave specific LSM policies in the future.
> > > 
> > > The source file (if one exists) for the enclave is long gone when the enclave
> > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > permissions for a given page are snapshotted when the page is added to the
> > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > noexec file system.
> > 
> > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > addresses, checks that permissions are not surpassed and there are
> > no holes.
> 
> Yes, that's what I said.

sgx_encl_add_page() will remove such page. The callback does not
interact with this process as such pages never get to the enclave.

> I would copy-paste the part of the response that was snipped...

I do agree with the main conclusions but it contains also things that I
do not see relating that much, like noexec partitions. It goes too far
in detail what will LSM's end up doing. I absolutely do not want to
forecast too far how LSM hooks would work.

Since we do not have ioctl's for EMODPE and such, I see EMODPE as the
only reason for doing this right now. Otherwise, we are in trouble with
any possible LSM callbacks. For any sort of access control decision,
things decided must stick.

I would add something like this to the commit message largely based on
your text:

"SGX stores the permissions for each page when they are first added, and
will implement this callback to check that mmap() or mprotect() does not
surpass these permissions in the requested address range.

This is done to prevent using EMODPE upgrading permissions of a page
after mmap() or mprotect() has been done, which would prevent any sort
of LSM callbacks to be implemented later on because the access control
decision could deprecate."

/Jarkko
Sean Christopherson Sept. 21, 2020, 9:18 p.m. UTC | #11
On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > > option of adding enclave specific LSM policies in the future.
> > > > 
> > > > The source file (if one exists) for the enclave is long gone when the enclave
> > > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > > permissions for a given page are snapshotted when the page is added to the
> > > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > > noexec file system.
> > > 
> > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > addresses, checks that permissions are not surpassed and there are
> > > no holes.
> > 
> > Yes, that's what I said.
> 
> sgx_encl_add_page() will remove such page. The callback does not
> interact with this process as such pages never get to the enclave.

I think we're in violent agreement, mostly.

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.

> > I would copy-paste the part of the response that was snipped...
> 
> I do agree with the main conclusions but it contains also things that I
> do not see relating that much, like noexec partitions.

As above, this does directly related to noexec/VM_MAYEXEC.

> It goes too far in detail what will LSM's end up doing. I absolutely do not
> want to forecast too far how LSM hooks would work.

That's fine, I was responding to Andy's question, not intending to write a
changelog.
 
> Since we do not have ioctl's for EMODPE and such, I see EMODPE as the
> only reason for doing this right now. Otherwise, we are in trouble with
> any possible LSM callbacks. For any sort of access control decision,
> things decided must stick.

Yes, again, violent agreement :-).

> I would add something like this to the commit message largely based on
> your text:
> 
> "SGX stores the permissions for each page when they are first added, and
> will implement this callback to check that mmap() or mprotect() does not
> surpass these permissions in the requested address range.
> 
> This is done to prevent using EMODPE upgrading permissions of a page
> after mmap() or mprotect() has been done, which would prevent any sort
> of LSM callbacks to be implemented later on because the access control
> decision could deprecate."
Jarkko Sakkinen Sept. 22, 2020, 5:29 a.m. UTC | #12
On Mon, Sep 21, 2020 at 02:18:49PM -0700, Sean Christopherson wrote:
> On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > > > option of adding enclave specific LSM policies in the future.
> > > > > 
> > > > > The source file (if one exists) for the enclave is long gone when the enclave
> > > > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > > > permissions for a given page are snapshotted when the page is added to the
> > > > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > > > noexec file system.
> > > > 
> > > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > > addresses, checks that permissions are not surpassed and there are
> > > > no holes.
> > > 
> > > Yes, that's what I said.
> > 
> > sgx_encl_add_page() will remove such page. The callback does not
> > interact with this process as such pages never get to the enclave.
> 
> I think we're in violent agreement, mostly.
> 
> 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?

/Jarkko
Jarkko Sakkinen Sept. 22, 2020, 5:35 a.m. UTC | #13
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:
> > On Tue, Sep 22, 2020 at 12:07:36AM +0300, Jarkko Sakkinen wrote:
> > > On Mon, Sep 21, 2020 at 09:57:58AM -0700, Sean Christopherson wrote:
> > > > On Mon, Sep 21, 2020 at 03:49:46PM +0300, Jarkko Sakkinen wrote:
> > > > > On Fri, Sep 18, 2020 at 04:53:37PM -0700, Sean Christopherson wrote:
> > > > > > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > > > > > option of adding enclave specific LSM policies in the future.
> > > > > > 
> > > > > > The source file (if one exists) for the enclave is long gone when the enclave
> > > > > > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > > > > > permissions for a given page are snapshotted when the page is added to the
> > > > > > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > > > > > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > > > > > noexec file system.
> > > > > 
> > > > > noexec check is done in __sgx_encl_add_page(), not in this callback.
> > > > > sgx_vma_mprotect() calls sgx_encl_may_map(), which iterates the
> > > > > addresses, checks that permissions are not surpassed and there are
> > > > > no holes.
> > > > 
> > > > Yes, that's what I said.
> > > 
> > > sgx_encl_add_page() will remove such page. The callback does not
> > > interact with this process as such pages never get to the enclave.
> > 
> > I think we're in violent agreement, mostly.
> > 
> > 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.

/Jarkko
Jarkko Sakkinen Sept. 22, 2020, 12:58 p.m. UTC | #14
On Fri, Sep 18, 2020 at 05:15:32PM -0700, Andy Lutomirski wrote:
> 
> > On Sep 18, 2020, at 4:53 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> > 
> > On Fri, Sep 18, 2020 at 08:09:04AM -0700, Andy Lutomirski wrote:
> >>> On Tue, Sep 15, 2020 at 4:28 AM Jarkko Sakkinen
> >>> <jarkko.sakkinen@linux.intel.com> wrote:
> >>> 
> >>> From: Sean Christopherson <sean.j.christopherson@intel.com>
> >>> 
> >>> Add vm_ops()->mprotect() for additional constraints for a VMA.
> >>> 
> >>> Intel Software Guard eXtensions (SGX) will use this callback to add two
> >>> constraints:
> >>> 
> >>> 1. Verify that the address range does not have holes: each page address
> >>>   must be filled with an enclave page.
> >>> 2. Verify that VMA permissions won't surpass the permissions of any enclave
> >>>   page within the address range. Enclave cryptographically sealed
> >>>   permissions for each page address that set the upper limit for possible
> >>>   VMA permissions. Not respecting this can cause #GP's to be emitted.
> > 
> > Side note, #GP is wrong.  EPCM violations are #PFs.  Skylake CPUs #GP, but
> > that's technically an errata.  But this isn't the real motivation, e.g.
> > userspace can already trigger #GP/#PF by reading/writing a bad address, SGX
> > simply adds another flavor.
> > 
> >> It's been awhile since I looked at this.  Can you remind us: is this
> >> just preventing userspace from shooting itself in the foot or is this
> >> something more important?
> > 
> > Something more important, it's used to prevent userspace from circumventing
> > a noexec filesystem by loading code into an enclave, and to give the kernel the
> > option of adding enclave specific LSM policies in the future.
> > 
> > The source file (if one exists) for the enclave is long gone when the enclave
> > is actually mmap()'d and mprotect()'d.  To enforce noexec, the requested
> > permissions for a given page are snapshotted when the page is added to the
> > enclave, i.e. when the enclave is built.  Enclave pages that will be executable
> > must originate from an a MAYEXEC VMA, e.g. the source page can't come from a
> > noexec file system.
> > 
> > The ->mprotect() hook allows SGX to reject mprotect() if userspace is declaring
> > permissions beyond what are allowed, e.g. trying to map an enclave page with
> > EXEC permissions when the page was added to the enclave without EXEC.
> > 
> > Future LSM policies have a similar need due to vm_file always pointing at
> > /dev/sgx/enclave, e.g. policies couldn't be attached to a specific enclave.
> > ->mprotect() again allows enforcing permissions at map time that were checked
> > at enclave build time, e.g. via an LSM hook.
> > 
> > Deferring ->mprotect() until LSM support is added (if it ever is) would be
> > problematic due to SGX2.  With SGX2, userspace can extend permissions of an
> > enclave page (for the CPU's EPC Map entry, not the kernel's page tables)
> > without bouncing through the kernel.  Without ->mprotect () enforcement.
> > userspace could do EADD(RW) -> mprotect(RWX) -> EMODPE(X) to gain W+X.  We
> > want to disallow such a flow now, i.e. force userspace to do EADD(RW,X), so
> > that the hypothetical LSM hook would have all information at EADD(), i.e.
> > would be aware of the EXEC permission, without creating divergent behavior
> > based on whether or not an LSM is active.
> 
> That’s what I thought. Can we get this in the changelog?

I rewrote the commit message. 

"
mm: Add 'mprotect' callback to vm_ops

Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
called enclaves, of which page permissions are defined when the enclave
is first loaded. Once an enclave is loaded and initialized, it can be
mapped to the process address space.

Enclave permissions can be dynamically modified by using ENCLS[EMODPE]
instruction. We want to limit its use to not allow higher permissions than
the ones defined when the enclave was first created.

Add 'mprotect' hook to vm_ops, so that we can implement a callback for SGX
that will check that {mmap, mprotect}() permissions do not surpass any of
the page permissions in the address range defined.

This is required in order to be able to make any access control decisions
when enclave pages are loaded.
"

/Jarkko
Dave Hansen Sept. 22, 2020, 3:11 p.m. UTC | #15
On 9/22/20 5:58 AM, Jarkko Sakkinen wrote:
> Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> called enclaves, of which page permissions are defined when the enclave

"of which" => "for which"

> is first loaded. Once an enclave is loaded and initialized, it can be
> mapped to the process address space.

Could you compare and contrast this a *bit* with existing executables?
What's special about SGX?  ELF executables have page permissions inside
the binary too.  Why don't we use this mechanism for them?

> Enclave permissions can be dynamically modified by using ENCLS[EMODPE]

I'm not sure this sentence matters.  I'm not sure why I care what the
instruction is named that does this.  But, it _sounds_ here like an
enclave can adjust its own permissions directly with ENCLS[EMODPE].

> instruction. We want to limit its use to not allow higher permissions than
> the ones defined when the enclave was first created.

Rather than higher and lower, please use stronger and weaker.

Also, please get rid of the "we".

> Add 'mprotect' hook to vm_ops, so that we can implement a callback for SGX
> that will check that {mmap, mprotect}() permissions do not surpass any of
> the page permissions in the address range defined.

"check" => "ensure"

> This is required in order to be able to make any access control decisions
> when enclave pages are loaded.
Now I'm confused.  I actually don't think I have a strong understanding
of how an enclave actually gets loaded, how mmap() and mprotect() are
normally used and what this hook is intended to thwart.
Sean Christopherson Sept. 22, 2020, 4:43 p.m. UTC | #16
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".
Jarkko Sakkinen Sept. 23, 2020, 1:30 p.m. UTC | #17
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> > Enclave permissions can be dynamically modified by using ENCLS[EMODPE]
> 
> I'm not sure this sentence matters.  I'm not sure why I care what the
> instruction is named that does this.  But, it _sounds_ here like an
> enclave can adjust its own permissions directly with ENCLS[EMODPE].

If there was no EMODPE, I would drop this patch from the patch set. It
is the only reason I keep it. There are no other hard reasons to have
this.

> Now I'm confused.  I actually don't think I have a strong understanding
> of how an enclave actually gets loaded, how mmap() and mprotect() are
> normally used and what this hook is intended to thwart.

Enclave gets loaded with the ioctl API so ATM we rely only on
DAC permissions.

In future you might want to have LSM hooks to improve granularity
in two points:

1. When pages are added using SGX_IOC_ENCLAVE ADD_PAGES.
2. When enclave is initialized using SGX_IOC_ENCLAVE_INIT

In both you might want to make a policy decision based on origin
and page permissions.

If we do not limit mmap(), enclave could later on upgrade its
permissions with EMODPE and do mmap().

No matter what kind of LSM hooks or whatever possible improvements
are done later on to access control, they won't work unless we have
this because the permissions could be different than the original.

With this change you can still do EMODPE inside an enclave, but you
don't gain anything with it because your max permissions are capped
during the build time.

I'm not sure what exactly from this is missing from the commit message
but if you get this explanation maybe you can help me out with that.

Thank you for the feedback.

/Jarkko
Jarkko Sakkinen Sept. 23, 2020, 1:43 p.m. UTC | #18
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> On 9/22/20 5:58 AM, Jarkko Sakkinen wrote:
> > Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> > called enclaves, of which page permissions are defined when the enclave
> 
> "of which" => "for which"
> 
> > is first loaded. Once an enclave is loaded and initialized, it can be
> > mapped to the process address space.
> 
> Could you compare and contrast this a *bit* with existing executables?
> What's special about SGX?  ELF executables have page permissions inside
> the binary too.  Why don't we use this mechanism for them?

There is no standard file format for enclaves. They are dynamically
built. And the way enclaves are used as part of an app and throwing
container inside enclave differ. A single format would no work too
well for all possible use cases.

I cannot formally prove this of course but it is highly unlikely that
we could ever define such a format. Thus, the security focus is allow
to verify from origin.

And the existing ecosystem around SGX is already too large to suddenly
move to a single format. User base, I guess, is also an argument. This
is not yet mainline code so technically we have zero ABI debt but I
still think this is a valid point because SGX is already widely used.

I'm not really sure what would be the best way to nail this information
to the commit message but I'll try to figure out something before I send
the next version of the patch set.

/Jarkko
Jarkko Sakkinen Sept. 23, 2020, 1:50 p.m. UTC | #19
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
Jarkko Sakkinen Sept. 23, 2020, 2:33 p.m. UTC | #20
On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> Now I'm confused.  I actually don't think I have a strong understanding
> of how an enclave actually gets loaded, how mmap() and mprotect() are
> normally used and what this hook is intended to thwart.

You saw my other comments. I scraped this together based on your
feedback and my responses:

"
mm: Add 'mprotect' callback to vm_ops

Intel Sofware Guard eXtensions (SGX) allows creation of blobs called
enclaves, for which page permissions are defined when the enclave is first
loaded. Once an enclave is loaded and initialized, it can be mapped to the
process address space.

There is no standard file format for enclaves. They are dynamically built
and the ways how enclaves are deployed differ greatly. For an app you might
want to have a simple static binary, but on the other hand for a container
you might want to dynamically create the whole thing at run-time. Also, the
existing ecosystem for SGX is already large, which would make the task very
hard.

Finally, even if there was a standard format, one would still want a
dynamic way to add pages to the enclave. One big reason for this is that
enclaves have load time defined pages that represent entry points to the
enclave. Each entry point can service one hardware thread at a time and
you might want to run-time parametrize this depending on your environment.

The consequence is that enclaves are best created with an ioctl API and the
access control can be based only to the origin of the source file for the
enclave data, i.e. on VMA file pointer and page permissions. For example,
this could be done with LSM hooks that are triggered in the appropriate
ioctl's and they could make the access control decision based on this
information.

Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
could upgrade its permissions by using EMODPE followed by an appropriate
mprotect() call. This would be completely hidden from the kernel.

Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
that will ensure that {mmap, mprotect}() permissions do not surpass any of
the original page permissions. This feature allows to maintain and refine
sane access control for enclaves.
"

/Jarkko
Dave Hansen Sept. 24, 2020, 2:50 p.m. UTC | #21
On 9/23/20 7:33 AM, Jarkko Sakkinen wrote:
> The consequence is that enclaves are best created with an ioctl API and the
> access control can be based only to the origin of the source file for the
> enclave data, i.e. on VMA file pointer and page permissions. For example,
> this could be done with LSM hooks that are triggered in the appropriate
> ioctl's and they could make the access control decision based on this
> information.
> 
> Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> could upgrade its permissions by using EMODPE followed by an appropriate
> mprotect() call. This would be completely hidden from the kernel.
> 
> Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> that will ensure that {mmap, mprotect}() permissions do not surpass any of
> the original page permissions. This feature allows to maintain and refine
> sane access control for enclaves.

Maybe I'm just being dense, but I still don't have a clear idea what
function this hook serves.

I understand that SGX has an orthogonal set of page permissions to the
normal x86 page tables.  It needs these so that the OS can't play nasty
tricks on the enclave, like removing read-only protections that provide
hardening.

But, I still don't get the connection to mprotect() and the x86 paging
permissions.  If the enclave's permissions are orthogonal, then why
bother with this hook?  Why does the OS view of the enclave's memory matter?
Sean Christopherson Sept. 24, 2020, 4:27 p.m. UTC | #22
On Thu, Sep 24, 2020 at 07:50:15AM -0700, Dave Hansen wrote:
> On 9/23/20 7:33 AM, Jarkko Sakkinen wrote:
> > The consequence is that enclaves are best created with an ioctl API and the
> > access control can be based only to the origin of the source file for the
> > enclave data, i.e. on VMA file pointer and page permissions. For example,
> > this could be done with LSM hooks that are triggered in the appropriate
> > ioctl's and they could make the access control decision based on this
> > information.
> > 
> > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> > could upgrade its permissions by using EMODPE followed by an appropriate
> > mprotect() call. This would be completely hidden from the kernel.
> > 
> > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> > that will ensure that {mmap, mprotect}() permissions do not surpass any of
> > the original page permissions. This feature allows to maintain and refine
> > sane access control for enclaves.
> 
> Maybe I'm just being dense, but I still don't have a clear idea what
> function this hook serves.
> 
> I understand that SGX has an orthogonal set of page permissions to the
> normal x86 page tables.  It needs these so that the OS can't play nasty
> tricks on the enclave, like removing read-only protections that provide
> hardening.
> 
> But, I still don't get the connection to mprotect() and the x86 paging
> permissions.  If the enclave's permissions are orthogonal, then why
> bother with this hook?  Why does the OS view of the enclave's memory matter?

For the purpose of this discussion, ignore the enclave permissions.  The only
reason they're mentioned is to explain the background (well, try to) of how we
ended up at an ->mprotect() hook.  There was a great deal of discussion in the
past about whether or not we could use enclave permissions to enforce OS
permissions.  The TL:DR version is that because of ENCLU[EMODPE], the answer
is "no".

What we're preventing via ->mprotect() is using SGX to bypass existing
restrictions on code execution, e.g. noexec and LSM policies.

Because code must first be loaded into an enclave before it can be executed,
all enclaves are kind of a variant on (in SELinux terminology) either EXECMOD
or EXECMEM.  I.e. it's simply not possible to execute an enclave by mapping
the source file as executable.  This effectively allows userspace to bypass a
noexec FS by loading code into an enclave without EXEC perms on the source
file, only on /dev/sgx/enclave, and denying EXEC on /dev/sgx/enclave would
prevent running _any_ enclave.

The ->mprotect() hook is used by SGX to require userspace to declare what
permissions are allowed on any given enclave page, e.g. SGX's mmap()/mprotect()
requires all underlying enclave pages to be declared as executable if the
mmap()/mprotect() is specifying VM_EXEC.  By requiring userspace to declare
their intent up front, SGX can then enforce noexec by requiring pages that are
declared as executable to have VM_MAYEXEC set in the source VMA when loading
code into the enclave.

As Jarkko pointed out, an alternative to adding ->mprotect() would be to
simply require VM_MAYEXEC on _all_ source VMAs when loading code into the
enclave.  That would work, albeit with the potentially undesirable side effect
of preventing loading any part of an enclave from e.g. a noexec, readonly FS.

But, unconditionally requiring VM_MAYEXEC doesn't address the Linux Security
Module hooks for mmap() and mprotect(), which could also be bypassed by abusing
SGX.  E.g. a process could gain arbitrary code execution by loading code from
anonymous memory into an enclave, as the LSM checks hooks at mmap()/mprotect()
will see always vm_file=/dev/sgx/enclave.  An LSM could deny a process access
to /dev/sgx/enclave, but again that is very coarse granularity.

By requiring userspace to declare permissions up front (when loading code/data
into an enclave), SGX can make explicit upcalls to LSMs hooks at load time so
that an LSM can enforce a meaningful policy, e.g. require all enclave code to
originate from an executable file system.  This series doesn't actually
implement the LSM integration, but it does ensure that _if_ we want to add LSM
support in the future, we can do so without breaking userspace.
Haitao Huang Sept. 24, 2020, 7:11 p.m. UTC | #23
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?
Sean Christopherson Sept. 24, 2020, 7:28 p.m. UTC | #24
On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >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?

No.  noexec only applies to file-backed VMAs, what you're describing is loading
an enclave from an anon VMA, which will still have VM_MAYEXEC.

I believe you're thinking of SELinux's EXECMEM, which is required to execute
from anonymous memory, and which we talked about (more than once) applying to
SGX enclaves.

That being said, I still dislike the idea of requiring VM_MAYEXEC, it's a hack
that doesn't really buy us much, if anything.
Jarkko Sakkinen Sept. 24, 2020, 7:35 p.m. UTC | #25
On Thu, Sep 24, 2020 at 07:50:15AM -0700, Dave Hansen wrote:
> On 9/23/20 7:33 AM, Jarkko Sakkinen wrote:
> > The consequence is that enclaves are best created with an ioctl API and the
> > access control can be based only to the origin of the source file for the
> > enclave data, i.e. on VMA file pointer and page permissions. For example,
> > this could be done with LSM hooks that are triggered in the appropriate
> > ioctl's and they could make the access control decision based on this
> > information.
> > 
> > Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> > upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> > could upgrade its permissions by using EMODPE followed by an appropriate
> > mprotect() call. This would be completely hidden from the kernel.
> > 
> > Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> > that will ensure that {mmap, mprotect}() permissions do not surpass any of
> > the original page permissions. This feature allows to maintain and refine
> > sane access control for enclaves.
> 
> Maybe I'm just being dense, but I still don't have a clear idea what
> function this hook serves.
> 
> I understand that SGX has an orthogonal set of page permissions to the
> normal x86 page tables.  It needs these so that the OS can't play nasty
> tricks on the enclave, like removing read-only protections that provide
> hardening.
> 
> But, I still don't get the connection to mprotect() and the x86 paging
> permissions.  If the enclave's permissions are orthogonal, then why
> bother with this hook?  Why does the OS view of the enclave's memory matter?

Consider SGX_IOC_ENCLAVE_ADD_PAGES. It essentially takes from MAC
perpective two items:

1. Source represented as a VMA, and in the end as vm_file, i.e. the
   origin. This good place to anchor a security policy.
2. Permissions.

Since enclaves are dynamically constructed and do not go through
execve() path but are dynamically loaded this is a good place hook make
an LSM hook. Lets imagine that we have an LSM hook in place.

Now when enclave the enclave is loaded the LSM makes decisions based
on its policy, permissions and the origin of the enclave file. After
this decisions has been made it is sane to assume that the enclave
could not be run with higher permissions, right?

Now what an adversary could do after the enclave has been loaded and
initialized is to call EMODPE inside the enclave to upgrade permissions
to some pages. After that mprotect() can be applied to use the new
permissions.

The mprotect() callback keeps any higher permissions than originally
accepted by the MAC policy unusable.

Also without any LSM hooks this allows to have a more privileged launcher
process to build enclaves (e.g. have someone to own /dev/sgx/enclave)
and send fd's to other processes to run them. And with that callback in
place the launcher process can cap the permissions at build time.

That's where the indirect connection originates from. Should I write
this user story to the commit message as an addition. Would that help?

For v39 I did make a change that noexec partitions are categorically
discluded as an origin for enclaves. Before that it was that NX
pages from such partitions are allowed but I thought that it is better
simplify things since they are anyway complex. I'm 100% we can make
that kind of support for noexec partitions later on, if anyone ever
wants that anyway.

/Jarkko
Dave Hansen Sept. 24, 2020, 7:39 p.m. UTC | #26
On 9/24/20 12:28 PM, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
>> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
>> <jarkko.sakkinen@linux.intel.com> wrote:
>>> 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?
> No.  noexec only applies to file-backed VMAs, what you're describing is loading
> an enclave from an anon VMA, which will still have VM_MAYEXEC.

Maybe I'm just stupid, but I still don't get the scenario that's being
thwarted or why it is valuable.  The SDM is worthless on what EMODPE
does or what its restrictions are.

In pseudo-C, it's something logically like this for the "nice" case:

	ptr = mmap("/some/executable", PROT_EXEC);
	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
	mmap(sgx_fd);
	EENTER;

And we're trying to thwart:

	ptr = mmap("/mnt/noexec/file", PROT_READ);
	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
	mmap(sgx_fd);
	EENTER;

because that loads data into the enclave which is executable but which
was not executable normally.  But, we're allowing this from anonymous
memory, so this would seem to work:

	ptr = mmap("/mnt/noexec/file", PROT_READ);
	buffer = malloc(PAGE_SIZE);
	memcpy(buffer, ptr, PAGE_SIZE);
	// need mprotect(buf, PROT_EXEC)???
	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
	mmap(sgx_fd);
	EENTER;

and give the same result.  What am I missing?
Sean Christopherson Sept. 24, 2020, 8:01 p.m. UTC | #27
On Thu, Sep 24, 2020 at 12:39:24PM -0700, Dave Hansen wrote:
> On 9/24/20 12:28 PM, Sean Christopherson wrote:
> > On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> >> On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> >> <jarkko.sakkinen@linux.intel.com> wrote:
> >>> 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?
> > No.  noexec only applies to file-backed VMAs, what you're describing is loading
> > an enclave from an anon VMA, which will still have VM_MAYEXEC.
> 
> Maybe I'm just stupid, but I still don't get the scenario that's being
> thwarted or why it is valuable.  The SDM is worthless on what EMODPE
> does or what its restrictions are.
> 
> In pseudo-C, it's something logically like this for the "nice" case:
> 
> 	ptr = mmap("/some/executable", PROT_EXEC);
> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> 	mmap(sgx_fd);
> 	EENTER;
> 
> And we're trying to thwart:
> 
> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> 	mmap(sgx_fd);
> 	EENTER;
> 
> because that loads data into the enclave which is executable but which
> was not executable normally.  But, we're allowing this from anonymous
> memory, so this would seem to work:
> 
> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> 	buffer = malloc(PAGE_SIZE);
> 	memcpy(buffer, ptr, PAGE_SIZE);
> 	// need mprotect(buf, PROT_EXEC)???
> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
> 	mmap(sgx_fd);
> 	EENTER;
> 
> and give the same result.  What am I missing?

The last example, where the enclave is copied to a buffer, is out of scope
for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
SGX specific equivalent).

The ->mprotect() hook gives us direct line of sight to such LSM upcalls,
e.g. I have fully working code that implements the LSM integration.  LSM
support isn't in this series because the only thing everyone could agree on
in terms of an LSM implementation is that it wasn't needed for initial
upstreaming :-)
Dave Hansen Sept. 24, 2020, 8:10 p.m. UTC | #28
On 9/24/20 1:01 PM, Sean Christopherson wrote:
>> In pseudo-C, it's something logically like this for the "nice" case:
>>
>> 	ptr = mmap("/some/executable", PROT_EXEC);
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> And we're trying to thwart:
>>
>> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> because that loads data into the enclave which is executable but which
>> was not executable normally.  But, we're allowing this from anonymous
>> memory, so this would seem to work:
>>
>> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
>> 	buffer = malloc(PAGE_SIZE);
>> 	memcpy(buffer, ptr, PAGE_SIZE);
>> 	// need mprotect(buf, PROT_EXEC)???
>> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
>> 	mmap(sgx_fd);
>> 	EENTER;
>>
>> and give the same result.  What am I missing?
> The last example, where the enclave is copied to a buffer, is out of scope
> for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> SGX specific equivalent).

Why don't we just declare enclave memory as "out of scope for noexec" in
the same way that anonymous memory is, and just discard this patch?
That doesn't seem too much of a stretch.
Sean Christopherson Sept. 24, 2020, 8:25 p.m. UTC | #29
On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote:
> On 9/24/20 1:01 PM, Sean Christopherson wrote:
> >> In pseudo-C, it's something logically like this for the "nice" case:
> >>
> >> 	ptr = mmap("/some/executable", PROT_EXEC);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> And we're trying to thwart:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> because that loads data into the enclave which is executable but which
> >> was not executable normally.  But, we're allowing this from anonymous
> >> memory, so this would seem to work:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	buffer = malloc(PAGE_SIZE);
> >> 	memcpy(buffer, ptr, PAGE_SIZE);
> >> 	// need mprotect(buf, PROT_EXEC)???
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> and give the same result.  What am I missing?
> > The last example, where the enclave is copied to a buffer, is out of scope
> > for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> > SGX specific equivalent).
> 
> Why don't we just declare enclave memory as "out of scope for noexec" in
> the same way that anonymous memory is, and just discard this patch?
> That doesn't seem too much of a stretch.

Because we lose line of sight to LSM support.  Without enforcing "declare perms
at load time" in the initial series, we would create an ABI where userspace
could load an enclave page with only READ permissions and then map the enclave
with whatever permissions it wants, without any convenient way for SGX to call
into the LSM.

Retroactively enforcing permissions at load time would break the ABI, or at
least yield different behavior based on the mere existence of LSMs, e.g. if
LSMs are supported, suddenly the ADD_PAGES w/ READ -> mmap(RWX) flow breaks,
even if there is no LSM policy denying that behavior.

Enforcing LSM policies using the existing mmap()/mprotect() hooks doesn't work
well because the only information available is a fd pointing at
/dev/sgx/enclave, which is largely useless because /dev/sgx/enclave must be
map SHARED w/ RWX to run an enclave.  We explored things like grabbing a
reference to the source file for later verification, but that means pinning
files for the entire lifetime of an enclave.

Enforcing noexec was an easy/obvious addition since we need 99% of the code for
potential LSM support anyways.
Dave Hansen Sept. 24, 2020, 8:54 p.m. UTC | #30
On 9/24/20 1:25 PM, Sean Christopherson wrote:
...
>> Why don't we just declare enclave memory as "out of scope for noexec" in
>> the same way that anonymous memory is, and just discard this patch?
>> That doesn't seem too much of a stretch.
> 
> Because we lose line of sight to LSM support.  Without enforcing "declare perms
> at load time" in the initial series, we would create an ABI where userspace
> could load an enclave page with only READ permissions and then map the enclave
> with whatever permissions it wants, without any convenient way for SGX to call
> into the LSM.

This argument holds no water for me.  LSMs are all about taking what
would otherwise be perfectly acceptable behavior and breaking them in
the name of security.  They fundamentally break applications that used
to work just fine and also did totally sane things.

> Retroactively enforcing permissions at load time would break the ABI, or at
> least yield different behavior based on the mere existence of LSMs, e.g. if
> LSMs are supported, suddenly the ADD_PAGES w/ READ -> mmap(RWX) flow breaks,
> even if there is no LSM policy denying that behavior.

I'm a security dummy.  All I know is that when I see something like this:

	if (security_vm_enough_memory_mm(mm, grow))
		...

I know to ignore it because I like my systems to boot and I'm not using
those hooks.  :)

How could the mere presence of an LSM change the behavior of one of
these hooks?  Don't they have to actually hook into the specific place
and actively go trying to change the behavior at that site?
Jarkko Sakkinen Sept. 24, 2020, 9:55 p.m. UTC | #31
On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> > 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?

I do not see why data cannot be provided at run-time. AFAIK, it is not
different from executables how this works when it comes to noexec.

/Jarkko
Jarkko Sakkinen Sept. 24, 2020, 9:58 p.m. UTC | #32
On Thu, Sep 24, 2020 at 12:28:54PM -0700, Sean Christopherson wrote:
> On Thu, Sep 24, 2020 at 02:11:37PM -0500, Haitao Huang wrote:
> > On Wed, 23 Sep 2020 08:50:56 -0500, Jarkko Sakkinen
> > <jarkko.sakkinen@linux.intel.com> wrote:
> > >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?
> 
> No.  noexec only applies to file-backed VMAs, what you're describing is loading
> an enclave from an anon VMA, which will still have VM_MAYEXEC.
> 
> I believe you're thinking of SELinux's EXECMEM, which is required to execute
> from anonymous memory, and which we talked about (more than once) applying to
> SGX enclaves.
> 
> That being said, I still dislike the idea of requiring VM_MAYEXEC, it's a hack
> that doesn't really buy us much, if anything.

I think it makes sense as long as it is not half-way there solution.

Either require it for the full binary or not at all. I'm fine with
either.

/Jarkko
Jarkko Sakkinen Sept. 24, 2020, 10:07 p.m. UTC | #33
On Thu, Sep 24, 2020 at 01:10:31PM -0700, Dave Hansen wrote:
> On 9/24/20 1:01 PM, Sean Christopherson wrote:
> >> In pseudo-C, it's something logically like this for the "nice" case:
> >>
> >> 	ptr = mmap("/some/executable", PROT_EXEC);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> And we're trying to thwart:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, ptr, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> because that loads data into the enclave which is executable but which
> >> was not executable normally.  But, we're allowing this from anonymous
> >> memory, so this would seem to work:
> >>
> >> 	ptr = mmap("/mnt/noexec/file", PROT_READ);
> >> 	buffer = malloc(PAGE_SIZE);
> >> 	memcpy(buffer, ptr, PAGE_SIZE);
> >> 	// need mprotect(buf, PROT_EXEC)???
> >> 	ioctl(sgx_fd, ADD_ENCLAVE_PAGE, SGX_PROT_EXEC, buffer, size);
> >> 	mmap(sgx_fd);
> >> 	EENTER;
> >>
> >> and give the same result.  What am I missing?
> > The last example, where the enclave is copied to a buffer, is out of scope
> > for noexec.  But, it is in scope for LSMs, e.g. for this last example, we
> > could add an LSM upcall so that SELinux could require PROCESS_EXECMEM (or an
> > SGX specific equivalent).
> 
> Why don't we just declare enclave memory as "out of scope for noexec" in
> the same way that anonymous memory is, and just discard this patch?
> That doesn't seem too much of a stretch.

I did that already for v39. It unconditionally discards noexec
partitions.

I see EMODPE as the key driver for this patch, not noexec partitions.

I.e. post you've done SGX_IOC_ENCLAVE_INIT you are capped when it
comes to permissions.

/Jarkko
Jarkko Sakkinen Sept. 24, 2020, 10:10 p.m. UTC | #34
On Thu, Sep 24, 2020 at 01:54:09PM -0700, Dave Hansen wrote:
> On 9/24/20 1:25 PM, Sean Christopherson wrote:
> ...
> >> Why don't we just declare enclave memory as "out of scope for noexec" in
> >> the same way that anonymous memory is, and just discard this patch?
> >> That doesn't seem too much of a stretch.
> > 
> > Because we lose line of sight to LSM support.  Without enforcing "declare perms
> > at load time" in the initial series, we would create an ABI where userspace
> > could load an enclave page with only READ permissions and then map the enclave
> > with whatever permissions it wants, without any convenient way for SGX to call
> > into the LSM.
> 
> This argument holds no water for me.  LSMs are all about taking what
> would otherwise be perfectly acceptable behavior and breaking them in
> the name of security.  They fundamentally break applications that used
> to work just fine and also did totally sane things.

Well, I see that having this gives a better assets for a separate
loader. It can load and initialize the enclave and a consumer can
then use it but cannot override its permissions.

I don't even remember exactly how SELinux permissions played together.
I don't think it is required as an argument for this patch.

/Jarkko
Sean Christopherson Sept. 24, 2020, 11:05 p.m. UTC | #35
On Thu, Sep 24, 2020 at 01:54:09PM -0700, Dave Hansen wrote:
> On 9/24/20 1:25 PM, Sean Christopherson wrote:
> ...
> >> Why don't we just declare enclave memory as "out of scope for noexec" in
> >> the same way that anonymous memory is, and just discard this patch?
> >> That doesn't seem too much of a stretch.
> > 
> > Because we lose line of sight to LSM support.  Without enforcing "declare perms
> > at load time" in the initial series, we would create an ABI where userspace
> > could load an enclave page with only READ permissions and then map the enclave
> > with whatever permissions it wants, without any convenient way for SGX to call
> > into the LSM.
> 
> This argument holds no water for me.  LSMs are all about taking what
> would otherwise be perfectly acceptable behavior and breaking them in
> the name of security.  They fundamentally break applications that used
> to work just fine and also did totally sane things.

It's not about LSMs breaking things, they can obviously do that without any
help.  The concern is that, unless we lay the groundwork now, adding support
for LSMs in the future will break existing applications or create an unholy
mess of an ABI.

If we want to support LSM policy for enclave page permissions, checking LSM
policies at load time and hooking mprotect() to enforce the policy at run
time is by far the cleanest solution of the many ideas we discussed.

The problem is that enforcing permissions via mprotect() needs to be done
unconditionally, otherwise we end up with weird behavior where the existence
of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX
policy whatsover.

And on the flip side, enforcing permissions unconditionally will break
backwards compatibility.

I'm a-ok if we want to kill off the ->mprotect() hook, so long as we
acknowledge that in doing so we are likely throwing in the towel on supporting
LSM policies for enclave page permissions.
Dave Hansen Sept. 24, 2020, 11:09 p.m. UTC | #36
On 9/24/20 4:05 PM, Sean Christopherson wrote:
> The problem is that enforcing permissions via mprotect() needs to be done
> unconditionally, otherwise we end up with weird behavior where the existence
> of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX
> policy whatsover.

Could we make this a bit less abstract, please?

Could someone point to code or another examples that demonstrates how
the mere existence of an LSM will change what is/isn't allowed?

I can't seem to wrap my head around it as-is.
Sean Christopherson Sept. 25, 2020, midnight UTC | #37
On Thu, Sep 24, 2020 at 04:09:25PM -0700, Dave Hansen wrote:
> On 9/24/20 4:05 PM, Sean Christopherson wrote:
> > The problem is that enforcing permissions via mprotect() needs to be done
> > unconditionally, otherwise we end up with weird behavior where the existence
> > of an LSM will change what is/isn't allowed, even if the LSM(s) has no SGX
> > policy whatsover.
> 
> Could we make this a bit less abstract, please?
> 
> Could someone point to code or another examples that demonstrates how
> the mere existence of an LSM will change what is/isn't allowed?
> 
> I can't seem to wrap my head around it as-is.

Without pre-declared permissions, loading and running an enclave would be:

	ptr = malloc(size);
        memcpy(ptr, evil_shenanigans, size);
	ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);
        ...
	ioctl(sgx_fd, ENCLAVE_INIT);

        enclave = mmap(sgx_fd, ... PROT_READ);
        mprotect(enclave, ..., PROT_READ | PROT_EXEC);

	EENTER;

With the existing security_file_mprotect(), an LSM will see:

        vma->vm_file ~= /dev/sgx/enclave
        prot = PROT_READ | PROT_EXEC

From a policy perspective, the LSM can't do much because every enclave is
backed by /dev/sgx/enclave, and all enclaves need READ and EXEC perms, i.e.
a policy can only deny all enclaves or allow enclaves.

The solution we came up with is to require userspace to declare the intended
permissions at build time so that an LSM hook can be invoked when the source
VMA is availble, e.g. in this example, the LSM would see that the process is
loading executable code into an enclave from an anonymous VMA:

        ptr = malloc(size);
        memcpy(ptr, evil_shenanigans, size);
	ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);
        {
                ret = security_enclave_load(ptr, prot);
                if (ret)
                        return ret;

                enclave_page->declared_prot = prot;
        }
        ...
	ioctl(sgx_fd, ENCLAVE_INIT);

and then enforce the declared perms via ->mprotect()

        enclave = mmap(sgx_fd, ... PROT_READ);
        mprotect(enclave, ..., PROT_READ | PROT_EXEC);
        |
        -> sgx_mprotect(...)
           {
                   if (~enclave_page->declared_prot & prot)
                        return -EACCES;
           }

	EENTER;

So the above would be allowed, but this would fail (irrespective of LSM behavior):

        ptr = malloc(size);
        memcpy(ptr, evil_shenanigans, size);
	ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ, ptr, size);
        ...
	ioctl(sgx_fd, ENCLAVE_INIT);

        enclave = mmap(sgx_fd, ... PROT_READ);
        mprotect(enclave, ..., PROT_READ | PROT_EXEC);


My concern is that if we merge this

        ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);

without ->mprotect(), we can't actually enforce the declared protections.  And
if we drop the field altogether:

        ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);

then we can't implement security_enclave_load().
Dave Hansen Sept. 25, 2020, 5:18 p.m. UTC | #38
Thanks for the walkthrough.  The thing that clicked for me seeing those
examples was how the earlier ioctl(ADD_PAGE) is "bound" to later
enforcement actions at enclave PTE creation time.

On 9/24/20 5:00 PM, Sean Christopherson wrote:
> My concern is that if we merge this
> 
>         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);
> 
> without ->mprotect(), we can't actually enforce the declared protections.  And
> if we drop the field altogether:
> 
>         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);
> 
> then we can't implement security_enclave_load().

To me, it's perfectly OK to have parts of the ABI which are unused.  It
sure makes them harder to test if there are no actual users in the code,
but if it solves a real problem with the ABI, I'm fine with it.

Let's see if I can put all the pieces together.

Background:

1. SGX enclave pages are populated with data by copying data to them
   from normal memory via: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, src_ptr...);
2. We want to be able to restrict those normal memory data sources.  For
   instance, before copying data to an executable enclave page, we might
   ensure that the source is executable.
3. Enclave page permissions are dynamic just like normal permissions and
   can be adjusted at runtime with mprotect() (along with a
   corresponding special instruction inside the enclave)
4. The original data source may have have long since vanished at the
   time when enclave page permission are established (mmap() or
   mprotect())

Solution:

The solution is to force enclaves creators to declare their intent up
front to ioctl(ENCLAVE_ADD_PAGE).  This intent can me immediately
compared to the source data mapping (and rejected if necessary).  It is
also stashed off and then later compared with enclave PTEs to ensure
that any future mmap()/mprotect() operations performed by the enclave
creator or the enclave itself are consistent with the earlier declared
permissions.

Essentially, this means that whenever the kernel is asked to change an
enclave PTE, it needs to ensure the change is consistent with that
stashed intent.  There is an existing vm_ops->mmap() hook which allows
SGX to do that for mmap().  However, there is no ->mprotect() hook.  Add
a vm_ops->mprotect() hook so that mprotect() operations which are
inconsistent with any page's stashed intent can be rejected by the driver.

Implications:

However, there is currently no implementation of the intent checks at
the time of ioctl(ENCLAVE_ADD_PAGE).  That means that the intent
argument (SGX_PROT_*) is currently unused.

--

Is that all correct?  Did I miss anything?
Sean Christopherson Sept. 25, 2020, 7:43 p.m. UTC | #39
On Fri, Sep 25, 2020 at 10:18:28AM -0700, Dave Hansen wrote:
> Thanks for the walkthrough.  The thing that clicked for me seeing those
> examples was how the earlier ioctl(ADD_PAGE) is "bound" to later
> enforcement actions at enclave PTE creation time.
> 
> On 9/24/20 5:00 PM, Sean Christopherson wrote:
> > My concern is that if we merge this
> > 
> >         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, SGX_PROT_READ | SGX_PROT_EXEC, ptr, size);
> > 
> > without ->mprotect(), we can't actually enforce the declared protections.  And
> > if we drop the field altogether:
> > 
> >         ioctl(sgx_fd, ENCLAVE_ADD_PAGE, ptr, size);
> > 
> > then we can't implement security_enclave_load().
> 
> To me, it's perfectly OK to have parts of the ABI which are unused.  It
> sure makes them harder to test if there are no actual users in the code,
> but if it solves a real problem with the ABI, I'm fine with it.
> 
> Let's see if I can put all the pieces together.
> 
> Background:
> 
> 1. SGX enclave pages are populated with data by copying data to them
>    from normal memory via: ioctl(sgx_fd, ENCLAVE_ADD_PAGE, src_ptr...);
> 2. We want to be able to restrict those normal memory data sources.  For
>    instance, before copying data to an executable enclave page, we might
>    ensure that the source is executable.
> 3. Enclave page permissions are dynamic just like normal permissions and
>    can be adjusted at runtime with mprotect() (along with a
>    corresponding special instruction inside the enclave)
> 4. The original data source may have have long since vanished at the
>    time when enclave page permission are established (mmap() or
>    mprotect())
> 
> Solution:
> 
> The solution is to force enclaves creators to declare their intent up
> front to ioctl(ENCLAVE_ADD_PAGE).  This intent can me immediately
> compared to the source data mapping (and rejected if necessary).  It is
> also stashed off and then later compared with enclave PTEs to ensure
> that any future mmap()/mprotect() operations performed by the enclave
> creator or the enclave itself are consistent with the earlier declared
> permissions.
> 
> Essentially, this means that whenever the kernel is asked to change an
> enclave PTE, it needs to ensure the change is consistent with that
> stashed intent.  There is an existing vm_ops->mmap() hook which allows
> SGX to do that for mmap().  However, there is no ->mprotect() hook.  Add
> a vm_ops->mprotect() hook so that mprotect() operations which are
> inconsistent with any page's stashed intent can be rejected by the driver.

Yes to all of the above.

> Implications:
> 
> However, there is currently no implementation of the intent checks at
> the time of ioctl(ENCLAVE_ADD_PAGE).

Correct.

> That means that the intent argument (SGX_PROT_*) is currently unused.

No, the intent argument is used (eventually) by SGX's ->mprotect()
implementation, i.e. sgx_mprotect() enforces that the actual protections are a
subset of the declared/intended protections.

If ->mprotect() is not merged, then it yes, it will be unused.  And therein
lies the problem as the kernel can't start using/enforcing the intent without
breaking userspace.  E.g. an enclave loaded with SGX_PROT_READ but mprotect()'d
with PROT_READ | PROT_EXEC would break if sgx_mprotect() came along.

One way to avoid introducing ->mprotect() would be to require all enclaves to
declare all pages with READ|WRITE|EXEC.  Then we could drop sgx_mprotect()
since the mprotect() permissions are guaranteed to be a subset of the declared
permissions.  That would have the added bonus of eliminating the per-page
checks in sgx_mmap()/sgx_mprotect(), though I've no idea if that is a
meaningful optmization or it's lost in the noise.

The big downside of requiring READ|WRITE|EXEC is that it will make life hell
for a LSM policy owner if they ever want to apply EXECMEM or EXECMOD style
restritions on enclaves, i.e. if SELinux folks want to add
security_enclave_load().

I find that I'm more or less ok with that approach, in no small part because
introducing security_enclave_load() might be a pretty big "if", e.g. security
folks may decide that they'd rather allow/deny enclaves based on the
measurement or signer of the enclave and eschew per-page checks entirely.

> --
> 
> Is that all correct?  Did I miss anything?
Dave Hansen Sept. 25, 2020, 7:53 p.m. UTC | #40
On 9/25/20 12:43 PM, Sean Christopherson wrote:
>> That means that the intent argument (SGX_PROT_*) is currently unused.
> No, the intent argument is used (eventually) by SGX's ->mprotect()
> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> subset of the declared/intended protections.
> 
> If ->mprotect() is not merged, then it yes, it will be unused.

OK, I think I've got it.

I think I'm OK with adding ->mprotect().  As long as folks buy into the
argument that intent needs to be checked at mmap() time, they obviously
need to be checked at mprotect() too.

Jarkko, if you want to try and rewrite the changelog, capturing the
discussion here and reply, I think I can ack the resulting patch.  I
don't know if that will satisfy the request from Boris from an ack from
a "mm person", but we can at least start there. :)

Please be judicious in what you include in the changelog.  There's been
a lot of detritus in them.  Let's keep it as short, sweet, simple and on
topic as we can.
Andy Lutomirski Sept. 26, 2020, 4:15 a.m. UTC | #41
> On Sep 25, 2020, at 12:53 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> 
> On 9/25/20 12:43 PM, Sean Christopherson wrote:
>>> That means that the intent argument (SGX_PROT_*) is currently unused.
>> No, the intent argument is used (eventually) by SGX's ->mprotect()
>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
>> subset of the declared/intended protections.
>> 
>> If ->mprotect() is not merged, then it yes, it will be unused.
> 
> OK, I think I've got it.
> 
> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> argument that intent needs to be checked at mmap() time, they obviously
> need to be checked at mprotect() too.
> 
> Jarkko, if you want to try and rewrite the changelog, capturing the
> discussion here and reply, I think I can ack the resulting patch.  I
> don't know if that will satisfy the request from Boris from an ack from
> a "mm person", but we can at least start there. :)

I think I agree. ->mprotect seems reasonable to me.

FWIW, I don’t think I should ack this particular thing — it was, to a decent extent, my suggestion in the first place, so I’m biased. I think it turned into something reasonable, and the ->mprotect mechanism seems easily supportable and plausibly useful for other purposes down the road.

> 
> Please be judicious in what you include in the changelog.  There's been
> a lot of detritus in them.  Let's keep it as short, sweet, simple and on
> topic as we can.
Jarkko Sakkinen Sept. 28, 2020, 12:53 a.m. UTC | #42
On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >> That means that the intent argument (SGX_PROT_*) is currently unused.
> > No, the intent argument is used (eventually) by SGX's ->mprotect()
> > implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> > subset of the declared/intended protections.
> > 
> > If ->mprotect() is not merged, then it yes, it will be unused.
> 
> OK, I think I've got it.
> 
> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> argument that intent needs to be checked at mmap() time, they obviously
> need to be checked at mprotect() too.
> 
> Jarkko, if you want to try and rewrite the changelog, capturing the
> discussion here and reply, I think I can ack the resulting patch.  I
> don't know if that will satisfy the request from Boris from an ack from
> a "mm person", but we can at least start there. :)

I think what it needs, based on what I've read, is the step by step
description of the EMODPE scenarion without this callback and with it.

I think other important thing to underline is that an LSM or any other
security measure can only do a sane decision when the enclave is loaded.
At that point we know the source (vm_file).

I.e. when you are doing mmap() or mprotect() you don't have that
information. The permissions kind of describe the contact made at that
point of time.

> Please be judicious in what you include in the changelog.  There's been
> a lot of detritus in them.  Let's keep it as short, sweet, simple and on
> topic as we can.

Of course.

/Jarkko
Dave Hansen Sept. 28, 2020, 2:04 p.m. UTC | #43
On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
>> On 9/25/20 12:43 PM, Sean Christopherson wrote:
>>>> That means that the intent argument (SGX_PROT_*) is currently unused.
>>> No, the intent argument is used (eventually) by SGX's ->mprotect()
>>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
>>> subset of the declared/intended protections.
>>>
>>> If ->mprotect() is not merged, then it yes, it will be unused.
>>
>> OK, I think I've got it.
>>
>> I think I'm OK with adding ->mprotect().  As long as folks buy into the
>> argument that intent needs to be checked at mmap() time, they obviously
>> need to be checked at mprotect() too.
>>
>> Jarkko, if you want to try and rewrite the changelog, capturing the
>> discussion here and reply, I think I can ack the resulting patch.  I
>> don't know if that will satisfy the request from Boris from an ack from
>> a "mm person", but we can at least start there. :)
> 
> I think what it needs, based on what I've read, is the step by step
> description of the EMODPE scenarion without this callback and with it.

EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
permissions still specify the most restrictive permissions, which is
what matters the most.

We care about the _worst_ the enclave can do, not what it imposes on
itself on top of that.

> I think other important thing to underline is that an LSM or any other
> security measure can only do a sane decision when the enclave is loaded.
> At that point we know the source (vm_file).

Right, you know the source, but it can be anonymous or a file.
Jarkko Sakkinen Sept. 28, 2020, 4:19 p.m. UTC | #44
On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> >> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >>>> That means that the intent argument (SGX_PROT_*) is currently unused.
> >>> No, the intent argument is used (eventually) by SGX's ->mprotect()
> >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> >>> subset of the declared/intended protections.
> >>>
> >>> If ->mprotect() is not merged, then it yes, it will be unused.
> >>
> >> OK, I think I've got it.
> >>
> >> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> >> argument that intent needs to be checked at mmap() time, they obviously
> >> need to be checked at mprotect() too.
> >>
> >> Jarkko, if you want to try and rewrite the changelog, capturing the
> >> discussion here and reply, I think I can ack the resulting patch.  I
> >> don't know if that will satisfy the request from Boris from an ack from
> >> a "mm person", but we can at least start there. :)
> > 
> > I think what it needs, based on what I've read, is the step by step
> > description of the EMODPE scenarion without this callback and with it.
> 
> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> permissions still specify the most restrictive permissions, which is
> what matters the most.
> 
> We care about the _worst_ the enclave can do, not what it imposes on
> itself on top of that.

AFAIK it is not, or what we are protecting against with this anyway
then?

Let say an LSM makes decision for the permissions based on origin. If we
do not have this you can:

1. EMODPE
2. mprotect

I.e. whatever LSM decides, won't matter.

The other case, noexec, is now unconditionally denied.

> > I think other important thing to underline is that an LSM or any other
> > security measure can only do a sane decision when the enclave is loaded.
> > At that point we know the source (vm_file).
> 
> Right, you know the source, but it can be anonymous or a file.

They are both origin, the point being that you know what you're dealing
with when you build the enclave, not when you map it.

This is my current rewrite of the commit message in my master branch:

"
    mm: Add 'mprotect' callback to vm_ops
    
    Intel Sofware Guard eXtensions (SGX) allows creation of blobs called
    enclaves, for which page permissions are defined when the enclave is first
    loaded. Once an enclave is loaded and initialized, it can be mapped to the
    process address space.
    
    There is no standard file format for enclaves. They are dynamically built
    and the ways how enclaves are deployed differ greatly. For an app you might
    want to have a simple static binary, but on the other hand for a container
    you might want to dynamically create the whole thing at run-time. Also, the
    existing ecosystem for SGX is already large, which would make the task very
    hard.
    
    Finally, even if there was a standard format, one would still want a
    dynamic way to add pages to the enclave. One big reason for this is that
    enclaves have load time defined pages that represent entry points to the
    enclave. Each entry point can service one hardware thread at a time and
    you might want to run-time parametrize this depending on your environment.
    
    The consequence is that enclaves are best created with an ioctl API and the
    access control can be based only to the origin of the source file for the
    enclave data, i.e. on VMA file pointer and page permissions. For example,
    this could be done with LSM hooks that are triggered in the appropriate
    ioctl's and they could make the access control decision based on this
    information.
    
    Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
    upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
    could upgrade its permissions by using EMODPE followed by an appropriate
    mprotect() call. This would be completely hidden from the kernel.
    
    Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
    that will ensure that {mmap, mprotect}() permissions do not surpass any of
    the original page permissions. This feature allows to maintain and refine
    sane access control for enclaves.
"

I'm mostly happy with this but am open for change suggestions.

/Jarkko
Dave Hansen Sept. 28, 2020, 4:48 p.m. UTC | #45
On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
>> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
>> permissions still specify the most restrictive permissions, which is
>> what matters the most.
>>
>> We care about the _worst_ the enclave can do, not what it imposes on
>> itself on top of that.
> 
> AFAIK it is not, or what we are protecting against with this anyway
> then?
> 
> Let say an LSM makes decision for the permissions based on origin. If we
> do not have this you can:
> 
> 1. EMODPE
> 2. mprotect

The thing that matters is that the enclave needs relaxed permissions
from the kernel.  What it *ALSO* needs to do to *ITSELF* to get those
permissions is entirely irrelevant to the kernel.

> I.e. whatever LSM decides, won't matter.
> 
> The other case, noexec, is now unconditionally denied.



>>> I think other important thing to underline is that an LSM or any other
>>> security measure can only do a sane decision when the enclave is loaded.
>>> At that point we know the source (vm_file).
>>
>> Right, you know the source, but it can be anonymous or a file.
> 
> They are both origin, the point being that you know what you're dealing
> with when you build the enclave, not when you map it.
> 
> This is my current rewrite of the commit message in my master branch:
> 
> "
>     mm: Add 'mprotect' callback to vm_ops
>     
>     Intel Sofware Guard eXtensions (SGX) allows creation of blobs called
>     enclaves, for which page permissions are defined when the enclave is first
>     loaded. Once an enclave is loaded and initialized, it can be mapped to the
>     process address space.
>     
>     There is no standard file format for enclaves. They are dynamically built
>     and the ways how enclaves are deployed differ greatly. For an app you might
>     want to have a simple static binary, but on the other hand for a container
>     you might want to dynamically create the whole thing at run-time. Also, the
>     existing ecosystem for SGX is already large, which would make the task very
>     hard.

I'm sorry I ever mentioned the file format.  Please remove any mention
of it.  It's irrelevant.  This entire paragraph is irrelevant.

>     Finally, even if there was a standard format, one would still want a
>     dynamic way to add pages to the enclave. One big reason for this is that
>     enclaves have load time defined pages that represent entry points to the
>     enclave. Each entry point can service one hardware thread at a time and
>     you might want to run-time parametrize this depending on your environment.

I also don't know what this paragraph has to do with the mprotect()
hook.  Please remove it.

>     The consequence is that enclaves are best created with an ioctl API and the
>     access control can be based only to the origin of the source file for the
>     enclave data, i.e. on VMA file pointer and page permissions. For example,

It's not strictly page permissions, though.  It's actually VMA
permissions.  The thing you copy from might be the zero page, and even
though it has Write=0 page permissions, apps are completely OK to write
to the address.  This is the WRITE vs. MAY_WRITE semantic in the VMA flags.

It's also not just about *files*.  Anonymous memory might or might not
be a valid source for enclave data based on LSM hooks.

>     this could be done with LSM hooks that are triggered in the appropriate
>     ioctl's and they could make the access control decision based on this
>     information.

This "appropriate ioctl's" is not good changelog material.  Please use
those bytes to convey actual information.

	... this could be done with LSM hooks which restrict the source
	of enclave page data

I don't care that it's an ioctl(), really.  What matters is what the
ioctl() does: copy data into enclave pages.

>     Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
>     upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
>     could upgrade its permissions by using EMODPE followed by an appropriate
>     mprotect() call. This would be completely hidden from the kernel.

There's too much irrelevant info.

I'll say it again: all that matters is that enclaves can legitimately,
safely, and securely have a need for the kernel to change page
permissions.  That's *IT*.  EMODPE just happens to be part of the
mechanism that makes these permission changes safe for enclaves.  It's a
side show.

>     Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
>     that will ensure that {mmap, mprotect}() permissions do not surpass any of
>     the original page permissions. This feature allows to maintain and refine
>     sane access control for enclaves.

Instead of "original", I'd stick to the "source" page nomenclature.
There are also "original" permissions with mprotect().

Also, it's literally OK for the enclave page permissions to surpass the
original (source) page permissions.  That sentence is incorrect, or at
least misleadingly imprecise.

> I'm mostly happy with this but am open for change suggestions.

I wrote a pretty nice description of this.  It was about 90% correct,
shorter, and conveyed more information.  I'd suggest starting with that.
Jarkko Sakkinen Sept. 28, 2020, 7:32 p.m. UTC | #46
On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote:
> On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> >> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> >> permissions still specify the most restrictive permissions, which is
> >> what matters the most.
> >>
> >> We care about the _worst_ the enclave can do, not what it imposes on
> >> itself on top of that.
> > 
> > AFAIK it is not, or what we are protecting against with this anyway
> > then?
> > 
> > Let say an LSM makes decision for the permissions based on origin. If we
> > do not have this you can:
> > 
> > 1. EMODPE
> > 2. mprotect
> 
> The thing that matters is that the enclave needs relaxed permissions
> from the kernel.  What it *ALSO* needs to do to *ITSELF* to get those
> permissions is entirely irrelevant to the kernel.

Lets try to find the root of misunderstanding, shall we?

I'm assuming that your statement is encapsulated to:

https://lore.kernel.org/linux-sgx/32fc9df4-d4aa-6768-aa06-0035427b7535@intel.com/

I do agree with this.

And here is a direct quote:

"It is also stashed off and then later compared with enclave PTEs to
ensure that any future mmap()/mprotect() operations performed by the
enclave creator or the enclave itself are consistent with the earlier
declared permissions."

Without the mprotect callback in place, by using EMODPE and mprotect,
one could surpass the permisssions that we declared earlier.

With the callback in place this is not possible. EMODPE can be freely
used but mprotect() always caps the permissions. It enables us to *not
care* about EMODPE.

My problem is that I fully agree what you say in your description but
disagree on that EMODPE should not be mentioned.

> >     There is no standard file format for enclaves. They are dynamically built
> >     and the ways how enclaves are deployed differ greatly. For an app you might
> >     want to have a simple static binary, but on the other hand for a container
> >     you might want to dynamically create the whole thing at run-time. Also, the
> >     existing ecosystem for SGX is already large, which would make the task very
> >     hard.
> 
> I'm sorry I ever mentioned the file format.  Please remove any mention
> of it.  It's irrelevant.  This entire paragraph is irrelevant.

Not sure if it is or not. It is merely to state that execve() path is
possible. Perhaps should be toned down in some way. Should be like the
a small remark at most.

> >     Finally, even if there was a standard format, one would still want a
> >     dynamic way to add pages to the enclave. One big reason for this is that
> >     enclaves have load time defined pages that represent entry points to the
> >     enclave. Each entry point can service one hardware thread at a time and
> >     you might want to run-time parametrize this depending on your environment.
> 
> I also don't know what this paragraph has to do with the mprotect()
> hook.  Please remove it.

Agreed.

> >     The consequence is that enclaves are best created with an ioctl API and the
> >     access control can be based only to the origin of the source file for the
> >     enclave data, i.e. on VMA file pointer and page permissions. For example,
> 
> It's not strictly page permissions, though.  It's actually VMA
> permissions.  The thing you copy from might be the zero page, and even
> though it has Write=0 page permissions, apps are completely OK to write
> to the address.  This is the WRITE vs. MAY_WRITE semantic in the VMA flags.
> 
> It's also not just about *files*.  Anonymous memory might or might not
> be a valid source for enclave data based on LSM hooks.

Yes, this should be refined, agreed. Source can be either anonymous page
or a file, I do of course understand that.

> >     this could be done with LSM hooks that are triggered in the appropriate
> >     ioctl's and they could make the access control decision based on this
> >     information.
> 
> This "appropriate ioctl's" is not good changelog material.  Please use
> those bytes to convey actual information.
> 
> 	... this could be done with LSM hooks which restrict the source
> 	of enclave page data
> 
> I don't care that it's an ioctl(), really.  What matters is what the
> ioctl() does: copy data into enclave pages.

Agreed.

> >     Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> >     upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> >     could upgrade its permissions by using EMODPE followed by an appropriate
> >     mprotect() call. This would be completely hidden from the kernel.
> 
> There's too much irrelevant info.
> 
> I'll say it again: all that matters is that enclaves can legitimately,
> safely, and securely have a need for the kernel to change page
> permissions.  That's *IT*.  EMODPE just happens to be part of the
> mechanism that makes these permission changes safe for enclaves.  It's a
> side show.

Disagree on this. I wrote my statement about. Maybe it should not be
driving argument but should be definitely part of the description.

> >     Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> >     that will ensure that {mmap, mprotect}() permissions do not surpass any of
> >     the original page permissions. This feature allows to maintain and refine
> >     sane access control for enclaves.
> 
> Instead of "original", I'd stick to the "source" page nomenclature.
> There are also "original" permissions with mprotect().
> 
> Also, it's literally OK for the enclave page permissions to surpass the
> original (source) page permissions.  That sentence is incorrect, or at
> least misleadingly imprecise.

Yes it is. It's fine to use EMODPE to upgrade the perms, and by having
this hook, doing anything nasty with it is impossible.

> > I'm mostly happy with this but am open for change suggestions.
> 
> I wrote a pretty nice description of this.  It was about 90% correct,
> shorter, and conveyed more information.  I'd suggest starting with that.

I should have added a disclaimer that my description is not up to date.
Just do not want to make anything final before this EMODPE discussion
has some conclusion.

I'm fine using your description as basis for the commit message if as long
as these few details are settled.

/Jarkko
Dave Hansen Sept. 28, 2020, 7:45 p.m. UTC | #47
On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
> My problem is that I fully agree what you say in your description but
> disagree on that EMODPE should not be mentioned.

I'll just be very clear: I'm not willing to ack any patch with a
changelog that has more than a passing mention of EMODPE.

Do what you think is best, but if sticking to your guns may deplete the
pool of folks willing to ack your patch.
Jarkko Sakkinen Sept. 28, 2020, 8:18 p.m. UTC | #48
On Mon, Sep 28, 2020 at 09:48:10AM -0700, Dave Hansen wrote:
> On 9/28/20 9:19 AM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:
> >> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> >> permissions still specify the most restrictive permissions, which is
> >> what matters the most.
> >>
> >> We care about the _worst_ the enclave can do, not what it imposes on
> >> itself on top of that.
> > 
> > AFAIK it is not, or what we are protecting against with this anyway
> > then?
> > 
> > Let say an LSM makes decision for the permissions based on origin. If we
> > do not have this you can:
> > 
> > 1. EMODPE
> > 2. mprotect
> 
> The thing that matters is that the enclave needs relaxed permissions
> from the kernel.  What it *ALSO* needs to do to *ITSELF* to get those
> permissions is entirely irrelevant to the kernel.

Lets try to find the root of misunderstanding, shall we?

I'm assuming that your statement is encapsulated to:

https://lore.kernel.org/linux-sgx/32fc9df4-d4aa-6768-aa06-0035427b7535@intel.com/

I do agree with this.

And here is a direct quote:

"It is also stashed off and then later compared with enclave PTEs to
ensure that any future mmap()/mprotect() operations performed by the
enclave creator or the enclave itself are consistent with the earlier
declared permissions."

Without the mprotect callback in place, by using EMODPE and mprotect,
one could surpass the permisssions that we declared earlier.

With the callback in place this is not possible. EMODPE can be freely
used but mprotect() always caps the permissions. It enables us to *not
care* about EMODPE.

My problem is that I fully agree what you say in your description but
disagree on that EMODPE should not be mentioned.

> >     There is no standard file format for enclaves. They are dynamically built
> >     and the ways how enclaves are deployed differ greatly. For an app you might
> >     want to have a simple static binary, but on the other hand for a container
> >     you might want to dynamically create the whole thing at run-time. Also, the
> >     existing ecosystem for SGX is already large, which would make the task very
> >     hard.
> 
> I'm sorry I ever mentioned the file format.  Please remove any mention
> of it.  It's irrelevant.  This entire paragraph is irrelevant.

Not sure if it is or not. It is merely to state that execve() path is
possible. Perhaps should be toned down in some way. Should be like the
a small remark at most.

> >     Finally, even if there was a standard format, one would still want a
> >     dynamic way to add pages to the enclave. One big reason for this is that
> >     enclaves have load time defined pages that represent entry points to the
> >     enclave. Each entry point can service one hardware thread at a time and
> >     you might want to run-time parametrize this depending on your environment.
> 
> I also don't know what this paragraph has to do with the mprotect()
> hook.  Please remove it.

Agreed.

> >     The consequence is that enclaves are best created with an ioctl API and the
> >     access control can be based only to the origin of the source file for the
> >     enclave data, i.e. on VMA file pointer and page permissions. For example,
> 
> It's not strictly page permissions, though.  It's actually VMA
> permissions.  The thing you copy from might be the zero page, and even
> though it has Write=0 page permissions, apps are completely OK to write
> to the address.  This is the WRITE vs. MAY_WRITE semantic in the VMA flags.
> 
> It's also not just about *files*.  Anonymous memory might or might not
> be a valid source for enclave data based on LSM hooks.

Yes, this should be refined, agreed. Source can be either anonymous page
or a file, I do of course understand that.

> >     this could be done with LSM hooks that are triggered in the appropriate
> >     ioctl's and they could make the access control decision based on this
> >     information.
> 
> This "appropriate ioctl's" is not good changelog material.  Please use
> those bytes to convey actual information.
> 
> 	... this could be done with LSM hooks which restrict the source
> 	of enclave page data
> 
> I don't care that it's an ioctl(), really.  What matters is what the
> ioctl() does: copy data into enclave pages.

Agreed.

> >     Unfortunately, there is ENCLS[EMODPE] that a running enclave can use to
> >     upgrade its permissions. If we do not limit mmap() and mprotect(), enclave
> >     could upgrade its permissions by using EMODPE followed by an appropriate
> >     mprotect() call. This would be completely hidden from the kernel.
> 
> There's too much irrelevant info.
> 
> I'll say it again: all that matters is that enclaves can legitimately,
> safely, and securely have a need for the kernel to change page
> permissions.  That's *IT*.  EMODPE just happens to be part of the
> mechanism that makes these permission changes safe for enclaves.  It's a
> side show.

Disagree on this. I wrote my statement about. Maybe it should not be
driving argument but should be definitely part of the description.

> >     Add 'mprotect' hook to vm_ops, so that a callback can be implemeted for SGX
> >     that will ensure that {mmap, mprotect}() permissions do not surpass any of
> >     the original page permissions. This feature allows to maintain and refine
> >     sane access control for enclaves.
> 
> Instead of "original", I'd stick to the "source" page nomenclature.
> There are also "original" permissions with mprotect().
> 
> Also, it's literally OK for the enclave page permissions to surpass the
> original (source) page permissions.  That sentence is incorrect, or at
> least misleadingly imprecise.

Yes it is. It's fine to use EMODPE to upgrade the perms, and by having
this hook, doing anything nasty with it is impossible.

> > I'm mostly happy with this but am open for change suggestions.
> 
> I wrote a pretty nice description of this.  It was about 90% correct,
> shorter, and conveyed more information.  I'd suggest starting with that.

I should have added a disclaimer that my description is not up to date.
Just do not want to make anything final before this EMODPE discussion
has some conclusion.

I'm fine using your description as basis for the commit message if as long
as these few details are settled.

/Jarkko
Jarkko Sakkinen Sept. 28, 2020, 8:19 p.m. UTC | #49
On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote:
> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
> > My problem is that I fully agree what you say in your description but
> > disagree on that EMODPE should not be mentioned.
> 
> I'll just be very clear: I'm not willing to ack any patch with a
> changelog that has more than a passing mention of EMODPE.
> 
> Do what you think is best, but if sticking to your guns may deplete the
> pool of folks willing to ack your patch.

I do see it mentioned in other responses too in this thread, and not
just mine.

And here is even a request to get it to the changelog:

https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net/

I'm absolutely fine not to mention EMODPE but after re-reading the
thread, it is not like there is one voice on it. I don't really
care all that much whether it is mentioned or not but there should
be some reasonable logic behind the decision.

PS. I just noticed that my previous response did not reach lore so
I bounced it again.

/Jarkko
Andy Lutomirski Sept. 29, 2020, 1:37 a.m. UTC | #50
> On Sep 28, 2020, at 1:20 PM, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> 
> On Mon, Sep 28, 2020 at 12:45:27PM -0700, Dave Hansen wrote:
>>> On 9/28/20 12:32 PM, Jarkko Sakkinen wrote:
>>> My problem is that I fully agree what you say in your description but
>>> disagree on that EMODPE should not be mentioned.
>> 
>> I'll just be very clear: I'm not willing to ack any patch with a
>> changelog that has more than a passing mention of EMODPE.
>> 
>> Do what you think is best, but if sticking to your guns may deplete the
>> pool of folks willing to ack your patch.
> 
> I do see it mentioned in other responses too in this thread, and not
> just mine.
> 
> And here is even a request to get it to the changelog:
> 
> https://lore.kernel.org/linux-sgx/1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net/
> 
> I'm absolutely fine not to mention EMODPE but after re-reading the
> thread, it is not like there is one voice on it. I don't really
> care all that much whether it is mentioned or not but there should
> be some reasonable logic behind the decision.

I don’t personally care that much about EMODPE but, you could probably get the point across with something like:

SGX’s EPCM permission bits do not obviate the need to enforce these rules in the PTEs because enclaves can freely modify the EPCM permissions using EMODPE.

IOW, EMODPE is not really special here; rather, EMODPE’s existence demonstrates that EADD / EEXTEND are not special.
Jarkko Sakkinen Sept. 29, 2020, 4:05 a.m. UTC | #51
On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
> I don’t personally care that much about EMODPE but, you could probably
> get the point across with something like:
> 
> SGX’s EPCM permission bits do not obviate the need to enforce these
> rules in the PTEs because enclaves can freely modify the EPCM
> permissions using EMODPE.
> 
> IOW, EMODPE is not really special here; rather, EMODPE’s existence
> demonstrates that EADD / EEXTEND are not special.

So I did "disagree and commit" with this one. I'm not actually
diagreeing on anything what Dave wrote, on the contrary it is an
understandable high level description. I just thought that it would not
hurt to remark that the ISA contains such peculiarities as EMODPE.

I did only very rudimentary clean up for the text (e.g. fix the ioctl
name, add shortt summary and not much else).

Does not make sense to waste more time to this. I'll move on to
implement the missing boot time patching for the vDSO so that we
get the next version out.

"
mm: Add 'mprotect' hook to struct vm_operations_struct

Background
==========

1. SGX enclave pages are populated with data by copying data to them
   from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
2. We want to be able to restrict those normal memory data sources.  For
   instance, before copying data to an executable enclave page, we might
   ensure that the source is executable.
3. Enclave page permissions are dynamic just like normal permissions and
   can be adjusted at runtime with mprotect() (along with a
   corresponding special instruction inside the enclave).
4. The original data source may have have long since vanished at the
   time when enclave page permission are established (mmap() or
   mprotect()).

Solution
========

The solution is to force enclaves creators to declare their intent up front
to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
compared to the source data mapping (and rejected if necessary).  It is
also stashed off and then later compared with enclave PTEs to ensure that
any future mmap()/mprotect() operations performed by the enclave creator or
the enclave itself are consistent with the earlier declared permissions.

Essentially, this means that whenever the kernel is asked to change an
enclave PTE, it needs to ensure the change is consistent with that stashed
intent.  There is an existing vm_ops->mmap() hook which allows SGX to do
that for mmap().  However, there is no ->mprotect() hook.  Add a
vm_ops->mprotect() hook so that mprotect() operations which are
inconsistent with any page's stashed intent can be rejected by the driver.

Implications
============

However, there is currently no implementation of the intent checks at the
time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  That means that the intent
argument (SGX_PROT_*) is currently unused.
"

/Jarkko
Dave Hansen Sept. 29, 2020, 2:24 p.m. UTC | #52
On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
> On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
>> I don’t personally care that much about EMODPE but, you could probably
>> get the point across with something like:
>>
>> SGX’s EPCM permission bits do not obviate the need to enforce these
>> rules in the PTEs because enclaves can freely modify the EPCM
>> permissions using EMODPE.
>>
>> IOW, EMODPE is not really special here; rather, EMODPE’s existence
>> demonstrates that EADD / EEXTEND are not special.
> 
> So I did "disagree and commit" with this one. I'm not actually
> diagreeing on anything what Dave wrote, on the contrary it is an
> understandable high level description. I just thought that it would not
> hurt to remark that the ISA contains such peculiarities as EMODPE.
> 
> I did only very rudimentary clean up for the text (e.g. fix the ioctl
> name, add shortt summary and not much else).
> 
> Does not make sense to waste more time to this. I'll move on to
> implement the missing boot time patching for the vDSO so that we
> get the next version out.
> 
> "
> mm: Add 'mprotect' hook to struct vm_operations_struct
> 
> Background
> ==========
> 
> 1. SGX enclave pages are populated with data by copying data to them
>    from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
> 2. We want to be able to restrict those normal memory data sources.  For
>    instance, before copying data to an executable enclave page, we might
>    ensure that the source is executable.

I know I wrote that.  I suck, and I wrote it in a changelog-unacceptable
way.  Folks dislike the use of "we" in these things.  Here's a better
version:

  2. It is desirable to be able to restrict those normal memory data
     sources.  For instance, the kernel can ensure that the source is
     executable, before copying data to an executable enclave page.

> 3. Enclave page permissions are dynamic just like normal permissions and
>    can be adjusted at runtime with mprotect() (along with a
>    corresponding special instruction inside the enclave).
> 4. The original data source may have have long since vanished at the
>    time when enclave page permission are established (mmap() or
>    mprotect()).
> 
> Solution
> ========
> 
> The solution is to force enclaves creators to declare their intent up front
> to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
> compared to the source data mapping (and rejected if necessary).  It is
> also stashed off and then later compared with enclave PTEs to ensure that
> any future mmap()/mprotect() operations performed by the enclave creator or
> the enclave itself are consistent with the earlier declared permissions.

Let's also say "... or *requested* by the enclave itself ...", since the
enclave itself can't directly make syscalls.

> Essentially, this means that whenever the kernel is asked to change an
> enclave PTE, it needs to ensure the change is consistent with that stashed
> intent.  There is an existing vm_ops->mmap() hook which allows SGX to do
> that for mmap().  However, there is no ->mprotect() hook.  Add a
> vm_ops->mprotect() hook so that mprotect() operations which are
> inconsistent with any page's stashed intent can be rejected by the driver.
> 
> Implications
> ============
> 
> However, there is currently no implementation of the intent checks at the
> time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  That means that the intent
> argument (SGX_PROT_*) is currently unused.

This was incorrect to say.  Sean corrected me on this point.  Could you
look through the thread and incorporate that?
Jarkko Sakkinen Sept. 30, 2020, 12:20 a.m. UTC | #53
On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote:
> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
> > On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
> >> I don’t personally care that much about EMODPE but, you could probably
> >> get the point across with something like:
> >>
> >> SGX’s EPCM permission bits do not obviate the need to enforce these
> >> rules in the PTEs because enclaves can freely modify the EPCM
> >> permissions using EMODPE.
> >>
> >> IOW, EMODPE is not really special here; rather, EMODPE’s existence
> >> demonstrates that EADD / EEXTEND are not special.
> > 
> > So I did "disagree and commit" with this one. I'm not actually
> > diagreeing on anything what Dave wrote, on the contrary it is an
> > understandable high level description. I just thought that it would not
> > hurt to remark that the ISA contains such peculiarities as EMODPE.
> > 
> > I did only very rudimentary clean up for the text (e.g. fix the ioctl
> > name, add shortt summary and not much else).
> > 
> > Does not make sense to waste more time to this. I'll move on to
> > implement the missing boot time patching for the vDSO so that we
> > get the next version out.
> > 
> > "
> > mm: Add 'mprotect' hook to struct vm_operations_struct
> > 
> > Background
> > ==========
> > 
> > 1. SGX enclave pages are populated with data by copying data to them
> >    from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
> > 2. We want to be able to restrict those normal memory data sources.  For
> >    instance, before copying data to an executable enclave page, we might
> >    ensure that the source is executable.
> 
> I know I wrote that.  I suck, and I wrote it in a changelog-unacceptable
> way.  Folks dislike the use of "we" in these things.  Here's a better
> version:
> 
>   2. It is desirable to be able to restrict those normal memory data
>      sources.  For instance, the kernel can ensure that the source is
>      executable, before copying data to an executable enclave page.
> 
> > 3. Enclave page permissions are dynamic just like normal permissions and
> >    can be adjusted at runtime with mprotect() (along with a
> >    corresponding special instruction inside the enclave).
> > 4. The original data source may have have long since vanished at the
> >    time when enclave page permission are established (mmap() or
> >    mprotect()).
> > 
> > Solution
> > ========
> > 
> > The solution is to force enclaves creators to declare their intent up front
> > to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
> > compared to the source data mapping (and rejected if necessary).  It is
> > also stashed off and then later compared with enclave PTEs to ensure that
> > any future mmap()/mprotect() operations performed by the enclave creator or
> > the enclave itself are consistent with the earlier declared permissions.
> 
> Let's also say "... or *requested* by the enclave itself ...", since the
> enclave itself can't directly make syscalls.

Yes, it is definitely more understandable way to say it. Do you mind
if I rephrase it as:

"It is also stashed off and then later compared with enclave PTEs to
ensure that any future mmap()/mprotect() operations performed by the
enclave creator or requested the enclave by itself (e.g. by issuing
ECLU[EMODPE]) are consistent with the earlier declared permissions."

I'd just mention EMODPE as an example, but I'm also perfectly fine
leaving that out :-) Not a big deal for me.

Also, should there be commas, i.e. ", or requested the enclave by
itself,"? I suck with English comma rules.

> > Essentially, this means that whenever the kernel is asked to change an
> > enclave PTE, it needs to ensure the change is consistent with that stashed
> > intent.  There is an existing vm_ops->mmap() hook which allows SGX to do
> > that for mmap().  However, there is no ->mprotect() hook.  Add a
> > vm_ops->mprotect() hook so that mprotect() operations which are
> > inconsistent with any page's stashed intent can be rejected by the driver.
> > 
> > Implications
> > ============
> > 
> > However, there is currently no implementation of the intent checks at the
> > time of ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  That means that the intent
> > argument (SGX_PROT_*) is currently unused.
> 
> This was incorrect to say.  Sean corrected me on this point.  Could you
> look through the thread and incorporate that?

OK, so we are probably talking about [1] here, right?

There are at least two checks done with and without the callback:

A. TCS pages are required to be passed with zero EPCM permissions,
   the reason being that CPU will silently overwrite its permissions
   zero. This check resides in sgx_validate_secinfo() [2].
B. noexec partitions are unconditionally disallowed. This check
   resides in __sgx_encl_add_page() [2].

TCS pages are funky in the way that they are also required to be
mapped as RW. OK, then you might argue that why not just require
RW as ioctl supplied permissions. That would cause a mismatch with
CPU calculated MRENCLAVE and one calculated to SIGSTRUCT. I've
written in past quite length explanation of this to the kdoc
of sgx_ioc_enclave_add_pages() [2].

This was something that I did not find from Sean's response.

To encompensate all this information in a paragraph, I'd write along
the lines of

"ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES, ...) checks for every page that
Thread Control Structure (TCS) pages are always added with zero
permissions and no pages are sourced from noexec partitions. TCS pages
are pages that work as entry points to the enclave. This is the basic
acceptance criteria for any enclave page before it gets mapped.

After finishing this, the ioctl will project the enclave permissions to
the corresponding VMA permissions and stores the result for later
lookup.  For regular pages this is an identity mapping but as an
exception TCS pages are unconditionally mapped as RW VMA permssion even
though their enclave permissions are zero. This required by the ISA.

This information will be used by sgx_mmap() and sgx_vma_protect() to
enforce that higher permissions than the projected permissions will
not be used by checking this for each every page in the address
range.

By doing this, we give assets for LSM's to make decisions during the
build time based on projected VMA permissions and the source VMA
(either a file or anonymous mapping) that hold when the enclave is
finally mapped to the visible memory."

Is this sufficient?

[1] https://lore.kernel.org/linux-sgx/20200915112842.897265-1-jarkko.sakkinen@linux.intel.com/T/#m7e84af96d63dd8ec528422cfc942f42e3bdf4356
[2] https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git/tree/arch/x86/kernel/cpu/sgx/ioctl.c

/Jarkko
Dave Hansen Sept. 30, 2020, 2:35 p.m. UTC | #54
On 9/29/20 5:20 PM, Jarkko Sakkinen wrote:
> On Tue, Sep 29, 2020 at 07:24:24AM -0700, Dave Hansen wrote:
>> On 9/28/20 9:05 PM, Jarkko Sakkinen wrote:
>>> On Mon, Sep 28, 2020 at 06:37:54PM -0700, Andy Lutomirski wrote:
>>>> I don’t personally care that much about EMODPE but, you could probably
>>>> get the point across with something like:
>>>>
>>>> SGX’s EPCM permission bits do not obviate the need to enforce these
>>>> rules in the PTEs because enclaves can freely modify the EPCM
>>>> permissions using EMODPE.
>>>>
>>>> IOW, EMODPE is not really special here; rather, EMODPE’s existence
>>>> demonstrates that EADD / EEXTEND are not special.
>>>
>>> So I did "disagree and commit" with this one. I'm not actually
>>> diagreeing on anything what Dave wrote, on the contrary it is an
>>> understandable high level description. I just thought that it would not
>>> hurt to remark that the ISA contains such peculiarities as EMODPE.
>>>
>>> I did only very rudimentary clean up for the text (e.g. fix the ioctl
>>> name, add shortt summary and not much else).
>>>
>>> Does not make sense to waste more time to this. I'll move on to
>>> implement the missing boot time patching for the vDSO so that we
>>> get the next version out.
>>>
>>> "
>>> mm: Add 'mprotect' hook to struct vm_operations_struct
>>>
>>> Background
>>> ==========
>>>
>>> 1. SGX enclave pages are populated with data by copying data to them
>>>    from normal memory via ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).
>>> 2. We want to be able to restrict those normal memory data sources.  For
>>>    instance, before copying data to an executable enclave page, we might
>>>    ensure that the source is executable.
>>
>> I know I wrote that.  I suck, and I wrote it in a changelog-unacceptable
>> way.  Folks dislike the use of "we" in these things.  Here's a better
>> version:
>>
>>   2. It is desirable to be able to restrict those normal memory data
>>      sources.  For instance, the kernel can ensure that the source is
>>      executable, before copying data to an executable enclave page.
>>
>>> 3. Enclave page permissions are dynamic just like normal permissions and
>>>    can be adjusted at runtime with mprotect() (along with a
>>>    corresponding special instruction inside the enclave).
>>> 4. The original data source may have have long since vanished at the
>>>    time when enclave page permission are established (mmap() or
>>>    mprotect()).
>>>
>>> Solution
>>> ========
>>>
>>> The solution is to force enclaves creators to declare their intent up front
>>> to ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES).  This intent can me immediately
>>> compared to the source data mapping (and rejected if necessary).  It is
>>> also stashed off and then later compared with enclave PTEs to ensure that
>>> any future mmap()/mprotect() operations performed by the enclave creator or
>>> the enclave itself are consistent with the earlier declared permissions.
>>
>> Let's also say "... or *requested* by the enclave itself ...", since the
>> enclave itself can't directly make syscalls.
> 
> Yes, it is definitely more understandable way to say it. Do you mind
> if I rephrase it as:
> 
> "It is also stashed off and then later compared with enclave PTEs to
> ensure that any future mmap()/mprotect() operations performed by the
> enclave creator or requested the enclave by itself (e.g. by issuing
> ECLU[EMODPE]) are consistent with the earlier declared permissions."
> 
> I'd just mention EMODPE as an example, but I'm also perfectly fine
> leaving that out :-) Not a big deal for me.

If I say it's a big deal for me, will you remove the bloody thing?

Mentioning EMODPE is a distraction for this patch.  It's a big
distraction because it makes it sound like it is some kind of *peer* of
mmap()/mprotect().  It's not.  It's subservient to x86 paging
protections and thus *IRRELEVANT* for this unless you care about the
intricacies of writing enclaves.

It's a big deal to me.

Also, I've tried to give this feedback previously, but the paging
permissions are also essentially irrelevant.

> Also, should there be commas, i.e. ", or requested the enclave by
> itself,"? I suck with English comma rules.

I'd just say this:

	It is also stashed off and then later compared with enclave PTEs
	to ensure that any future mmap()/mprotect() operations are
	consistent with the earlier declared permissions.

Yours was starting to look pretty run on.

> "ioctl(fd, SGX_IOC_ENCLAVE_ADD_PAGES, ...) checks for every page that
> Thread Control Structure (TCS) pages are always added with zero
> permissions and no pages are sourced from noexec partitions. TCS pages
> are pages that work as entry points to the enclave. This is the basic
> acceptance criteria for any enclave page before it gets mapped.

This is going off into the SGX weeds again.

We don't need to justify the ABI for an ioctl() introduced in a
different patch in *THIS* patch.  Just remove this, please.

> After finishing this, the ioctl will project the enclave permissions to
> the corresponding VMA permissions and stores the result for later
> lookup.

That sounds vaguely relevant, although I'm not sure what permission
projection is.  You use that terminology over and over, so you probably
need to define it.

>  For regular pages this is an identity mapping but as an
> exception TCS pages are unconditionally mapped as RW VMA permssion even
> though their enclave permissions are zero. This required by the ISA.

I don't think this is relevant.

> This information will be used by sgx_mmap() and sgx_vma_protect() to
> enforce that higher permissions than the projected permissions will
> not be used by checking this for each every page in the address
> range.

I've given this feedback before.  Please don't use "higher" and "lower"
permissions.  "Stronger/weaker" is my preferred terminology.

You also don't have to *NAME* the functions.  If I want to know where a
structure field is, grep is a better way to find that.

Does this lose any meaning if we just say:

	This information will be to ensure that enclave PTEs will not be
	created with permissions weaker than the source data

?

> By doing this, we give assets for LSM's to make decisions during the
> build time based on projected VMA permissions and the source VMA
> (either a file or anonymous mapping) that hold when the enclave is
> finally mapped to the visible memory."
Dr. Greg Oct. 18, 2020, 8:49 a.m. UTC | #55
On Mon, Sep 28, 2020 at 07:04:38AM -0700, Dave Hansen wrote:

Good morning, I hope the weekend is going well for everyone.

> On 9/27/20 5:53 PM, Jarkko Sakkinen wrote:
> > On Fri, Sep 25, 2020 at 12:53:35PM -0700, Dave Hansen wrote:
> >> On 9/25/20 12:43 PM, Sean Christopherson wrote:
> >>>> That means that the intent argument (SGX_PROT_*) is currently unused.
> >>> No, the intent argument is used (eventually) by SGX's ->mprotect()
> >>> implementation, i.e. sgx_mprotect() enforces that the actual protections are a
> >>> subset of the declared/intended protections.
> >>>
> >>> If ->mprotect() is not merged, then it yes, it will be unused.
> >>
> >> OK, I think I've got it.
> >>
> >> I think I'm OK with adding ->mprotect().  As long as folks buy into the
> >> argument that intent needs to be checked at mmap() time, they obviously
> >> need to be checked at mprotect() too.
> >>
> >> Jarkko, if you want to try and rewrite the changelog, capturing the
> >> discussion here and reply, I think I can ack the resulting patch.  I
> >> don't know if that will satisfy the request from Boris from an ack from
> >> a "mm person", but we can at least start there. :)
> > 
> > I think what it needs, based on what I've read, is the step by step
> > description of the EMODPE scenarion without this callback and with it.
> 
> EMODPE is virtually irrelevant for this whole thing.  The x86 PTE
> permissions still specify the most restrictive permissions, which is
> what matters the most.
> 
> We care about the _worst_ the enclave can do, not what it imposes on
> itself on top of that.
> 
> > I think other important thing to underline is that an LSM or any other
> > security measure can only do a sane decision when the enclave is loaded.
> > At that point we know the source (vm_file).
> 
> Right, you know the source, but it can be anonymous or a file.

Or it could be loaded over the network in encrypted form by the
enclave itself.

Sean, admirably, wants to peer into the future and set the driver up
from an architectural perspective, to future proof it for the
imposition of security controls.  So it would seem helpful to peer a
bit.

If I can paraphrase/simplify the discussion to date; the best the
kernel can do with respect to SGX is to impose controls, via mprotect,
that limit the maximum permissions of an enclave page to whatever was
specified when the enclave was loaded/initialized.

So here is the question that would seem to need answering:

Is this even a relevant control if we cede the notion of dynamically
loadable enclave code, which is the objective of SGX2 hardware, which
will in all likelihood be the only relevant hardware implementation in
the future?

The answer to this could very well be yes if the objective is to
provide a method for a platform owner to explicitly block dynamically
loadable enclave code.  Since there seems to be a desire for immense
clarity in the changelogs surrounding all of this, framing the
discussion in something practical like this may be of assistance.

One of the desires of the SGX user community is to not allow
visibility into enclave code, this is one of the notions/objectives of
confidential computing.  The Protected Code Loader that was added by
Intel to their PSW is an acknowledgement of this fact.  EDMM and
dynamically loadable code makes doing this much more efficient so that
would seem to be the face of the future.

My apologies for 'delaying' the driver even more.  I was accused of
that about a year ago but it appears I didn't do too much
damage... :-)

Best wishes for a productive week.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
                                -- Cowboy Wisdom
Sean Christopherson Oct. 19, 2020, 9:31 p.m. UTC | #56
On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> Is this even a relevant control if we cede the notion of dynamically
> loadable enclave code, which is the objective of SGX2 hardware, which
> will in all likelihood be the only relevant hardware implementation in
> the future?

Yes, it's still relevant.  Giving the thumbs up to dynamically loadable code is
not a purely binary decision, e.g. a user/admin can allow RW->RX transitions
but still disallow full RWX permissions.
Dr. Greg Oct. 20, 2020, 10:01 a.m. UTC | #57
On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote:

Good morning, I hope the day is starting well for everyone.

> On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> > Is this even a relevant control if we cede the notion of dynamically
> > loadable enclave code, which is the objective of SGX2 hardware, which
> > will in all likelihood be the only relevant hardware implementation in
> > the future?

> Yes, it's still relevant.  Giving the thumbs up to dynamically
> loadable code is not a purely binary decision, e.g. a user/admin can
> allow RW->RX transitions but still disallow full RWX permissions.

With respect to the security issue at hand, the only relevant issue
would seem to be if a page had write permissions at one time in its
trajectory to having execute permisions, isn't this correct?

The next paragraph of my reply wasn't included in your reply, but I
did state that the mprotect hook would be relevant if its purpose was
to disallow this permission trajectory and in the process disable
enclave dynamic code loading and execution.

So to assist everyone in understanding this issue and the security
implications involved, is the ultimate purpose of the mprotect hook to
disable dynamic code loading?

Have a good day.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: dg@enjellic.com
------------------------------------------------------------------------------
"Those who will not study history are doomed to debug it."
                                -- Barry Shein
Sean Christopherson Oct. 20, 2020, 4:40 p.m. UTC | #58
On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote:
> On Mon, Oct 19, 2020 at 02:31:05PM -0700, Sean Christopherson wrote:
> 
> Good morning, I hope the day is starting well for everyone.
> 
> > On Sun, Oct 18, 2020 at 03:49:20AM -0500, Dr. Greg wrote:
> > > Is this even a relevant control if we cede the notion of dynamically
> > > loadable enclave code, which is the objective of SGX2 hardware, which
> > > will in all likelihood be the only relevant hardware implementation in
> > > the future?
> 
> > Yes, it's still relevant.  Giving the thumbs up to dynamically
> > loadable code is not a purely binary decision, e.g. a user/admin can
> > allow RW->RX transitions but still disallow full RWX permissions.
> 
> With respect to the security issue at hand, the only relevant issue
> would seem to be if a page had write permissions at one time in its
> trajectory to having execute permisions, isn't this correct?

No.  RW->RX has different properties than RWX.  E.g. an enclave that
dynamically loads code is not the same thing as an enclave that allows
simultaneously writing and executing a page.

> The next paragraph of my reply wasn't included in your reply, but I
> did state that the mprotect hook would be relevant if its purpose was
> to disallow this permission trajectory and in the process disable
> enclave dynamic code loading and execution.
> 
> So to assist everyone in understanding this issue and the security
> implications involved, is the ultimate purpose of the mprotect hook to
> disable dynamic code loading?

No, it's to provide line of sight to enforcing granular LSM checks on enclave
pages.  Jumping back to the RWX thing, as a defense in depth measure, a policy
owner could set an SELinux policy to never allow RWX, even for enclaves that
dynamically load code.

Whether or not having per-page granluarity on enclave permission checks is
valuable/interesting is debatable, e.g. it's why LSM integration is notably
absent from the this series.  But, adding the ->mprotect() hook is relatively
cheap and can always be removed if it's deemed unnecessary in the long run.
The reverse is not true; omitting ->mprotect() commits the kernel to an ABI
that is either ugly and potentially painful (require all enclaves to declare
full RWX permissions), or flat out prevents adding granular LSM support in
the future (do nothing).
Dr. Greg Oct. 24, 2020, 2:37 p.m. UTC | #59
On Tue, Oct 20, 2020 at 09:40:00AM -0700, Sean Christopherson wrote:

Good morning, I hope the week has gone well for everyone.

> On Tue, Oct 20, 2020 at 05:01:18AM -0500, Dr. Greg wrote:
> >
> > With respect to the security issue at hand, the only relevant issue
> > would seem to be if a page had write permissions at one time in its
> > trajectory to having execute permisions, isn't this correct?

> No.  RW->RX has different properties than RWX.  E.g. an enclave that
> dynamically loads code is not the same thing as an enclave that
> allows simultaneously writing and executing a page.

Yes, it is certainly correct that a platform administrator may want to
restrict RWX, given that it makes an enclave susceptible to potential
arbitrary code execution if there is a programming error in the
enclave.

However, I think it is important for everyone interested in these
issues, to reflect back on what started all of this and that was
Andy's concern that the initial incantations of the driver allowed
execution of arbitrary memory without the ability of the LSM to get a
'look' at the code/memory.

My point in all of this is that a permissions trajectory for an
enclave that allows for write permissions on a path that terminates in
X permissions opens the door for arbitrary memory execution that the
platform security architect has no insight into or that the LSM will
have any control over.

There is no guarantee that dynamically loaded code has to come into
the enclave via anything that the operating system has visibility
into.  If the enclave can toggle RW->RX it is free to dynamically load
code, in encrypted form over the network and then execute it.

In fact, I would posit that this model will be a primary use for
dynamic code loading.  The SGX user community views 'confidential
computing' as much about protecting visibility into algorithms and
code as it is about data that is being operated on.  In certain
unnamed venues where I have consulted it is the primary concern.

So in the broadest sense, we have spent a year worrying about if and
how the LSM will have visibility into enclave based code and in the
end the only really relevant security mechanism available is limiting
page permission transitions that prevent dynamic code loading.  Modulo
of course the issue with RWX, where a platform owner may elect to try
and prevent an enclave writer from shooting themselves in the foot.

The issue at hand is that the primary security threat of the
technology is the same as what the user community wants to use it for.
Joanna Rutkowska called that out a half decade ago when she first
reviewed the technology.

> > The next paragraph of my reply wasn't included in your reply, but I
> > did state that the mprotect hook would be relevant if its purpose was
> > to disallow this permission trajectory and in the process disable
> > enclave dynamic code loading and execution.
> > 
> > So to assist everyone in understanding this issue and the security
> > implications involved, is the ultimate purpose of the mprotect hook to
> > disable dynamic code loading?

> No, it's to provide line of sight to enforcing granular LSM checks
> on enclave pages.  Jumping back to the RWX thing, as a defense in
> depth measure, a policy owner could set an SELinux policy to never
> allow RWX, even for enclaves that dynamically load code.
>
> Whether or not having per-page granluarity on enclave permission
> checks is valuable/interesting is debatable, e.g. it's why LSM
> integration is notably absent from the this series.  But, adding the
> ->mprotect() hook is relatively cheap and can always be removed if
> it's deemed unnecessary in the long run.  The reverse is not true;
> omitting ->mprotect() commits the kernel to an ABI that is either
> ugly and potentially painful (require all enclaves to declare full
> RWX permissions), or flat out prevents adding granular LSM support
> in the future (do nothing).

I believe your analysis with respect to the ability to remove
->mprotect is flawed.  The long standing consensus has been that
functionality never gets broken.  Once ->mprotect is a component of
the ABI it would have to be left intact since it could potentially
break things that elected to use it.  On the other hand there is a
long standing history of adding functionality.

I can't bring myself to believe that LSM's are going to be written
that will be making enclave security decisions on a page by page
basis.  Given what I have written above, I think all of this comes
down to giving platform administrators one of three decisions, in
order of most to least secure:

1.) Block dynamic code loading and execution.

2.) Block access to RWX pages.

3.) The wild west - no restrictions on enclave page protection manipulation.

From a security perspective I would argue for the wisdom of making
option 1 unconditional via a kernel command-line parameter.

It may be that ->mprotect is the right mechanism to implement this.
If that is the case, frame the discussion and documentation so that it
reflects the actual security threat and the consideration and means
for dealing with it.

Hopefully all of this is useful to the stakeholders in this
technology.

Have a good weekend.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 19th Ave. N.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Politics is the business of getting power and privilege without possessing
 merit."
                                -- P.J. O'Rourke
Andy Lutomirski Oct. 24, 2020, 3:33 p.m. UTC | #60
> On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@enjellic.com> wrote:
> 

> 
> I can't bring myself to believe that LSM's are going to be written
> that will be making enclave security decisions on a page by page
> basis.  Given what I have written above, I think all of this comes
> down to giving platform administrators one of three decisions, in
> order of most to least secure:
> 
> 1.) Block dynamic code loading and execution.
> 

I don’t understand what you’re trying to say. Unless we’re going to split enclaves into multiple VMAs with different permissions, how do you expect to block dynamic code loading unless you have separate RW and RX pages?  That would be “page-by-page”, right?

> 2.) Block access to RWX pages.
> 
> 3.) The wild west - no restrictions on enclave page protection manipulation.
> 
> From a security perspective I would argue for the wisdom of making
> option 1 unconditional via a kernel command-line parameter.
> 
> It may be that ->mprotect is the right mechanism to implement this.
> If that is the case, frame the discussion and documentation so that it
> reflects the actual security threat and the consideration and means
> for dealing with it.
> 
> Hopefully all of this is useful to the stakeholders in this
> technology.
> 
> Have a good weekend.
> 
> Dr. Greg
> 
> As always,
> Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
> Enjellic Systems Development, LLC     IOT platforms and edge devices.
> 4206 19th Ave. N.
> Fargo, ND  58102
> PH: 701-281-1686                      EMAIL: greg@enjellic.com
> ------------------------------------------------------------------------------
> "Politics is the business of getting power and privilege without possessing
> merit."
>                                -- P.J. O'Rourke
Dr. Greg Oct. 26, 2020, 10:51 a.m. UTC | #61
On Sat, Oct 24, 2020 at 08:33:21AM -0700, Andy Lutomirski wrote:

Good morning, I hope the week is starting well for everyone.

> > On Oct 24, 2020, at 7:38 AM, Dr. Greg <greg@enjellic.com> wrote:
> > I can't bring myself to believe that LSM's are going to be written
> > that will be making enclave security decisions on a page by page
> > basis.  Given what I have written above, I think all of this comes
> > down to giving platform administrators one of three decisions, in
> > order of most to least secure:
> > 
> > 1.) Block dynamic code loading and execution.

> I don't understand what you're trying to say. Unless we're going to
> split enclaves into multiple VMAs with different permissions, how do
> you expect to block dynamic code loading unless you have separate RW
> and RX pages?  That would be ???page-by-page???, right?

I believe that there are multiple knobs that can be manipulated to
achieve the effects that are desired.  I am advocating that we have a
clear and reasoned understanding, with appropriate documentation, as
to what we are doing and why we are doing it.

To advance this understanding, I would advocate that anyone interested
in these issues review the papers that describe the design and use of
the SGX2 architecture instructions.  Fore convenience we have them
available on our FTP server via the following links:

ftp://ftp.enjellic.com/pub/sgx/docs/hasp4.pdf

ftp://ftp.enjellic.com/pub/sgx/docs/hasp5.pdf

They are both from HASP 2016 and are readily available elsewhere as
well.

The first paper discusses the SGX2 architecture instructions and why
they were implemented.  The second paper discusses how Enclave Dynamic
Memory Management (EDMM) can be implemented from the OS perspective
using these instructions.

Full disclosure, I've had the opportunity to have direct exchanges
with a number of the authors on those papers.

The design of all this was heavily influenced by Marcus Peinado's
group at Microsoft.  They did the first implementation of an SGX
library OS (Haven) and in the process addressed the issue of dynamic
memory and code loading.  Their work also resulted in the
documentation of a number of errata in the SGX silicon implementation.

Like the company or not, I don't think the case can be made that they
don't understand operating system design and theory.  It would thus
seem prudent to understand the prior art that went into the design of
all this.

To summarize at a high level, EDMM requires a rather intricate
choreography between enclave code and the device driver, the latter of
which needs to execute ring-0 privileged instructions in order to
expand the virtual address space of an enclave.

The easiest way to generically block dynamic code loading is to not
allow the ENCLS[EAUG] instruction to be executed, the purpose of which
is to augment a defined but sparse ELRANGE with additional physical
pages from the EPC.  It doesn't require ->mprotect or anything else,
just a physical decision by the OS to not allow execution of that
instruction.

All of which is consistent with my recomendation for a global disable
knob on the kernel command-line for sites that do not want to tolerate
completely anonymous code execution.

Since this driver does not yet support EDMM, the most immediate
situation that we are dealing with are the potential security
implications of SGX2 ENCLU instructions being executed inside of an
enclave.  The most principal issue is the ENCLU[EMODPE] instruction
that allows a running enclave to extend the current permissions of a
page.

I've been assuming that Sean's desire for ->mprotect is to block the
ability of an initialized enclave, on a non-EDMM enabled driver, to
collaborate with its untrusted component to self-modify its page
permissions and thus allow execution of code that the operating system
has no visibility into.  That would make far more sense then the
notion of someone trying to create an LSM that makes page by page
security decisions.

The open question in all of this is that the EDMM paper, as well as
the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside
of a running enclave.  I'm assuming that this does NOT mean that once
a context of execution is running in enclave mode it would be capable
of evading standard page protections but the 'immediate' is somewhat
disquieting and probably deserves clarification, despite Dave Hansen's
adament concerns about discussing the instruction... :-)

At the risk of being widely unpopular, it may be worth calling the
question if we shouldn't bite the bullet and implement full SGX2
support in the driver.  Given the trajectory that SGX is on it is what
everyone wants and will be using.  We are currently in somewhat of a
bad place since we have to be cognizant of the implications of SGX2
hardware, which is going to be the only relevant platform for this
driver, without actually addressing all of the issues it brings to the
table.

Hopefully all of the above helps advance an understanding of the
issues at hand.

Have a good day.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker      Autonomously self-defensive
Enjellic Systems Development, LLC     IOT platforms and edge devices.
4206 N. 19th Ave.
Fargo, ND  58102
PH: 701-281-1686                      EMAIL: dg@enjellic.com
------------------------------------------------------------------------------
"Five year projections, are you kidding me.  We don't know what we are
 supposed to be doing at the 4 o'clock meeting this afternoon."
                                -- Terry Wieland
                                   Resurrection
Andy Lutomirski Oct. 26, 2020, 10:59 p.m. UTC | #62
> On Oct 26, 2020, at 3:51 AM, Dr. Greg <greg@enjellic.com> wrote:
> 
> On Sat, Oct 24, 2020 at 08:33:21AM -0700, Andy Lutomirski wrote:
> 
> The easiest way to generically block dynamic code loading is to not
> allow the ENCLS[EAUG] instruction to be executed, the purpose of which
> is to augment a defined but sparse ELRANGE with additional physical
> pages from the EPC.  It doesn't require ->mprotect or anything else,
> just a physical decision by the OS to not allow execution of that
> instruction.

I’m pretty sure that one can dynamically load code without EAUG. It
would require preallocation, but I can’t see why EAUG changes anything from a security policy perspective.

> 
> All of which is consistent with my recomendation for a global disable
> knob on the kernel command-line for sites that do not want to tolerate
> completely anonymous code execution.
> 
> Since this driver does not yet support EDMM, the most immediate
> situation that we are dealing with are the potential security
> implications of SGX2 ENCLU instructions being executed inside of an
> enclave.  The most principal issue is the ENCLU[EMODPE] instruction
> that allows a running enclave to extend the current permissions of a
> page.
> 
> I've been assuming that Sean's desire for ->mprotect is to block the
> ability of an initialized enclave, on a non-EDMM enabled driver, to
> collaborate with its untrusted component to self-modify its page
> permissions and thus allow execution of code that the operating system
> has no visibility into.  That would make far more sense then the
> notion of someone trying to create an LSM that makes page by page
> security decisions.

If you remove every mention of EDMM from that description, and you realize that the ability for LSMs to implement this sort of policy is basically the same as for the core SGX code to do so, then I agree.

The addition of EDMM will not change anything here per se, except that we’re a lot more likely to encounter enclaves doing interesting things with EMODPE once EDMM is enabled.

> 
> The open question in all of this is that the EDMM paper, as well as
> the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside
> of a running enclave.  I'm assuming that this does NOT mean that once
> a context of execution is running in enclave mode it would be capable
> of evading standard page protections but the 'immediate' is somewhat
> disquieting and probably deserves clarification, despite Dave Hansen's
> adament concerns about discussing the instruction... :-)

If EMODPE writes an entry into the TLB that violates PTE permissions, then we have a real problem. I would be very surprised if this were to be the case.
Sean Christopherson Oct. 27, 2020, 12:40 a.m. UTC | #63
On Mon, Oct 26, 2020 at 03:59:35PM -0700, Andy Lutomirski wrote:
> > On Oct 26, 2020, at 3:51 AM, Dr. Greg <greg@enjellic.com> wrote:
> > The open question in all of this is that the EDMM paper, as well as
> > the SDM, indicate the effects of an ENCLU[EMODPE] are immediate inside
> > of a running enclave.  I'm assuming that this does NOT mean that once
> > a context of execution is running in enclave mode it would be capable
> > of evading standard page protections but the 'immediate' is somewhat
> > disquieting and probably deserves clarification, despite Dave Hansen's
> > adament concerns about discussing the instruction... :-)
> 
> If EMODPE writes an entry into the TLB that violates PTE permissions, then we
> have a real problem. I would be very surprised if this were to be the case.

EMODPE only affects the EPCM, it doesn't magically change the PTEs or insert
into the TLB.  The "immediate" wording in the whitepaper is differentiating it
from EMODPR and EMODT, where the modifications only take effect after they have
been verified by the enclave via EACCEPT.
diff mbox series

Patch

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 97c83773b6f0..717726fcace6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -547,6 +547,9 @@  struct vm_operations_struct {
 	void (*close)(struct vm_area_struct * area);
 	int (*split)(struct vm_area_struct * area, unsigned long addr);
 	int (*mremap)(struct vm_area_struct * area);
+	int (*mprotect)(struct vm_area_struct *vma,
+			struct vm_area_struct **pprev, unsigned long start,
+			unsigned long end, unsigned long newflags);
 	vm_fault_t (*fault)(struct vm_fault *vmf);
 	vm_fault_t (*huge_fault)(struct vm_fault *vmf,
 			enum page_entry_size pe_size);
diff --git a/mm/mprotect.c b/mm/mprotect.c
index ce8b8a5eacbb..f170f3da8a4f 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -610,7 +610,10 @@  static int do_mprotect_pkey(unsigned long start, size_t len,
 		tmp = vma->vm_end;
 		if (tmp > end)
 			tmp = end;
-		error = mprotect_fixup(vma, &prev, nstart, tmp, newflags);
+		if (vma->vm_ops && vma->vm_ops->mprotect)
+			error = vma->vm_ops->mprotect(vma, &prev, nstart, tmp, newflags);
+		else
+			error = mprotect_fixup(vma, &prev, nstart, tmp, newflags);
 		if (error)
 			goto out;
 		nstart = tmp;