Strict memcpy() bounds checking for the kernel

Posted Jul 31, 2021 4:31 UTC (Sat) by alison (subscriber, #63752)
Parent article: Strict memcpy() bounds checking for the kernel

>See the GCC documentation for more information on __builtin_object_size().

I wondered if __builtin_object_size() would work with Clang. Here is another few-day-old Cook patch in that regard: https://lkml.org/lkml/2021/7/27/1161

Which I take to mean "not in current release."

Strict memcpy() bounds checking for the kernel

Posted Jul 31, 2021 11:20 UTC (Sat) by rurban (guest, #96594) [Link] (1 responses)

BOS works much better in clang than gcc. I implemented those tricks in my str*/mem* variants, and clang could detect much more compile-time sizes, and it has diagnose_if to throw the same compile-time warnings as the runtime libc.
https://github.com/rurban/safeclib/blob/master/include/sa...

With drastic performance gains. https://github.com/rurban/safeclib/blob/master/tests/perf...

drastic performance gains

Posted Aug 2, 2021 0:25 UTC (Mon) by jreiser (subscriber, #11027) [Link]

In the linked file perf_memcpy_s.c, I saw uniform weighting of chunks that are all multiples of 1 KiB. What happens for a model that is closer to actual usage in the Linux kernel? The kernel has obvious special cases for filesystems, network stack, and general management of pages; but what about the rest? Measuring the task of re-compiling and re-building the kernel under the configurations "all module" and "all yes" are two interesting cases.

In user space, a very large portion of allocations by malloc() are for 100 bytes or fewer, which constrains memcpy to "small" lengths on average. See http://www.linuxplumbersconf.net/2016/ocw//system/presentations/3921/original/LPC%202016%20-%20linux%20and%20glibc_%20The%204.5TiB%20malloc%20API%20trace.pdf.