> Daniel Micay wrote: > > > > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1, > > and it similarly doesn't wipe at all with 'U' (even though junk-on-free > > also serves the purpose of preventing information leaks, not just > > mitigating use-after-free). IMO, optimizing large allocation perf like > > this isn't worthwhile. > > this requires some analysis of what programs do in the wild. some programs > preemptively malloc large buffers, but don't touch them. it would be a serious > reqression for free to fault in new pages, just to ditry them, then turn > around and unmap them. some of this is because i believe the code is doing > things at the wrong time. if you want to dirty whole pages, it should be when > they go on the freelist, not immediately. >
Exactly. Daniel the giant-allocation situation may not be normal in your ecosystem, but it is common in general purpose code. That is why an upper bound was chosen. I would also argue that that gigantic allocations have far fewer security risks, requiring them to be smashed in this way. We defend against those problems by unmapping them, so that the address space becomes unavailable -> SIGSEGV.
