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?
