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
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 10 Jan 2021 21:18:37 -0400
From:   Jason Gunthorpe <>
To:     Linus Torvalds <>
Cc:     Andrea Arcangeli <>,
        Andrew Morton <>,
        Linux-MM <>,
        Linux Kernel Mailing List <>,
        Yu Zhao <>, Andy Lutomirski <>,
        Peter Xu <>,
        Pavel Emelyanov <>,
        Mike Kravetz <>,
        Mike Rapoport <>,
        Minchan Kim <>,
        Will Deacon <>,
        Peter Zijlstra <>,
        Hugh Dickins <>,
        "Kirill A. Shutemov" <>,
        Matthew Wilcox <>,
        Oleg Nesterov <>, Jann Horn <>,
        Kees Cook <>,
        John Hubbard <>,
        Leon Romanovsky <>, Jan Kara <>,
        Kirill Tkhai <>,
        Nadav Amit <>, Jens Axboe <>
Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse

On Sun, Jan 10, 2021 at 11:30:57AM -0800, Linus Torvalds wrote:

> Notice how this is all both conceptually fairly simple (ie I can
> explain the rules in plain English without really making any complex
> argument) and it is arguably internally fairly self-consistent (ie the
> whole notion of "oh, there's another thing that has write access that
> page but doesn't go through the page table, so trying to make it
> read-only in the page tables is a nonsensical operation").

Yes exactly!
> Are the end results wrt something like soft-dirty a bit odd? Not
> really. If you do soft-dirty, such a GUP-shared page would simply
> always show up as dirty. That's still consistent with the rules. If
> somebody else may be writing to it because of GUP, that page really
> *isn't* clean, and us marking it read-only would be just lying about
> things.
> I'm admittedly not very happy about mprotect() itself, though. It's
> actually ok to do the mprotect(PROT_READ) and turn the page read-only:
> that will also disable COW itself (because a page fault will now be a
> SIGSEGV, not a COW).

I would say even mprotect should not set write protect on page under
DMA, it seems like the sort of thing that will trip up other parts of
the mm that might sensibly assume read-only actually means read only,
not 'probably read-only but there might be DMA writes anyhow'

So copy the page before write protecting it? Then the explicit
mprotect is one of the system calls that can cause de-coherence of the
DMA - like munmap.

If we had reliable pinned detection I'd say to fail the mprotect..

And I think you are right about clear refs too. Clear refs must be
aware of FOLL_LONGTERM and handle it properly - which includes not
write protecting such a page.


Powered by blists - more mailing lists