So why don't most libc/kernel implementations ship a "memcpy" that would query the number of available bytes from the allocator (for heap objects), from the linker (for globals) and from some compiler-generated info (CFI?)?
-
-
yes, but ASan is too heavy-weight. It seems that hardened usercopy is exactly what I've described and if I'm not mistaken grsec had a compiler plugin for stack instrumentation. Now, why did this not get adopted everywhere at least for debugging, and did not get benchmarked?
-
I don't think hardened usercopy is related.
-
It's related but it's way too slow to use it for memcpy, especially in libc. Most malloc implementations aren't capable of providing a comparable feature. Kernel slab allocators are similar to a hardened malloc like OpenBSD malloc other than how they track free objects in slabs.
End of conversation
New conversation -
-
-
Also _FORTIFY_SOURCE kinda does it for production use, but the scope of size availability is limited.
-
Could extend it by providing a way to extend __builtin_object_size to call into a function with hooks into malloc & symbol table if size isn't locally known...
-
But making that work depends on a malloc implementation that can find an allocation by any pointer into it, not just pointer to start.
-
yes, and that depends on not trusting the pointers that you pass to "free()" and ideally not storing metadata inline with the data
-
OpenBSD malloc works like this and we have a __dynamic_object_size(arbitrary_pointer) implementation for it which we use for dynamic overflow checks in the libc system call wrappers. It's one of the features we haven't fully ported to Android Oreo though.
-
Still have __dynamic_object_size (which calls our __malloc_object_size) but need to add back the system call wrappers using it. They moved everything around and it just needs a bit of work. Doing it like this lets it work for indirect calls and doesn't require rebuilding code.
-
It would be ridiculously slow to use it with the string functions. It's only used for system calls. If you want pervasive overflow checks, you should probably just recompile code with fat pointers and check all dereferences not just string functions.
-
Can have a fat pointer ABI side-by-side with the existing ABI as part of phasing it in, just like a multiarch 32-bit -> 64-bit transition. Integer -> pointer conversions would need to use an intrinsic to set the size to enforce proper bounds checks but otherwise it's automatic.
End of conversation
New conversation -
-
-
ASan checks aren't based on allocation sizes. It's best effort checking based on bitmaps and red zones.
-
ASan approach can only reliably catch linear overflows. It can detect some non-linear overflows, but not all, and definitely not ones done by an attacker. It can't really detect a write from one heap object into another. It's good at catching some accidental stray accesses.
-
Similarly, ASan double-free / use-after-free detection works via a quarantine with a limited size so it's also only best effort. It's really an allocator feature and makes sense in a debugging or hardened allocator without any of the compiler instrumentation too.
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.