linux-kernel - Re: [PATCH 0/2] page_count can't be used to decide when wp_page

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>] [day] [month] [year] [list]

Date:   Mon, 11 Jan 2021 10:39:05 -0400
From:   Jason Gunthorpe <jgg@...pe.ca>
To:     Hillf Danton <hdanton@...a.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Yu Zhao <yuzhao@...gle.com>, Andy Lutomirski <luto@...nel.org>,
        Peter Xu <peterx@...hat.com>, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy

On Sat, Jan 09, 2021 at 11:49:58AM +0800, Hillf Danton wrote:
> On Fri, 8 Jan 2021 14:19:45 -0400 Jason Gunthorpe wrote:
> > 
> > What I was trying to explain below, is I think we agreed that a page
> > under active FOLL_LONGTERM pin *can not* be write protected.
> > 
> > Establishing the FOLL_LONGTERM pin (for read or write) must *always*
> > break the write protection and the VM *cannot* later establish a new
> > write protection on that page while the pin is active.
> > 
> > Indeed, it is complete nonsense to try and write protect a page that
> > has active DMA write activity! Changing the CPU page protection bits
> > will not stop any DMA! Doing so will inevitably become a security
> > problem with an attack similar to what you described.
> > 
> > So this is what was done during fork() - fork will no longer write
> > protect pages under FOLL_LONGTERM to make them COWable, instead it
> > will copy them at fork time.
> 
> Is it, in a step forward, unlikely for DMA write activity to happen
> during page copy at fork?

I'm not sure it matters, it is not that much different than CPU write
activity concurrent to fork(). fork() will capture some point in time
- if the application cares that this data is coherent during fork()
then it has to deliberately cause coherence somehow.

DMA just has fewer options for the application to create the coherency
because of data tearing during the page copy.

Jason