[–] caf link

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.

reply

[–] MaxBarraclough link

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.

reply

[–] jchw link

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?

reply

[–] DominikD link

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.

reply

[–] MrBuddyCasino link

Speed? CRC32 has dedicated CPU instructions on recent x64.

reply

[–] Arnt link

And size. The whole header ought to fit in 64 bits (a single cmpxchg), which rules out all of the good secure hashes.

reply

[–] caf link

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.

reply

[–] osivertsson link

How does scudo compare with libdislocator?

reply