* [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.