linux-kernel - Re: [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL

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]

Date:   Tue, 9 Aug 2022 15:48:37 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, stable@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Peter Xu <peterx@...hat.com>, Hugh Dickins <hughd@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        John Hubbard <jhubbard@...dia.com>
Subject: Re: [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove
 FOLL_COW

On Tue, Aug 09, 2022 at 11:40:50AM -0700, Linus Torvalds wrote:
> On Mon, Aug 8, 2022 at 12:32 AM David Hildenbrand <david@...hat.com> wrote:
> >
> > For example, a write() via /proc/self/mem to a uffd-wp-protected range has
> > to fail instead of silently granting write access and bypassing the
> > userspace fault handler. Note that FOLL_FORCE is not only used for debug
> > access, but also triggered by applications without debug intentions, for
> > example, when pinning pages via RDMA.
> 
> So this made me go "Whaa?"
> 
> I didn't even realize that the media drivers and rdma used FOLL_FORCE.
> 
> That's just completely bogus.
> 
> Why do they do that?
> 
> It seems to be completely bogus, and seems to have no actual valid
> reason for it. Looking through the history, it goes back to the
> original code submission in 2006, and doesn't have a mention of why.

It is because of all this madness with COW.

Lets say an app does:

 buf = mmap(MAP_PRIVATE)
 rdma_pin_for_read(buf)
 buf[0] = 1 

Then the store to buf[0] will COW the page and the pin will become
decoherent.

The purpose of the FORCE is to force COW to happen early so this is
avoided.

Sadly there are real apps that end up working this way, eg because
they are using buffer in .data or something.

I've hoped David's new work on this provided some kind of path to a
proper solution, as the need is very similar to all the other places
where we need to ensure there is no possiblity of future COW.

So, these usage can be interpreted as a FOLL flag we don't have - some
kind of (FOLL_EXCLUSIVE | FOLL_READ) to match the PG_anon_exclusive
sort of idea.

Jason