linux-kernel - Re: One (possible) x86 get_user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1296211891.15234.269.camel@laptop>
Date:	Fri, 28 Jan 2011 11:51:31 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Jan Beulich <JBeulich@...ell.com>
Cc:	Xiaowei Yang <xiaowei.yang@...wei.com>, fanhenglong@...wei.com,
	Kaushik Barde <kbarde@...wei.com>,
	Kenneth Lee <liguozhu@...wei.com>,
	linqaingmin <linqiangmin@...wei.com>, wangzhenguo@...wei.com,
	Wu Fengguang <fengguang.wu@...el.com>,
	Nick Piggin <npiggin@...nel.dk>, linux-kernel@...r.kernel.org
Subject: Re: One (possible) x86 get_user_pages bug

On Thu, 2011-01-27 at 14:30 +0000, Jan Beulich wrote:
> >>> On 27.01.11 at 14:56, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > On Thu, 2011-01-27 at 21:05 +0800, Xiaowei Yang wrote:
> >> 
> >> However, from the comments embedded in gup.c, it seems deliberate to 
> >> avoid the lock in the fast path. The question is: if so, how to avoid 
> >> the above scenario? 
> > 
> > Something like the below comes to mind... but I must say I haven't fully
> > considered the problem yet..
> 
> That doesn't seem to account for the possible case of the page
> even managing to get allocated again to something else.
> 
> And I think you would need to drop out of gup_pte_range() in
> that case.
> 
> I would think this needs to be get_page_unless_zero()
> followed by re-checking of the page table entry (probably
> not even requiring a second gup_get_pte()); I'm not sure
> yet what the correct action would be for change in only the
> accessed/dirty bits.

Nah, if its racy against unmap its racy and the caller needs to be able
to deal with whatever page comes it way. You either get the old, the
new, or no page.

The get_page_unless_zero() + RCU-freed page-tables should make Xen work
again, look at the powerpc gup_fast implementation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/