Linux-Sgx Archive on lore.kernel.org
 help / color / Atom feed
* mmap(), #PF handler and EADD interaction
@ 2019-08-19 15:24 Jarkko Sakkinen
  2019-08-19 17:54 ` Sean Christopherson
  0 siblings, 1 reply; 3+ messages in thread
From: Jarkko Sakkinen @ 2019-08-19 15:24 UTC (permalink / raw)
  To: sean.j.christopherson; +Cc: linux-sgx

I did some backtracking today how the permission flow worked.

With the maximum VM flags defined for a page, what if EADD is done after
mmap()?  E.g. we first do mmap() with RWX and later EADD with lets say
RW.

The first thing that comes to mind is that the #PF handler should caught
this corner case.

Now the code correctly validates when you do either mmap() and
mprotect() after EADD(s) but I think "other way around" is missing.

/Jarkko

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mmap(), #PF handler and EADD interaction
  2019-08-19 15:24 mmap(), #PF handler and EADD interaction Jarkko Sakkinen
@ 2019-08-19 17:54 ` Sean Christopherson
  2019-08-21 18:15   ` Jarkko Sakkinen
  0 siblings, 1 reply; 3+ messages in thread
From: Sean Christopherson @ 2019-08-19 17:54 UTC (permalink / raw)
  To: Jarkko Sakkinen; +Cc: linux-sgx

On Mon, Aug 19, 2019 at 06:24:31PM +0300, Jarkko Sakkinen wrote:
> I did some backtracking today how the permission flow worked.
> 
> With the maximum VM flags defined for a page, what if EADD is done after
> mmap()?  E.g. we first do mmap() with RWX and later EADD with lets say
> RW.

sgx_encl_may_map() returns -EACCESS on any attempt to mmap()/mprotect() a
range that is not fully covered by EADD'd pages with any of PROT_READ,
PROT_WRITE or PROT_EXEC.  This is handled in the !page check below.

	if (!page || (~page->vm_prot_bits & vm_prot_bits))
		return -EACCES;

A waiver is given for PROT_NONE, primarily so that mmap() can be used
prior to ECREATE to find an available ELRANGE, but any attempt to access
a PROT_NONE VMA will result in a SIGSEGV, e.g. access_error() explicitly
checks the RWX prot bits.

	/* PROT_NONE always succeeds. */
	if (!vm_prot_bits)
		return 0;


> 
> The first thing that comes to mind is that the #PF handler should caught
> this corner case.
> 
> Now the code correctly validates when you do either mmap() and
> mprotect() after EADD(s) but I think "other way around" is missing.
> 
> /Jarkko

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mmap(), #PF handler and EADD interaction
  2019-08-19 17:54 ` Sean Christopherson
@ 2019-08-21 18:15   ` Jarkko Sakkinen
  0 siblings, 0 replies; 3+ messages in thread
From: Jarkko Sakkinen @ 2019-08-21 18:15 UTC (permalink / raw)
  To: Sean Christopherson; +Cc: linux-sgx

On Mon, Aug 19, 2019 at 10:54:21AM -0700, Sean Christopherson wrote:
> On Mon, Aug 19, 2019 at 06:24:31PM +0300, Jarkko Sakkinen wrote:
> > I did some backtracking today how the permission flow worked.
> > 
> > With the maximum VM flags defined for a page, what if EADD is done after
> > mmap()?  E.g. we first do mmap() with RWX and later EADD with lets say
> > RW.
> 
> sgx_encl_may_map() returns -EACCESS on any attempt to mmap()/mprotect() a
> range that is not fully covered by EADD'd pages with any of PROT_READ,
> PROT_WRITE or PROT_EXEC.  This is handled in the !page check below.

Aah so it was. Can you send me a patch to extend the kdoc with
additional paragraph to remark this?

/Jarkko

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-19 15:24 mmap(), #PF handler and EADD interaction Jarkko Sakkinen
2019-08-19 17:54 ` Sean Christopherson
2019-08-21 18:15   ` Jarkko Sakkinen

Linux-Sgx Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \
		linux-sgx@vger.kernel.org linux-sgx@archiver.kernel.org
	public-inbox-index linux-sgx


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx


AGPL code for this site: git clone https://public-inbox.org/ public-inbox