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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 7 Jan 2021 13:29:43 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Andrea Arcangeli <aarcange@...hat.com> Cc: Linux-MM <linux-mm@...ck.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Yu Zhao <yuzhao@...gle.com>, Andy Lutomirski <luto@...nel.org>, Peter Xu <peterx@...hat.com>, Pavel Emelyanov <xemul@...nvz.org>, Mike Kravetz <mike.kravetz@...cle.com>, Mike Rapoport <rppt@...ux.vnet.ibm.com>, Minchan Kim <minchan@...nel.org>, Will Deacon <will@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Hugh Dickins <hughd@...gle.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Matthew Wilcox <willy@...radead.org>, Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>, Kees Cook <keescook@...omium.org>, John Hubbard <jhubbard@...dia.com>, Leon Romanovsky <leonro@...dia.com>, Jason Gunthorpe <jgg@...pe.ca>, Jan Kara <jack@...e.cz>, Kirill Tkhai <ktkhai@...tuozzo.com> Subject: Re: [PATCH 2/2] mm: soft_dirty: userfaultfd: introduce wrprotect_tlb_flush_pending On Thu, Jan 7, 2021 at 12:59 PM Andrea Arcangeli <aarcange@...hat.com> wrote: > > The problem is it's not even possible to detect reliably if there's > really a long term GUP pin because of speculative pagecache lookups. So none of the normal code _needs_ that any more these days, which is what I think is so nice. Any pinning will do the COW, and then we have the logic to make sure it stays writable, and that keeps everything nicely coherent and is all fairly simple. And yes, it does mean that if somebody then explicitly write-protects a page, it may end up being COW'ed after all, but if you first pinned it, and then started playing with the protections of that page, why should you be surprised? So to me, this sounds like a "don't do that then" situation. Anybody who does page pinning and wants coherency should NOT TOUCH THE MAPPING IT PINNED. (And if you do touch it, it's your own fault, and you get to keep both of the broken pieces) Now, I do agree that from a QoI standpoint, it would be really lovely if we actually enforced it. I'm not entirely sure we can, but maybe it would be reasonable to use that mm->has_pinned && page_maybe_dma_pinned(page) at least as the beginning of a heuristic. In fact, I do think that "page_maybe_dma_pinned()" could possibly be made stronger than it is. Because at *THAT* point, we might say "we know a pinned page always must have a page_mapcount() of 1" - since as part of pinning it and doing the GUP_PIN, we forced the COW, and then subsequent fork() operations enforce it too. So I do think that it might be possible to make that clear_refs code notice "this page is pinned, I can't mark it WP without the pinning coherency breaking". It might not even be hard. But admittedly I'm somewhat handwaving here, and I might not have thought of some situation. Linus
Powered by blists - more mailing lists