LWN: Comments on "Strict memcpy() bounds checking for the kernel"

Strict memcpy() bounds checking for the kernel

ukleinek — Thu, 02 May 2024 09:59:12 +0000

The syntax in the example is wrong.

struct foo {
int one;
struct_group(thing,
int two; // <-- ; here
int three; // <-- and here
);
int four;
};

Strict memcpy() bounds checking for the kernel

willy — Tue, 03 Aug 2021 02:22:29 +0000

Of course, the kernel disables SIMD so that it doesn't use the XMM/YMM registers, and thus they don't have to be saved/restored at system call time.

Strict memcpy() bounds checking for the kernel

kees — Mon, 02 Aug 2021 15:07:11 +0000

Right, and if any __randomize_layout struct wanted to use struct_group() it could as those would be kept together. It actually makes things easier.

drastic performance gains

jreiser — Mon, 02 Aug 2021 00:25:19 +0000

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.

Strict memcpy() bounds checking for the kernel

HenrikH — Sun, 01 Aug 2021 13:23:29 +0000

replacing that with a pure memset (yes I know that your example didn't clear all the members, but still) resulted in even less code.

Strict memcpy() bounds checking for the kernel

epa — Sun, 01 Aug 2021 08:41:42 +0000

It seems like ‘copy the following members of a struct’ or ‘copy all except these’ or ‘copy from this point to this point’ would be useful extensions to the C language.

Strict memcpy() bounds checking for the kernel

jengelh — Sat, 31 Jul 2021 13:27:30 +0000

Yes, it will also optimize for uint8_t. You just need enough bytes overall (looks like >= 8) to make it worthwhile for gcc to switch to SIMD-based copying.
For bitfields there is a bit of a problem, for which I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101705 .

Strict memcpy() bounds checking for the kernel

CAFxX — Sat, 31 Jul 2021 13:22:36 +0000

Seems like it can do even better than memcpy, in that it can handle cases where memcpy would waste work: https://godbolt.org/z/aa31McEjx

Strict memcpy() bounds checking for the kernel

Hello71 — Sat, 31 Jul 2021 12:38:56 +0000

no: https://gcc.godbolt.org/z/aP8GWb487

i don't understand what "running afoul of new members added to S" means anyways. it seems to me that in the vast majority of cases, when new members are added, one would want them to be copied too. otherwise, write memcpy(dest, src, sizeof(*dest) - offsetof(struct S, last_member) + sizeof(dest->last_member))?

Strict memcpy() bounds checking for the kernel

rurban — Sat, 31 Jul 2021 11:20:56 +0000

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

Strict memcpy() bounds checking for the kernel

bartoc — Sat, 31 Jul 2021 07:05:59 +0000

Interestingly that struct group macro is essentially recreating part of gcc's plan9-extensions (presumably they can from plan9). I will admit that using a typedef as the indication of "I want the member name and the anon-struct behavior" is pretty odd. Also it turns on other stuff (like the object oriented implicit pointer casts).

Strict memcpy() bounds checking for the kernel

alison — Sat, 31 Jul 2021 04:31:20 +0000

>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

pbonzini — Fri, 30 Jul 2021 21:54:18 +0000

Does that still work when some fields are u8 or bool and some are even bitfields? Is the compiler able to produce the same code as with memcpy?

Strict memcpy() bounds checking for the kernel

mathstuf — Fri, 30 Jul 2021 21:33:02 +0000

Isn't that just for static structures full of function pointers (basically vtables)? Presumably `sk_buff` structures and other such things being `memcpy`'d to are not constant once the kernel is booted.

Strict memcpy() bounds checking for the kernel

post-factum — Fri, 30 Jul 2021 21:07:37 +0000

How does it play with the struct layout randomisation?

Strict memcpy() bounds checking for the kernel

jengelh — Fri, 30 Jul 2021 20:28:18 +0000

#include <string.h>
struct S { int one, two, three, four; };
void lefttoright(struct S *d, struct S *s) {
d->one = s->one; d->two = s->two; d->three = s->three; d->four = s->four; }

Explicit field copies. More to type, but no running afoul of new members added to S. gcc-11.1.1 -O3 is capable to produce the same x86_64 asm as a field-insensitive memcpy(d,s,sizeof(*s)) would on -O2.