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? > > Any other place doing write protect must also follow these same > rules. > > I wasn't aware this could be used to create a security problem, but it > does make sense. write protect really must mean writes to the memory > must stop and that is fundementally incompatible with active DMA. > > Thus write protect of pages under DMA must be forbidden, as a matter > of security. > > Jason
