[compiler-rt] [scudo] Add primary option to zero block on dealloc. (PR #142394)
via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 19 03:37:51 PDT 2025
piwicode wrote:
Thanks for taking the time to reply.
> Zeroing-on-free is also a security feature ans that's why I think it is good to have. But it seems to me this is introduced for specific platform, then we may want to consider if we can implement it on platform side.
I made some conclusive measurements on Fuchsia. I don't have measures on Android but I this is will be positive too, given that linux zram store efficiently pages with a unique value.
> For example, the malloc/free hooks.
I see a few challenges because `__scudo_deallocate_hook`:
- runs outside of the allocator lock, hence a given block could be in use when the hook is called.
- does not know about the allocation header which also needs to be cleared.
- runs indistinctly on primary and secondary allocator, wheras this change is a primary allocator optimization.
- `__scudo_deallocate_hook` does not know the object size (easily fixed)
> In addition, the size of blocks in the primary allocator can be large (like several pages), it depends on the configuration. So even if you only zeroing blocks in primary allocator, it can still cause some performance issue.
Indeed. That should be in the same ballpark as zeroing on allocation. I thought about relaying on a platform specific function later on that would use kernel operation to zero the memory. That feature could be implemented in memset or scudo.
I profiled scudo allocation and deallocation on my system and the effect is small. I observe not effect on macro bencharks.
On the positive side, this decommits 30 MiB of memory on our system which is significant, I observe a reduction of the number of pages moved to zram, and a decrease in the time spent by the kernel on compression and decompression.
> We do have a way to implement this only for certain sizes but I would suggest having more discussion before we make it a formal feature in Scudo
Sure, how can I get the discussion rolling?
https://github.com/llvm/llvm-project/pull/142394
More information about the llvm-commits
mailing list