On Thu, Feb 9, 2023 at 11:23 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > The kernel is globally removing the ambiguous 0-length and 1-element > arrays in favor of flexible arrays, so that we can gain both compile-time > and run-time array bounds checking[1]. Most cases of these changes are > trivial, but this case in BPF is not. It faces some difficulties: > > 1) struct bpf_lpm_trie_key is part of UAPI so changes can be fragile in > the sense that projects external to Linux may be impacted. > > 2) The struct is intended to be used as a header, which means it may > be within another structure, resulting in the "data" array member > overlapping with the surrounding structure's following members. When > converting from [0]-style to []-style, this overlap elicits warnings > under Clang, and GCC considers it a deprecated extension (and similarly > warns under -pedantic): https://godbolt.org/z/vWzqs41h6 > > 3) Both the kernel and userspace access the existing "data" member > for more than just static initializers and offsetof() calculations. > For example: > > cilium: > struct egress_gw_policy_key in_key = { > .lpm_key = { 32 + 24, {} }, > .saddr = CLIENT_IP, > .daddr = EXTERNAL_SVC_IP & 0Xffffff, > }; > > systemd: > ipv6_map_fd = bpf_map_new( > BPF_MAP_TYPE_LPM_TRIE, > offsetof(struct bpf_lpm_trie_key, data) + sizeof(uint32_t)*4, > sizeof(uint64_t), ...); > ... > struct bpf_lpm_trie_key *key_ipv4, *key_ipv6; > ... > memcpy(key_ipv4->data, &a->address, sizeof(uint32_t)); > > Searching for other uses in Debian Code Search seem to be just copies > of UAPI headers: > https://codesearch.debian.net/search?q=struct+bpf_lpm_trie_key&literal=1&perpkg=1 > > Introduce struct bpf_lpm_trie_key_u8 for the kernel (and future userspace) > to use for walking the individual bytes following the header, and leave > the "data" member of struct bpf_lpm_trie_key as-is (i.e. a [0]-style > array). This will allow existing userspace code to continue to use "data" > as a fake flexible array. The kernel (and future userspace code) building > with -fstrict-flex-arrays=3 will see struct bpf_lpm_trie_key::data has > having 0 bytes so there will be no overlap warnings, and can instead > use struct bpf_lpm_trie_key_u8::data for accessing the actual byte > array contents. The definition of struct bpf_lpm_trie_key_u8 uses a > union with struct bpf_lpm_trie_key so that things like container_of() > can be used instead of doing explicit casting, all while leaving the > member names un-namespaced (i.e. key->prefixlen == key_u8->prefixlen, > key->data == key_u8->data), allowing for trivial drop-in replacement > without collateral member renaming. > > This will avoid structure overlap warnings and array bounds warnings > while enabling run-time array bounds checking under CONFIG_UBSAN_BOUNDS=y > and -fstrict-flex-arrays=3. > > For reference, the current warning under GCC 13 with -fstrict-flex-arrays=3 > and -Warray-bounds is: > > ../kernel/bpf/lpm_trie.c:207:51: warning: array subscript i is outside array bounds of 'const __u8[0]' {aka 'const unsigned char[]'} [-Warray-bounds=] > 207 | *(__be16 *)&key->data[i]); > | ^~~~~~~~~~~~~ > ../include/uapi/linux/swab.h:102:54: note: in definition of macro '__swab16' > 102 | #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) > | ^ > ../include/linux/byteorder/generic.h:97:21: note: in expansion of macro '__be16_to_cpu' > 97 | #define be16_to_cpu __be16_to_cpu > | ^~~~~~~~~~~~~ > ../kernel/bpf/lpm_trie.c:206:28: note: in expansion of macro 'be16_to_cpu' > 206 | u16 diff = be16_to_cpu(*(__be16 *)&node->data[i] > ^ > | ^~~~~~~~~~~ > In file included from ../include/linux/bpf.h:7: > ../include/uapi/linux/bpf.h:82:17: note: while referencing 'data' > 82 | __u8 data[0]; /* Arbitrary size */ > | ^~~~ > > Additionally update the samples and selftests to use the new structure, > for demonstrating best practices. > > [1] For lots of details, see both: > https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays > https://people.kernel.org/kees/bounded-flexible-arrays-in-c > > Cc: Alexei Starovoitov <ast@xxxxxxxxxx> > Cc: Stanislav Fomichev <sdf@xxxxxxxxxx> > Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx> > Cc: Andrii Nakryiko <andrii@xxxxxxxxxx> > Cc: Martin KaFai Lau <martin.lau@xxxxxxxxx> > Cc: Song Liu <song@xxxxxxxxxx> > Cc: Yonghong Song <yhs@xxxxxx> > Cc: John Fastabend <john.fastabend@xxxxxxxxx> > Cc: KP Singh <kpsingh@xxxxxxxxxx> > Cc: Hao Luo <haoluo@xxxxxxxxxx> > Cc: Jiri Olsa <jolsa@xxxxxxxxxx> > Cc: Mykola Lysenko <mykolal@xxxxxx> > Cc: Shuah Khan <shuah@xxxxxxxxxx> > Cc: Haowen Bai <baihaowen@xxxxxxxxx> > Cc: bpf@xxxxxxxxxxxxxxx > Cc: linux-kselftest@xxxxxxxxxxxxxxx > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > --- > include/uapi/linux/bpf.h | 15 +++++++++++++-- > kernel/bpf/lpm_trie.c | 16 +++++++++------- > samples/bpf/map_perf_test_user.c | 2 +- > samples/bpf/xdp_router_ipv4_user.c | 2 +- > tools/testing/selftests/bpf/test_lpm_map.c | 14 +++++++------- > 5 files changed, 31 insertions(+), 18 deletions(-) > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > index ba0f0cfb5e42..f843a7582456 100644 > --- a/include/uapi/linux/bpf.h > +++ b/include/uapi/linux/bpf.h > @@ -76,10 +76,21 @@ struct bpf_insn { > __s32 imm; /* signed immediate constant */ > }; > > -/* Key of an a BPF_MAP_TYPE_LPM_TRIE entry */ > +/* Header for a key of a BPF_MAP_TYPE_LPM_TRIE entry */ > struct bpf_lpm_trie_key { > __u32 prefixlen; /* up to 32 for AF_INET, 128 for AF_INET6 */ > - __u8 data[0]; /* Arbitrary size */ > + __u8 data[0]; /* Deprecated field: use struct bpf_lpm_trie_key_u8 */ > +}; > + > +/* Raw (u8 byte array) key of a BPF_MAP_TYPE_LPM_TRIE entry */ > +struct bpf_lpm_trie_key_u8 { > + union { > + struct bpf_lpm_trie_key hdr; > + struct { > + __u32 prefixlen; > + __u8 data[]; > + }; > + }; > }; Do we need to add a new type to UAPI at all here? We can make this new struct internal to kernel code (e.g. struct bpf_lpm_trie_key_kern) and point out that it should match the layout of struct bpf_lpm_trie_key. User-space can decide whether to use bpf_lpm_trie_key as-is, or if just to ensure their custom struct has the same layout (I see some internal users at Meta do just this, just make sure that they have __u32 prefixlen as first member). This whole union work-around seems like just extra cruft that we don't really need in UAPI. Or did I miss anything? [...]
