jchw 11 days ago [-]
It has an option to zero out allocations/deallocations. I wonder if it would be useful to randomize the memory instead. It seems like this would help surface bugs better than either zeroing it or leaving it alone?
caf 11 days ago [-]
Rather than random data, it is more typical to poison with a repeating pattern (like 0xAAAAAAAA). This is usually easy to spot in a backtrace, even with minor mutations.
MaxBarraclough 11 days ago [-]
The point of the allocator is security, not debugging.

Perhaps it would help even from a security perspective, though. It would make it harder to scan the heap for deallocated memory regions, for what that's worth.

caf 12 days ago [-]
The choice of CRC32 together with a secret seems odd, it seems to be relying on a security property which CRC32 doesn't have.

This looks like the kind of application that SipHash is designed for.

DominikD 11 days ago [-]
As long as results are different on every application run and app crashes when there's a mismatch, you don't need anything as strong as SipHash since your previous guesses don't narrow options for your future attack attempts.
MrBuddyCasino 11 days ago [-]
Speed? CRC32 has dedicated CPU instructions on recent x64.
Arnt 11 days ago [-]
And size. The whole header ought to fit in 64 bits (a single cmpxchg), which rules out all of the good secure hashes.
osivertsson 11 days ago [-]
How does scudo compare with libdislocator?