bpf: Deprecate "data" member of bpf_lpm_trie_key

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 <[email protected]>

Cc Stanislav Fomichev <[email protected]>

Cc Daniel Borkmann <[email protected]>

Cc Andrii Nakryiko <[email protected]>

Cc Martin KaFai Lau <[email protected]>

Cc Song Liu <[email protected]>

Cc Yonghong Song <[email protected]>

Cc John Fastabend <[email protected]>

Cc KP Singh <[email protected]>

Cc Hao Luo <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Mykola Lysenko <[email protected]>

Cc Shuah Khan <[email protected]>

Cc Haowen Bai <[email protected]>

Cc [email protected]

Cc [email protected]

Signed-off-by Kees Cook <[email protected]>

---
 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(-)

include/uapi/linux/bpf.h +4 -2

index ba0f0cfb5e42..f843a7582456 100644
@@ -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 */
+};
+

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.

Quoted 7 lines · Andrii Nakryiko

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

The uses outside the kernel seemed numerous enough to justify a new UAPI struct (samples, selftests, etc). It also paves a single way forward when the userspace projects start using modern compiler options (e.g. systemd is usually pretty quick to adopt new features).

Quoted 10 lines · Kees Cook

Quoted 7 lines · Andrii Nakryiko

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

Quoted 4 lines

The uses outside the kernel seemed numerous enough to justify a new UAPI struct (samples, selftests, etc). It also paves a single way forward when the userspace projects start using modern compiler options (e.g. systemd is usually pretty quick to adopt new features).

I don't understand how the new uapi struct bpf_lpm_trie_key_u8 helps. cilium progs and progs/map_ptr_kern.c
cannot do s/bpf_lpm_trie_key/bpf_lpm_trie_key_u8/.
They will fail to build, so they're stuck with bpf_lpm_trie_key.

Can we do just
struct bpf_lpm_trie_key_kern {
__u32 prefixlen;
__u8 data[];
};
and use it in the kernel?

What is the disadvantage?

Quoted 16 lines · Alexei Starovoitov

Quoted 10 lines · Kees Cook

Quoted 7 lines · Andrii Nakryiko

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

Quoted 4 lines

The uses outside the kernel seemed numerous enough to justify a new UAPI struct (samples, selftests, etc). It also paves a single way forward when the userspace projects start using modern compiler options (e.g. systemd is usually pretty quick to adopt new features).

Quoted 4 lines

I don't understand how the new uapi struct bpf_lpm_trie_key_u8 helps. cilium progs and progs/map_ptr_kern.c
cannot do s/bpf_lpm_trie_key/bpf_lpm_trie_key_u8/.
They will fail to build, so they're stuck with bpf_lpm_trie_key.

Right -- I'm proposing not changing bpf_lpm_trie_key. I'm proposing _adding_ bpf_lpm_trie_key_u8 for new users who will be using modern compiler options (i.e. where "data[0]" is nonsense).

Quoted 6 lines

Can we do just
struct bpf_lpm_trie_key_kern {
__u32 prefixlen;
__u8 data[];
};
and use it in the kernel?

Yeah, I can do that if that's preferred, but it leaves userspace hanging when they eventually trip over this in their code when they enable -fstrict-flex-arrays=3 too.

Quoted 1 line

What is the disadvantage?

It seemed better to give a working example of how to migrate this code.

Quoted 34 lines · Kees Cook

Quoted 16 lines · Alexei Starovoitov

Quoted 10 lines · Kees Cook

Quoted 7 lines · Andrii Nakryiko

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

Quoted 4 lines

The uses outside the kernel seemed numerous enough to justify a new UAPI struct (samples, selftests, etc). It also paves a single way forward when the userspace projects start using modern compiler options (e.g. systemd is usually pretty quick to adopt new features).

Quoted 4 lines

I don't understand how the new uapi struct bpf_lpm_trie_key_u8 helps. cilium progs and progs/map_ptr_kern.c
cannot do s/bpf_lpm_trie_key/bpf_lpm_trie_key_u8/.
They will fail to build, so they're stuck with bpf_lpm_trie_key.

Right -- I'm proposing not changing bpf_lpm_trie_key. I'm proposing _adding_ bpf_lpm_trie_key_u8 for new users who will be using modern compiler options (i.e. where "data[0]" is nonsense).

Quoted 6 lines

Can we do just
struct bpf_lpm_trie_key_kern {
__u32 prefixlen;
__u8 data[];
};
and use it in the kernel?

Quoted 7 lines

Yeah, I can do that if that's preferred, but it leaves userspace hanging when they eventually trip over this in their code when they enable -fstrict-flex-arrays=3 too.

Quoted 1 line

What is the disadvantage?

It seemed better to give a working example of how to migrate this code.

I understand and agree with intent, but I'm still missing
how you're going to achieve this migration. bpf_lpm_trie_key_u8 doesn't provide a migration path to cilium progs and pretty much all bpf progs that use LPM map.
Sure, one can change the user space part, like you did in test_lpm_map.c, but it doesn't address the full scope.
imo half way is worse than not doing it.