On Mon, 28 Dec 2020 18:09:28 -0800 Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > On Wed, Dec 23, 2020 at 2:34 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, 11 Dec 2020 21:31:52 -0800 Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > > > > > In the Scudo memory allocator [1] we would like to be able to > > > detect use-after-free vulnerabilities involving large allocations > > > by issuing mprotect(PROT_NONE) on the memory region used for the > > > allocation when it is deallocated. Later on, after the memory > > > region has been "quarantined" for a sufficient period of time we > > > would like to be able to use it for another allocation by issuing > > > mprotect(PROT_READ|PROT_WRITE). > > > > > > Before this patch, after removing the write protection, any writes > > > to the memory region would result in page faults and entering > > > the copy-on-write code path, even in the usual case where the > > > pages are only referenced by a single PTE, harming performance > > > unnecessarily. Make it so that any pages in anonymous mappings that > > > are only referenced by a single PTE are immediately made writable > > > during the mprotect so that we can avoid the page faults. > > > > > > > I worry that some other application out there does a similar thing, but > > only expects to very sparsely write to the area. It will see a big increase > > in mprotect() latency. > > > > Would it be better to implement this as a separate operation, rather > > than unconditionally tying it into mprotect()? Say, a new madvise() > > operation? > > So the case that you're concerned about would be highlighted by this > program, correct? > > ... > > So it seems that even with a single page fault the new approach is faster. > Cool, thanks. Can you please roll this new info into the changelog and resend?
