linux-kernel - Re: [RFC][PATCH v2 1/5] mm: Avoid unmapping pinned pages

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:   Fri, 21 Jan 2022 13:04:09 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...hat.com, tglx@...utronix.de, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-api@...r.kernel.org, x86@...nel.org,
        pjt@...gle.com, posk@...gle.com, avagin@...gle.com,
        jannh@...gle.com, tdelisle@...terloo.ca, mark.rutland@....com,
        posk@...k.io
Subject: Re: [RFC][PATCH v2 1/5] mm: Avoid unmapping pinned pages

On 21.01.22 12:40, Peter Zijlstra wrote:
> On Fri, Jan 21, 2022 at 10:04:45AM +0100, David Hildenbrand wrote:
>> On 21.01.22 09:59, Peter Zijlstra wrote:
> 
>>> However, I'm not quite sure what fork() does with pages that have a pin.
>>
>> We COW the anon pages always, and we protect against concurrent GUP
>> using the
>> * mmap_lock in exclusive mode for ordinary GUP
>> * mm->write_protect_seq for GUP-fast
> 
> Right, but neither the mmap_sem nor the write_protect_seq help anything
> at all vs already extant page pins.
> 
> But I just found copy_present_page()'s page_needs_cow_for_dma(), which I
> think deals with exactly that case, it avoids doing CoW on pinned pages
> and instead feeds the child a full copy while keeping the pinned page in
> the original process.

Yes, page_needs_cow_for_dma() is the magic bit. The locking I explained
keep its output "reliable".

> 
>>> Naively, a page that has async DMA activity should not be CoW'ed, or if
>>> it is, care must be taken to ensure the original pages stays in the
>>> original process, but I realize that's somewhat hard.
>>
>> That's precisely what I'm working on fixing ... and yes, it's hard.
>>
>> Let me know if you need any other information, I've spent way too much
>> time on this than I ever panned.
> 
> So let me try and get this right:
> 
>  - GUP post-fork breaks CoW for FOLL_WRITE/FOLL_PIN, without either
>    there's a problem where one task might observe changes by another.
> 
>  - GUP pre-fork prevents CoW and does a full copy.

Yes, pretty much.

> 
> And that all mostly works, except for a fair amount of 'fun' cases?

I'd say some obviously broken cases, some racy cases, some fun cases :)


We have three main cases. And usually, trying to tackle one triggers
another.

(1) Missed CoW

If the child R/O pins and unmaps the page, the parent might miss to CoW
and reuse the page. Security issue. Once CVE in that area is currently
still applicable for THP (well, and hugetlb).

(2) Unnecessary CoW

We CoW instead of reusing the page, but there are no relevant pins, so
it's unnecessary.

(3) Wrong CoW

We CoW a page that has relevant pins, losing synchronicity between GUP
and the page tables.


The "criticality" is (1), (3), (2).

(3) can currently get triggered by anything that can map a pinned page
R/O. The racy case is what I described about the swapcache. Other broken
cases are mprotect() and friends (we cannot differentiate between R/O
and R/W pins ...).


-- 
Thanks,

David / dhildenb