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...
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-... https://people.kernel.org/kees/bounded-flexible-arrays-in-c
Cc: Alexei Starovoitov ast@kernel.org Cc: Stanislav Fomichev sdf@google.com Cc: Daniel Borkmann daniel@iogearbox.net Cc: Andrii Nakryiko andrii@kernel.org Cc: Martin KaFai Lau martin.lau@linux.dev Cc: Song Liu song@kernel.org Cc: Yonghong Song yhs@fb.com Cc: John Fastabend john.fastabend@gmail.com Cc: KP Singh kpsingh@kernel.org Cc: Hao Luo haoluo@google.com Cc: Jiri Olsa jolsa@kernel.org Cc: Mykola Lysenko mykolal@fb.com Cc: Shuah Khan shuah@kernel.org Cc: Haowen Bai baihaowen@meizu.com Cc: bpf@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Signed-off-by: Kees Cook keescook@chromium.org --- 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[]; + }; + }; };
struct bpf_cgroup_storage_key { diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c index d833496e9e42..3a93ace62c87 100644 --- a/kernel/bpf/lpm_trie.c +++ b/kernel/bpf/lpm_trie.c @@ -164,13 +164,15 @@ static inline int extract_bit(const u8 *data, size_t index) */ static size_t longest_prefix_match(const struct lpm_trie *trie, const struct lpm_trie_node *node, - const struct bpf_lpm_trie_key *key) + const struct bpf_lpm_trie_key_u8 *key) { u32 limit = min(node->prefixlen, key->prefixlen); u32 prefixlen = 0, i = 0;
- BUILD_BUG_ON(offsetof(struct lpm_trie_node, data) % sizeof(u32)); - BUILD_BUG_ON(offsetof(struct bpf_lpm_trie_key, data) % sizeof(u32)); + BUILD_BUG_ON(offsetof(typeof(*node), data) % sizeof(u32)); + BUILD_BUG_ON(offsetof(typeof(*key), data) % sizeof(u32)); + BUILD_BUG_ON(offsetof(typeof(*key), data) != + offsetof(typeof(key->hdr), data));
#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) && defined(CONFIG_64BIT)
@@ -229,7 +231,7 @@ static void *trie_lookup_elem(struct bpf_map *map, void *_key) { struct lpm_trie *trie = container_of(map, struct lpm_trie, map); struct lpm_trie_node *node, *found = NULL; - struct bpf_lpm_trie_key *key = _key; + struct bpf_lpm_trie_key_u8 *key = _key;
/* Start walking the trie from the root node ... */
@@ -306,7 +308,7 @@ static int trie_update_elem(struct bpf_map *map, struct lpm_trie *trie = container_of(map, struct lpm_trie, map); struct lpm_trie_node *node, *im_node = NULL, *new_node = NULL; struct lpm_trie_node __rcu **slot; - struct bpf_lpm_trie_key *key = _key; + struct bpf_lpm_trie_key_u8 *key = _key; unsigned long irq_flags; unsigned int next_bit; size_t matchlen = 0; @@ -434,7 +436,7 @@ static int trie_update_elem(struct bpf_map *map, static int trie_delete_elem(struct bpf_map *map, void *_key) { struct lpm_trie *trie = container_of(map, struct lpm_trie, map); - struct bpf_lpm_trie_key *key = _key; + struct bpf_lpm_trie_key_u8 *key = _key; struct lpm_trie_node __rcu **trim, **trim2; struct lpm_trie_node *node, *parent; unsigned long irq_flags; @@ -616,7 +618,7 @@ static int trie_get_next_key(struct bpf_map *map, void *_key, void *_next_key) { struct lpm_trie_node *node, *next_node = NULL, *parent, *search_root; struct lpm_trie *trie = container_of(map, struct lpm_trie, map); - struct bpf_lpm_trie_key *key = _key, *next_key = _next_key; + struct bpf_lpm_trie_key_u8 *key = _key, *next_key = _next_key; struct lpm_trie_node **node_stack = NULL; int err = 0, stack_ptr = -1; unsigned int next_bit; diff --git a/samples/bpf/map_perf_test_user.c b/samples/bpf/map_perf_test_user.c index d2fbcf963cdf..07ff471ed6ae 100644 --- a/samples/bpf/map_perf_test_user.c +++ b/samples/bpf/map_perf_test_user.c @@ -370,7 +370,7 @@ static void run_perf_test(int tasks)
static void fill_lpm_trie(void) { - struct bpf_lpm_trie_key *key; + struct bpf_lpm_trie_key_u8 *key; unsigned long value = 0; unsigned int i; int r; diff --git a/samples/bpf/xdp_router_ipv4_user.c b/samples/bpf/xdp_router_ipv4_user.c index 9d41db09c480..266fdd0b025d 100644 --- a/samples/bpf/xdp_router_ipv4_user.c +++ b/samples/bpf/xdp_router_ipv4_user.c @@ -91,7 +91,7 @@ static int recv_msg(struct sockaddr_nl sock_addr, int sock) static void read_route(struct nlmsghdr *nh, int nll) { char dsts[24], gws[24], ifs[16], dsts_len[24], metrics[24]; - struct bpf_lpm_trie_key *prefix_key; + struct bpf_lpm_trie_key_u8 *prefix_key; struct rtattr *rt_attr; struct rtmsg *rt_msg; int rtm_family; diff --git a/tools/testing/selftests/bpf/test_lpm_map.c b/tools/testing/selftests/bpf/test_lpm_map.c index c028d621c744..e2e822759e13 100644 --- a/tools/testing/selftests/bpf/test_lpm_map.c +++ b/tools/testing/selftests/bpf/test_lpm_map.c @@ -211,7 +211,7 @@ static void test_lpm_map(int keysize) volatile size_t n_matches, n_matches_after_delete; size_t i, j, n_nodes, n_lookups; struct tlpm_node *t, *list = NULL; - struct bpf_lpm_trie_key *key; + struct bpf_lpm_trie_key_u8 *key; uint8_t *data, *value; int r, map;
@@ -331,8 +331,8 @@ static void test_lpm_map(int keysize) static void test_lpm_ipaddr(void) { LIBBPF_OPTS(bpf_map_create_opts, opts, .map_flags = BPF_F_NO_PREALLOC); - struct bpf_lpm_trie_key *key_ipv4; - struct bpf_lpm_trie_key *key_ipv6; + struct bpf_lpm_trie_key_u8 *key_ipv4; + struct bpf_lpm_trie_key_u8 *key_ipv6; size_t key_size_ipv4; size_t key_size_ipv6; int map_fd_ipv4; @@ -423,7 +423,7 @@ static void test_lpm_ipaddr(void) static void test_lpm_delete(void) { LIBBPF_OPTS(bpf_map_create_opts, opts, .map_flags = BPF_F_NO_PREALLOC); - struct bpf_lpm_trie_key *key; + struct bpf_lpm_trie_key_u8 *key; size_t key_size; int map_fd; __u64 value; @@ -532,7 +532,7 @@ static void test_lpm_delete(void) static void test_lpm_get_next_key(void) { LIBBPF_OPTS(bpf_map_create_opts, opts, .map_flags = BPF_F_NO_PREALLOC); - struct bpf_lpm_trie_key *key_p, *next_key_p; + struct bpf_lpm_trie_key_u8 *key_p, *next_key_p; size_t key_size; __u32 value = 0; int map_fd; @@ -693,7 +693,7 @@ static void *lpm_test_command(void *arg) { int i, j, ret, iter, key_size; struct lpm_mt_test_info *info = arg; - struct bpf_lpm_trie_key *key_p; + struct bpf_lpm_trie_key_u8 *key_p;
key_size = sizeof(struct bpf_lpm_trie_key) + sizeof(__u32); key_p = alloca(key_size); @@ -717,7 +717,7 @@ static void *lpm_test_command(void *arg) ret = bpf_map_lookup_elem(info->map_fd, key_p, &value); assert(ret == 0 || errno == ENOENT); } else { - struct bpf_lpm_trie_key *next_key_p = alloca(key_size); + struct bpf_lpm_trie_key_u8 *next_key_p = alloca(key_size); ret = bpf_map_get_next_key(info->map_fd, key_p, next_key_p); assert(ret == 0 || errno == ENOENT || errno == ENOMEM); }
On Thu, Feb 9, 2023 at 11:23 AM Kees Cook keescook@chromium.org 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:
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.
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
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...
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-... https://people.kernel.org/kees/bounded-flexible-arrays-in-c
Cc: Alexei Starovoitov ast@kernel.org Cc: Stanislav Fomichev sdf@google.com Cc: Daniel Borkmann daniel@iogearbox.net Cc: Andrii Nakryiko andrii@kernel.org Cc: Martin KaFai Lau martin.lau@linux.dev Cc: Song Liu song@kernel.org Cc: Yonghong Song yhs@fb.com Cc: John Fastabend john.fastabend@gmail.com Cc: KP Singh kpsingh@kernel.org Cc: Hao Luo haoluo@google.com Cc: Jiri Olsa jolsa@kernel.org Cc: Mykola Lysenko mykolal@fb.com Cc: Shuah Khan shuah@kernel.org Cc: Haowen Bai baihaowen@meizu.com Cc: bpf@vger.kernel.org Cc: linux-kselftest@vger.kernel.org Signed-off-by: Kees Cook keescook@chromium.org
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?
[...]
On Thu, Feb 09, 2023 at 11:52:10AM -0800, Andrii Nakryiko wrote:
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).
This whole union work-around seems like just extra cruft that we don't really need in UAPI.
The union is really only there so that possible uses of container_of() would be happy. But I did add a BUILD_BUG_ON() test for member offset equality, so a hard cast would be safe too. I'm happy to drop it if that's preferred?
On Thu, Feb 9, 2023 at 12:05 PM Kees Cook keescook@chromium.org wrote:
On Thu, Feb 09, 2023 at 11:52:10AM -0800, Andrii Nakryiko wrote:
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).
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?
On Thu, Feb 09, 2023 at 12:50:28PM -0800, Alexei Starovoitov wrote:
On Thu, Feb 9, 2023 at 12:05 PM Kees Cook keescook@chromium.org wrote:
On Thu, Feb 09, 2023 at 11:52:10AM -0800, Andrii Nakryiko wrote:
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).
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).
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.
What is the disadvantage?
It seemed better to give a working example of how to migrate this code.
Regardless, I can just make this specific to the kernel code if that's what's wanted.
On Thu, Feb 9, 2023 at 1:12 PM Kees Cook keescook@chromium.org wrote:
On Thu, Feb 09, 2023 at 12:50:28PM -0800, Alexei Starovoitov wrote:
On Thu, Feb 9, 2023 at 12:05 PM Kees Cook keescook@chromium.org wrote:
On Thu, Feb 09, 2023 at 11:52:10AM -0800, Andrii Nakryiko wrote:
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).
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).
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.
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.
On February 9, 2023 2:01:15 PM PST, Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Thu, Feb 9, 2023 at 1:12 PM Kees Cook keescook@chromium.org wrote:
On Thu, Feb 09, 2023 at 12:50:28PM -0800, Alexei Starovoitov wrote:
On Thu, Feb 9, 2023 at 12:05 PM Kees Cook keescook@chromium.org wrote:
On Thu, Feb 09, 2023 at 11:52:10AM -0800, Andrii Nakryiko wrote:
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).
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).
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.
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.
Maybe I'm missing something, but if a program isn't building with -fstrict-flex-arrays=3, it can keep on using struct bpf_lpm_trie_key as before. If/when it starts using -fsfa, if can use struct bpf_lpm_trie_key in composite structs as a header just like before, but if it has places using the "data" member as an array of u8, it can switch to something using struct bpf_lpm_trie_key_u8, either directly or as a union with whatever ever struct they have. (And this replacement is what I did for all the samples/selftests.)
linux-kselftest-mirror@lists.linaro.org
-
Alexei Starovoitov -
Andrii Nakryiko -
Kees Cook -
Kees Cook