At malloc time, assign an unpredictable, non-reusable 64-bit ID to the allocation and return it as part of the pointer value.
-
-
-
Non-malloc pointers have arbitrary (e.g. all zero bits). Now free can trap if the id in the fat pointer doesn't match the pointed-to block.
-
cool idea. would it be possible (or worthwhile) to cram a 16-bit ID into the unused high-order bits on x86-64?
-
I don't think so. It's insufficient to protect against intentional attacks and mandates an ABI change anyway.
End of conversation
New conversation -
-
-
Also solves ABA problems, but you need wider atomic ops. We just end up doing it in-app :weep:
-
Solaris does something with the header to detect invalid frees at least.
-
Can reliably detect all invalid frees without probabilistic mitigations (i.e. leakable) by having out-of-line metadata.
-
No you can't without never reusing a virtual address once it's freed.
-
It's valid to convert pointer -> integer -> pointer and then free that though, with extra steps in between.
-
Only if [u]intptr_t exists. On such an implementation, it doesn't.
End of conversation
New conversation -
-
-
languages with references exist. Languages like C that are incompatible with C tend not to be that interesting.
-
That's a different topic.
End of conversation
New conversation -
-
-
add as option in Musl? Happy to have a safer ABI...
-
Too much would be incompatible plus most of the work is on the compiler side.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.