get_user_pages pinning: 2^22 page refs max?

get_user_pages pinning: 2^22 page refs max?

[Jann Horn]

Regarding the LSFMM talk today:
So with the page ref bias, the maximum number of page references will
be something like 2^22, right? Is the bias only applied to writable
references or also readonly ones?

Re: get_user_pages pinning: 2^22 page refs max?

[Matthew Wilcox]

On Wed, May 01, 2019 at 06:19:00PM -0400, Jann Horn wrote:
> Regarding the LSFMM talk today:
> So with the page ref bias, the maximum number of page references will
> be something like 2^22, right? Is the bias only applied to writable
> references or also readonly ones?

2^21, because it's going to get caught by the < 0 check.

I think that's fine, though.  Anyone trying to map that page so many times
is clearly doing something either malicious or inadvertently very wrong.
After the 2 millionth time, attempting to pin the page will fail, and
the application will have to deal with that failure.

Re: get_user_pages pinning: 2^22 page refs max?

[Jan Kara]

On Wed 01-05-19 18:44:22, Matthew Wilcox wrote:
> On Wed, May 01, 2019 at 06:19:00PM -0400, Jann Horn wrote:
> > Regarding the LSFMM talk today:
> > So with the page ref bias, the maximum number of page references will
> > be something like 2^22, right? Is the bias only applied to writable
> > references or also readonly ones?
> 
> 2^21, because it's going to get caught by the < 0 check.
> 
> I think that's fine, though.  Anyone trying to map that page so many times
> is clearly doing something either malicious or inadvertently very wrong.
> After the 2 millionth time, attempting to pin the page will fail, and
> the application will have to deal with that failure.

So actually, you can still have ~2^31 *normal* page references (e.g. from
page tables). You would be limited to ~2^21 GUP references but I don't
think that would be a problem for any real workload.

If we are concerned about malicous application causing DOS by pinning page
too many times and then normal reference could not be acquired without
causing issues like leaking the page, I think we could even let get_pin()
fail whenever say page->_refcount >= 1<<29 to still leave *plenty* of space
for normal page references (effectively user could consume only 1/4 of
refcount range for GUP pins).

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: get_user_pages pinning: 2^22 page refs max?

[Matthew Wilcox]

On Thu, May 02, 2019 at 05:24:39PM +0200, Jan Kara wrote:
> On Wed 01-05-19 18:44:22, Matthew Wilcox wrote:
> > On Wed, May 01, 2019 at 06:19:00PM -0400, Jann Horn wrote:
> > > Regarding the LSFMM talk today:
> > > So with the page ref bias, the maximum number of page references will
> > > be something like 2^22, right? Is the bias only applied to writable
> > > references or also readonly ones?
> > 
> > 2^21, because it's going to get caught by the < 0 check.
> > 
> > I think that's fine, though.  Anyone trying to map that page so many times
> > is clearly doing something either malicious or inadvertently very wrong.
> > After the 2 millionth time, attempting to pin the page will fail, and
> > the application will have to deal with that failure.
> 
> So actually, you can still have ~2^31 *normal* page references (e.g. from
> page tables). You would be limited to ~2^21 GUP references but I don't
> think that would be a problem for any real workload.
> 
> If we are concerned about malicous application causing DOS by pinning page
> too many times and then normal reference could not be acquired without
> causing issues like leaking the page, I think we could even let get_pin()
> fail whenever say page->_refcount >= 1<<29 to still leave *plenty* of space
> for normal page references (effectively user could consume only 1/4 of
> refcount range for GUP pins).

Oh, I haven't explained the page refcount solution properly :-(

After the page refcount gets to 2^31, no more get_user_pages() calls
will succeed.  But normal get_page() calls will succeed, so you can
still fork() or do normal IO, just not O_DIRECT or RDMA.

I wanted to find a solution that didn't permit a local DoS by, eg,
doing O_DIRECT writes from a page of libc.  I mean, you can stop other
I/O from occurring, but you can't prevent fork().