As reported in [0], kernel and userspace can sometimes disagree
on the size of a type. This leads to trouble when userspace maps the memory of
a bpf program and reads/writes to it assuming a different memory layout.
With this change, the skeletons now contain size asserts to ensure the
types in userspace are compatible in size with the types in the bpf program.
In particular, we emit asserts for all top-level fields in the data/rodata/bss/etc
structs, but not recursively for the individual members inside - this strikes a
compromise between diagnostics precision and still catching all possible size
mismatches.
The generated asserts are somewhat ugly but are able to handle anonymous structs:
struct test_skeleton__data {
int in1;
char __pad0[4];
long long in2;
int out1;
char __pad1[4];
long long out2;
} *data;
BPF_STATIC_ASSERT(sizeof(((struct test_skeleton__data*)0)->in1) == 4, "unexpe
cted size of field in1");
BPF_STATIC_ASSERT(sizeof(((struct test_skeleton__data*)0)->in2) == 8, "unexpe
cted size of field in2");
BPF_STATIC_ASSERT(sizeof(((struct test_skeleton__data*)0)->out1) == 4, "unexp
ected size of field out1");
BPF_STATIC_ASSERT(sizeof(((struct test_skeleton__data*)0)->out2) == 8, "unexp
ected size of field out2");
struct test_skeleton__rodata {
struct {
int in6;
} in;
} *rodata;
BPF_STATIC_ASSERT(sizeof(((struct test_skeleton__rodata*)0)->in) == 4, "unexp
ected size of field in");
I'm open to pushing more of the ugliness into a macro, I was going primarily for
simplicity in the diagnostic messages (it's unfortunate enough that we need a level
of macro expansion for C++ support). If we need this to be prettier, what's a good
header I could push any extra complexity into, so it's not spelled out in gen.c?
Delyan Kratunov (1):
bpftool: bpf skeletons assert type sizes
tools/bpf/bpftool/gen.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
--
2.34.1
