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 20:53:01 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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 09.08.22 20:48, Jason Gunthorpe wrote:
> 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.

Thanks Jason for the explanation.

I have patches in the works to no longer use FOLL_FORCE|FOLL_WRITE for
taking a reliable longerterm R/O pin in a MAP_PRIVATE mapping. The
patches are mostly done (and comparably simple), I merely deferred
sending them out because I stumbled over this issue first.

Some ugly corner cases of MAP_SHARED remain, but for most prominent use
cases, my upcoming patches should allow us to just have longterm R/O
pins working as expected.

-- 
Thanks,

David / dhildenb