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
| ||
|
Message-ID: <4c032450-7184-fdb9-7b50-670ff06fc225@redhat.com> Date: Tue, 2 May 2023 21:07:34 +0200 From: David Hildenbrand <david@...hat.com> To: Lorenzo Stoakes <lstoakes@...il.com> Cc: Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, Jason Gunthorpe <jgg@...pe.ca>, Jens Axboe <axboe@...nel.dk>, Matthew Wilcox <willy@...radead.org>, Dennis Dalessandro <dennis.dalessandro@...nelisnetworks.com>, Leon Romanovsky <leon@...nel.org>, Christian Benvenuti <benve@...co.com>, Nelson Escobar <neescoba@...co.com>, Bernard Metzler <bmt@...ich.ibm.com>, Ingo Molnar <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, Mark Rutland <mark.rutland@....com>, Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>, Bjorn Topel <bjorn@...nel.org>, Magnus Karlsson <magnus.karlsson@...el.com>, Maciej Fijalkowski <maciej.fijalkowski@...el.com>, Jonathan Lemon <jonathan.lemon@...il.com>, "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Christian Brauner <brauner@...nel.org>, Richard Cochran <richardcochran@...il.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>, linux-fsdevel@...r.kernel.org, linux-perf-users@...r.kernel.org, netdev@...r.kernel.org, bpf@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>, Jason Gunthorpe <jgg@...dia.com>, John Hubbard <jhubbard@...dia.com>, Jan Kara <jack@...e.cz>, "Kirill A . Shutemov" <kirill@...temov.name>, Pavel Begunkov <asml.silence@...il.com>, Mika Penttila <mpenttil@...hat.com>, Dave Chinner <david@...morbit.com>, Theodore Ts'o <tytso@....edu>, Peter Xu <peterx@...hat.com>, Matthew Rosato <mjrosato@...ux.ibm.com>, "Paul E . McKenney" <paulmck@...nel.org>, Christian Borntraeger <borntraeger@...ux.ibm.com>, Mike Rapoport <rppt@...ux.ibm.com> Subject: Re: [PATCH v7 3/3] mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-backed mappings On 02.05.23 20:17, Lorenzo Stoakes wrote: > On Tue, May 02, 2023 at 07:34:06PM +0200, David Hildenbrand wrote: >> On 02.05.23 19:22, Peter Zijlstra wrote: >>> On Tue, May 02, 2023 at 07:13:49PM +0200, David Hildenbrand wrote: >>>> [...] >>>> >>>>> +{ >>>>> + struct address_space *mapping; >>>>> + >>>>> + /* >>>>> + * GUP-fast disables IRQs - this prevents IPIs from causing page tables >>>>> + * to disappear from under us, as well as preventing RCU grace periods >>>>> + * from making progress (i.e. implying rcu_read_lock()). >>>>> + * >>>>> + * This means we can rely on the folio remaining stable for all >>>>> + * architectures, both those that set CONFIG_MMU_GATHER_RCU_TABLE_FREE >>>>> + * and those that do not. >>>>> + * >>>>> + * We get the added benefit that given inodes, and thus address_space, >>>>> + * objects are RCU freed, we can rely on the mapping remaining stable >>>>> + * here with no risk of a truncation or similar race. >>>>> + */ >>>>> + lockdep_assert_irqs_disabled(); >>>>> + >>>>> + /* >>>>> + * If no mapping can be found, this implies an anonymous or otherwise >>>>> + * non-file backed folio so in this instance we permit the pin. >>>>> + * >>>>> + * shmem and hugetlb mappings do not require dirty-tracking so we >>>>> + * explicitly whitelist these. >>>>> + * >>>>> + * Other non dirty-tracked folios will be picked up on the slow path. >>>>> + */ >>>>> + mapping = folio_mapping(folio); >>>>> + return !mapping || shmem_mapping(mapping) || folio_test_hugetlb(folio); >>>> >>>> "Folios in the swap cache return the swap mapping" -- you might disallow >>>> pinning anonymous pages that are in the swap cache. >>>> >>>> I recall that there are corner cases where we can end up with an anon page >>>> that's mapped writable but still in the swap cache ... so you'd fallback to >>>> the GUP slow path (acceptable for these corner cases, I guess), however >>>> especially the comment is a bit misleading then. >>>> >>>> So I'd suggest not dropping the folio_test_anon() check, or open-coding it >>>> ... which will make this piece of code most certainly easier to get when >>>> staring at folio_mapping(). Or to spell it out in the comment (usually I >>>> prefer code over comments). >>> >>> So how stable is folio->mapping at this point? Can two subsequent reads >>> get different values? (eg. an actual mapping and NULL) >>> >>> If so, folio_mapping() itself seems to be missing a READ_ONCE() to avoid >>> the compiler from emitting the load multiple times. >> >> I can only talk about anon pages in this specific call order here (check >> first, then test if the PTE changed in the meantime): we don't care if we >> get two different values. If we get a different value the second time, >> surely we (temporarily) pinned an anon page that is no longer mapped (freed >> in the meantime). But in that case (even if we read garbage folio->mapping >> and made the wrong call here), we'll detect afterwards that the PTE changed, >> and unpin what we (temporarily) pinned. As folio_test_anon() only checks two >> bits in folio->mapping it's fine, because we won't dereference garbage >> folio->mapping. >> >> With folio_mapping() on !anon and READ_ONCE() ... good question. Kirill said >> it would be fairly stable, but I suspect that it could change (especially if >> we call it before validating if the PTE changed as I described further >> below). >> >> Now, if we read folio->mapping after checking if the page we pinned is still >> mapped (PTE unchanged), at least the page we pinned cannot be reused in the >> meantime. I suspect that we can still read "NULL" on the second read. But >> whatever we dereference from the first read should still be valid, even if >> the second read would have returned NULL ("rcu freeing"). >> > > On a specific point - if mapping turns out to be NULL after we confirm > stable PTE, I'd be inclined to reject and let the slow path take care of > it, would you agree that that's the correct approach? If it's not an anon page and the mapping is NULL, I'd say simply fallback to the slow path. -- Thanks, David / dhildenb
Powered by blists - more mailing lists