linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
Cc: David Hildenbrand <david@redhat.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: get_user_pages() and EXEC_ONLY mapping.
Date: Fri, 10 Nov 2023 11:06:20 -0400	[thread overview]
Message-ID: <20231110150620.GQ4488@nvidia.com> (raw)
In-Reply-To: <9a51f827-6bf4-412b-9feb-37cc41ad3e90@linux.ibm.com>

On Fri, Nov 10, 2023 at 08:27:19PM +0530, Aneesh Kumar K V wrote:
> On 11/10/23 8:23 PM, Jason Gunthorpe wrote:
> > On Fri, Nov 10, 2023 at 08:19:23PM +0530, Aneesh Kumar K.V wrote:
> >>
> >> Hello,
> >>
> >> Some architectures can now support EXEC_ONLY mappings and I am wondering
> >> what get_user_pages() on those addresses should return. 
> > 
> > -EPERM
> > 
> >> Earlier PROT_EXEC implied PROT_READ and pte_access_permitted()
> >> returned true for that. But arm64 does have this explicit comment
> >> that says
> >>
> >>  /*
> >>  * p??_access_permitted() is true for valid user mappings (PTE_USER
> >>  * bit set, subject to the write permission check). For execute-only
> >>  * mappings, like PROT_EXEC with EPAN (both PTE_USER and PTE_UXN bits
> >>  * not set) must return false. PROT_NONE mappings do not have the
> >>  * PTE_VALID bit set.
> >>  */
> >>
> >> Is that correct? We should be able to get struct page for PROT_EXEC
> >> mappings?
> > 
> > If the memory is unreadable then providing a back door through
> > O_DIRECT and everthing else to read it sounds wrong to me.
> > 
> > If there is some case where a get_user_pages caller is exec-only
> > compatible then a new FOLL_EXEC flag to permit it would make sense.
> > 
> 
> I was expecting pin_user_pages() to return -EPERM and get_user_pages()
> return struct page. This was based on Documentation/core-api/pin_user_pages.rst  

Not unconditionally but you could argue that FOLL_GET should
succeed. It depends how much do you care about absolute security of
unreadable memory vs compatability.

> "Another way of thinking about these flags is as a progression of restrictions:
> FOLL_GET is for struct page manipulation, without affecting the data that the
> struct page refers to. FOLL_PIN is a *replacement* for FOLL_GET, and is for
> short term pins on pages whose data *will* get accessed. "

This was sort of aspirational - have we got rid of all the FOLL_GET
users that are touching the data? Looks like no from a quick check..

Jason

  reply	other threads:[~2023-11-10 15:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-10 14:49 get_user_pages() and EXEC_ONLY mapping Aneesh Kumar K.V
2023-11-10 14:53 ` Jason Gunthorpe
2023-11-10 14:57   ` Aneesh Kumar K V
2023-11-10 15:06     ` Jason Gunthorpe [this message]
2023-11-10 17:17 ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231110150620.GQ4488@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).