* [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ
@ 2025-04-29 14:22 Anton Protopopov
2025-04-30 16:00 ` Andrii Nakryiko
0 siblings, 1 reply; 5+ messages in thread
From: Anton Protopopov @ 2025-04-29 14:22 UTC (permalink / raw)
To: bpf; +Cc: Anton Protopopov
With the latest LLVM bpf selftests build will fail with
the following error message:
progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe]
710 | proc_exec_data->parent_uid = BPF_CORE_READ(parent_task, real_cred, uid.val);
| ^
tools/testing/selftests/bpf/tools/include/bpf/bpf_core_read.h:520:35: note: expanded from macro 'BPF_CORE_READ'
520 | ___type((src), a, ##__VA_ARGS__) __r; \
| ^
Fix this by declaring __r to be an array of __u8 of a proper size.
Fixes: 792001f4f7aa ("libbpf: Add user-space variants of BPF_CORE_READ() family of macros")
Fixes: a4b09a9ef945 ("libbpf: Add non-CO-RE variants of BPF_CORE_READ() macro family")
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
---
tools/lib/bpf/bpf_core_read.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h
index c0e13cdf9660..b7395b75658c 100644
--- a/tools/lib/bpf/bpf_core_read.h
+++ b/tools/lib/bpf/bpf_core_read.h
@@ -517,9 +517,9 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak;
* than enough for any practical purpose.
*/
#define BPF_CORE_READ(src, a, ...) ({ \
- ___type((src), a, ##__VA_ARGS__) __r; \
+ __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \
BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); \
- __r; \
+ *(___type((src), a, ##__VA_ARGS__) *)__r; \
})
/*
@@ -533,16 +533,16 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak;
* input argument.
*/
#define BPF_CORE_READ_USER(src, a, ...) ({ \
- ___type((src), a, ##__VA_ARGS__) __r; \
+ __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \
BPF_CORE_READ_USER_INTO(&__r, (src), a, ##__VA_ARGS__); \
- __r; \
+ *(___type((src), a, ##__VA_ARGS__) *)__r; \
})
/* Non-CO-RE variant of BPF_CORE_READ() */
#define BPF_PROBE_READ(src, a, ...) ({ \
- ___type((src), a, ##__VA_ARGS__) __r; \
+ __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \
BPF_PROBE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); \
- __r; \
+ *(___type((src), a, ##__VA_ARGS__) *)__r; \
})
/*
@@ -552,9 +552,9 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak;
* not restricted to kernel types only.
*/
#define BPF_PROBE_READ_USER(src, a, ...) ({ \
- ___type((src), a, ##__VA_ARGS__) __r; \
+ __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \
BPF_PROBE_READ_USER_INTO(&__r, (src), a, ##__VA_ARGS__); \
- __r; \
+ *(___type((src), a, ##__VA_ARGS__) *)__r; \
})
#endif
--
2.34.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ 2025-04-29 14:22 [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ Anton Protopopov @ 2025-04-30 16:00 ` Andrii Nakryiko 2025-04-30 16:33 ` Anton Protopopov 0 siblings, 1 reply; 5+ messages in thread From: Andrii Nakryiko @ 2025-04-30 16:00 UTC (permalink / raw) To: Anton Protopopov; +Cc: bpf On Tue, Apr 29, 2025 at 7:19 AM Anton Protopopov <a.s.protopopov@gmail.com> wrote: > > With the latest LLVM bpf selftests build will fail with > the following error message: > > progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe] this is BPF-side code, what does C++ have to do with this, I'm confused... Also, why using __u8[] is suddenly ok, and using the actual type isn't? Eventually it all is initialized by bpf_probe_read_kernel(), so compiler is wrong or I am misunderstanding something... Can you please help me understand this? > 710 | proc_exec_data->parent_uid = BPF_CORE_READ(parent_task, real_cred, uid.val); > | ^ > tools/testing/selftests/bpf/tools/include/bpf/bpf_core_read.h:520:35: note: expanded from macro 'BPF_CORE_READ' > 520 | ___type((src), a, ##__VA_ARGS__) __r; \ > | ^ > > Fix this by declaring __r to be an array of __u8 of a proper size. > > Fixes: 792001f4f7aa ("libbpf: Add user-space variants of BPF_CORE_READ() family of macros") > Fixes: a4b09a9ef945 ("libbpf: Add non-CO-RE variants of BPF_CORE_READ() macro family") > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com> > --- > tools/lib/bpf/bpf_core_read.h | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h > index c0e13cdf9660..b7395b75658c 100644 > --- a/tools/lib/bpf/bpf_core_read.h > +++ b/tools/lib/bpf/bpf_core_read.h > @@ -517,9 +517,9 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak; > * than enough for any practical purpose. > */ > #define BPF_CORE_READ(src, a, ...) ({ \ > - ___type((src), a, ##__VA_ARGS__) __r; \ > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); \ > - __r; \ > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > }) > > /* > @@ -533,16 +533,16 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak; > * input argument. > */ > #define BPF_CORE_READ_USER(src, a, ...) ({ \ > - ___type((src), a, ##__VA_ARGS__) __r; \ > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > BPF_CORE_READ_USER_INTO(&__r, (src), a, ##__VA_ARGS__); \ > - __r; \ > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > }) > > /* Non-CO-RE variant of BPF_CORE_READ() */ > #define BPF_PROBE_READ(src, a, ...) ({ \ > - ___type((src), a, ##__VA_ARGS__) __r; \ > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > BPF_PROBE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); \ > - __r; \ > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > }) > > /* > @@ -552,9 +552,9 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak; > * not restricted to kernel types only. > */ > #define BPF_PROBE_READ_USER(src, a, ...) ({ \ > - ___type((src), a, ##__VA_ARGS__) __r; \ > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > BPF_PROBE_READ_USER_INTO(&__r, (src), a, ##__VA_ARGS__); \ > - __r; \ > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > }) > > #endif > -- > 2.34.1 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ 2025-04-30 16:00 ` Andrii Nakryiko @ 2025-04-30 16:33 ` Anton Protopopov 2025-04-30 16:34 ` Alexei Starovoitov 0 siblings, 1 reply; 5+ messages in thread From: Anton Protopopov @ 2025-04-30 16:33 UTC (permalink / raw) To: Andrii Nakryiko; +Cc: bpf On 25/04/30 09:00AM, Andrii Nakryiko wrote: > On Tue, Apr 29, 2025 at 7:19 AM Anton Protopopov > <a.s.protopopov@gmail.com> wrote: > > > > With the latest LLVM bpf selftests build will fail with > > the following error message: > > > > progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe] > > this is BPF-side code, what does C++ have to do with this, I'm confused... This I am not sure about why exactly, but clang (wihout ++) emits this warning now (try smth like `clang -c -x c - <<<'void foo(void) {const int x;}'`). When sending patch, I though that CORE* macros also can be used by ++ progs. For C, maybe, this is a problem with clang that it enables -Wdefault-const-init-unsafe? > > Also, why using __u8[] is suddenly ok, and using the actual type > isn't? Eventually it all is initialized by bpf_probe_read_kernel(), so > compiler is wrong or I am misunderstanding something... Can you please > help me understand this? So, when a const sneaks in, one have BPF_CORE_READ expanded into say smth like this: ({ typeof(((parent_task)->real_cred->uid.val)) __r; BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); __r; }) It happens that real_cred is a pointer to const, so __r becomes const, and thus the warning (if enabled) is legit. With __u8 this turns into (let T = typeof(((parent_task)->real_cred->uid.val))) ({ __u8 __r[sizeof(T)]; BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); * (T *) __r; }) So here we do not care if T is const or not, as __r is not in any case. > > > 710 | proc_exec_data->parent_uid = BPF_CORE_READ(parent_task, real_cred, uid.val); > > | ^ > > tools/testing/selftests/bpf/tools/include/bpf/bpf_core_read.h:520:35: note: expanded from macro 'BPF_CORE_READ' > > 520 | ___type((src), a, ##__VA_ARGS__) __r; \ > > | ^ > > > > Fix this by declaring __r to be an array of __u8 of a proper size. > > > > Fixes: 792001f4f7aa ("libbpf: Add user-space variants of BPF_CORE_READ() family of macros") > > Fixes: a4b09a9ef945 ("libbpf: Add non-CO-RE variants of BPF_CORE_READ() macro family") > > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com> > > --- > > tools/lib/bpf/bpf_core_read.h | 16 ++++++++-------- > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/tools/lib/bpf/bpf_core_read.h b/tools/lib/bpf/bpf_core_read.h > > index c0e13cdf9660..b7395b75658c 100644 > > --- a/tools/lib/bpf/bpf_core_read.h > > +++ b/tools/lib/bpf/bpf_core_read.h > > @@ -517,9 +517,9 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak; > > * than enough for any practical purpose. > > */ > > #define BPF_CORE_READ(src, a, ...) ({ \ > > - ___type((src), a, ##__VA_ARGS__) __r; \ > > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > > BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); \ > > - __r; \ > > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > > }) > > > > /* > > @@ -533,16 +533,16 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak; > > * input argument. > > */ > > #define BPF_CORE_READ_USER(src, a, ...) ({ \ > > - ___type((src), a, ##__VA_ARGS__) __r; \ > > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > > BPF_CORE_READ_USER_INTO(&__r, (src), a, ##__VA_ARGS__); \ > > - __r; \ > > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > > }) > > > > /* Non-CO-RE variant of BPF_CORE_READ() */ > > #define BPF_PROBE_READ(src, a, ...) ({ \ > > - ___type((src), a, ##__VA_ARGS__) __r; \ > > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > > BPF_PROBE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); \ > > - __r; \ > > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > > }) > > > > /* > > @@ -552,9 +552,9 @@ extern void *bpf_rdonly_cast(const void *obj, __u32 btf_id) __ksym __weak; > > * not restricted to kernel types only. > > */ > > #define BPF_PROBE_READ_USER(src, a, ...) ({ \ > > - ___type((src), a, ##__VA_ARGS__) __r; \ > > + __u8 __r[sizeof(___type((src), a, ##__VA_ARGS__))]; \ > > BPF_PROBE_READ_USER_INTO(&__r, (src), a, ##__VA_ARGS__); \ > > - __r; \ > > + *(___type((src), a, ##__VA_ARGS__) *)__r; \ > > }) > > > > #endif > > -- > > 2.34.1 > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ 2025-04-30 16:33 ` Anton Protopopov @ 2025-04-30 16:34 ` Alexei Starovoitov 2025-04-30 17:24 ` Anton Protopopov 0 siblings, 1 reply; 5+ messages in thread From: Alexei Starovoitov @ 2025-04-30 16:34 UTC (permalink / raw) To: Anton Protopopov; +Cc: Andrii Nakryiko, bpf On Wed, Apr 30, 2025 at 9:29 AM Anton Protopopov <a.s.protopopov@gmail.com> wrote: > > On 25/04/30 09:00AM, Andrii Nakryiko wrote: > > On Tue, Apr 29, 2025 at 7:19 AM Anton Protopopov > > <a.s.protopopov@gmail.com> wrote: > > > > > > With the latest LLVM bpf selftests build will fail with > > > the following error message: > > > > > > progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe] > > > > this is BPF-side code, what does C++ have to do with this, I'm confused... > > This I am not sure about why exactly, but clang (wihout ++) emits this warning > now (try smth like `clang -c -x c - <<<'void foo(void) {const int x;}'`). > When sending patch, I though that CORE* macros also can be used by ++ progs. > For C, maybe, this is a problem with clang that it enables -Wdefault-const-init-unsafe? > > > > > Also, why using __u8[] is suddenly ok, and using the actual type > > isn't? Eventually it all is initialized by bpf_probe_read_kernel(), so > > compiler is wrong or I am misunderstanding something... Can you please > > help me understand this? > > So, when a const sneaks in, one have BPF_CORE_READ expanded into > say smth like this: > > ({ > typeof(((parent_task)->real_cred->uid.val)) __r; > BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); > __r; > }) > > It happens that real_cred is a pointer to const, so __r becomes const, > and thus the warning (if enabled) is legit. > > With __u8 this turns into (let T = typeof(((parent_task)->real_cred->uid.val))) > > ({ > __u8 __r[sizeof(T)]; > BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); > * (T *) __r; > }) > > So here we do not care if T is const or not, as __r is not in any case. The problem with __u8 approach is that it's losing alignment. Have you tried typeof_unqual instead ? Modern gcc and clang support it directly. For older compilers we have __unqual_typeof() in bpf_atomic.h ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ 2025-04-30 16:34 ` Alexei Starovoitov @ 2025-04-30 17:24 ` Anton Protopopov 0 siblings, 0 replies; 5+ messages in thread From: Anton Protopopov @ 2025-04-30 17:24 UTC (permalink / raw) To: Alexei Starovoitov; +Cc: Andrii Nakryiko, bpf On 25/04/30 09:34AM, Alexei Starovoitov wrote: > On Wed, Apr 30, 2025 at 9:29 AM Anton Protopopov > <a.s.protopopov@gmail.com> wrote: > > > > On 25/04/30 09:00AM, Andrii Nakryiko wrote: > > > On Tue, Apr 29, 2025 at 7:19 AM Anton Protopopov > > > <a.s.protopopov@gmail.com> wrote: > > > > > > > > With the latest LLVM bpf selftests build will fail with > > > > the following error message: > > > > > > > > progs/profiler.inc.h:710:31: error: default initialization of an object of type 'typeof ((parent_task)->real_cred->uid.val)' (aka 'const unsigned int') leaves the object uninitialized and is incompatible with C++ [-Werror,-Wdefault-const-init-unsafe] > > > > > > this is BPF-side code, what does C++ have to do with this, I'm confused... > > > > This I am not sure about why exactly, but clang (wihout ++) emits this warning > > now (try smth like `clang -c -x c - <<<'void foo(void) {const int x;}'`). > > When sending patch, I though that CORE* macros also can be used by ++ progs. > > For C, maybe, this is a problem with clang that it enables -Wdefault-const-init-unsafe? > > > > > > > > Also, why using __u8[] is suddenly ok, and using the actual type > > > isn't? Eventually it all is initialized by bpf_probe_read_kernel(), so > > > compiler is wrong or I am misunderstanding something... Can you please > > > help me understand this? > > > > So, when a const sneaks in, one have BPF_CORE_READ expanded into > > say smth like this: > > > > ({ > > typeof(((parent_task)->real_cred->uid.val)) __r; > > BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); > > __r; > > }) > > > > It happens that real_cred is a pointer to const, so __r becomes const, > > and thus the warning (if enabled) is legit. > > > > With __u8 this turns into (let T = typeof(((parent_task)->real_cred->uid.val))) > > > > ({ > > __u8 __r[sizeof(T)]; > > BPF_CORE_READ_INTO(&__r, (src), a, ##__VA_ARGS__); > > * (T *) __r; > > }) > > > > So here we do not care if T is const or not, as __r is not in any case. > > The problem with __u8 approach is that it's losing alignment. > Have you tried typeof_unqual instead ? > Modern gcc and clang support it directly. Yes, thanks, typeof_unqual should work. > For older compilers we have __unqual_typeof() in bpf_atomic.h Older compilers aren't a problem, as build only fails on modern (LLVM added -Wdefault-const-init-unsafe for C just a few days ago). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-04-30 17:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-29 14:22 [PATCH v2 bpf-next] bpf: fix uninitialized values in BPF_{CORE,PROBE}_READ Anton Protopopov
2025-04-30 16:00 ` Andrii Nakryiko
2025-04-30 16:33 ` Anton Protopopov
2025-04-30 16:34 ` Alexei Starovoitov
2025-04-30 17:24 ` Anton Protopopov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.