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?)?
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 -
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.