On Sun, 2015-12-06 at 17:10 -0700, Theo de Raadt wrote: > Kept out of circulation? It sounds like it would be incredibly > expensive data-structure wise for the kernel to even attempt such a > gaurantee..
I was just expecting it to be a FIFO ring buffer. It would have a limit on the number of mappings it can delay along with a maximum upper bound on the total mapping size (and it would flush the oldest mappings out to stay under that threshold). It would increase virtual memory fragmentation so it could be expensive. I was thinking about it from a userspace perspective which is why I had mentioned purging the delayed mappings with MADV_FREE. It wouldn't make sense to do it in userspace though. Simply unmapping right away and approaching it in the kernel is better. > So what is the purpose of your proposal? Is it to opportunistically > find bugs? Or to resist attack in UAF situations by "gauranteeing" > the memory is unallocated at time of reuse? Guaranteeing that the memory is not reused until a given amount of allocator throughput happens. And reliable immediate detection of the access since it will be guaranteed to fault. > Maybe you are on a system with where mmap ASLR isn't as good? The > OpenBSD one isn't perfect, because we are trying to maintain a small > amount of page-table locality (so that N-level page tables don't have > to be walked fully from root for every access that misses in the > TLB). Yeah, the Linux kernel's mmap ASLR only randomizes the base. So I'm not getting the same security properties as OpenBSD malloc has on OpenBSD. I could implement fine-grained randomization in the kernel for 64-bit (Android has no virtual memory to spare on 32-bit) but I thought a delay might be useful even with that in place as it fully prevents reuse for a given period of "time" (allocator throughput). It depends on how aggressive the mmap randomization is and perhaps on the level of control that an attacker can exert over memory allocation.
