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:

quoted

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