News for hackers. Stuff that matters.

A comment on System memory allocator free operation zeroes out deallocated blocks in iOS 16. Parent comment

Re:System memory allocator free operation zeroes out dealloc... by cesarb on Thursday September 22, 2022 @12:28PM (#32941205)
> As long as Apple's allocator continues to zero freed memory, programs accidentally depending on that behavior will only be a problem for other operating systems.

As I mentioned, only until that freed block is reused for a new allocation, which means it will no longer be all-zeros; or until the memory allocator decides it's time to unmap that region, which means it will trap (SIGSEGV or similar).

[ Parent | on HN ]
Re:System memory allocator free operation zeroes out dealloc... by ncmncm on Thursday September 22, 2022 @03:53PM (#32943835)
Memory allocators generally don't unmap anything, because the performance hit on any other threads running is severe.

When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts. Then they get misses until their cache is restored.

In what might be a multi-thread program, you don't fool with the memory map without very good reasons. Mapping new pages, or marking a page r/o or r/w is OK; anything else, probably not.

[ Parent | on HN ]
Re:System memory allocator free operation zeroes out dealloc... by zerohp on Thursday September 22, 2022 @06:09PM (#32945267)
> When memory is unmapped, caches of memory mappings of other threads are discarded, via inter-core interrupts.

ARM architecture does not need to interrupt for TLB shootdown.

[ Parent | on HN ]
Re:System memory allocator free operation zeroes out dealloc... by kergonath on Thursday September 22, 2022 @12:53PM (#32941521)
> which means it will trap

Is it really a problem? Failing harder and earlier is a good thing if it means the bug has more chances of being detected and fixed.

[ Parent | on HN ]