From: Yonghong Song <yonghong.song@linux.dev>
To: lsf-pc <lsf-pc@lists.linux-foundation.org>
Cc: bpf <bpf@vger.kernel.org>, "Eddy Z" <eddyz87@gmail.com>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Marc Suñé" <marc.sune@isovalent.com>
Subject: [LSF/MM/BPF TOPIC] Uninitialized Variable In BPF Programs
Date: Tue, 28 Jan 2025 13:41:47 -0800 [thread overview]
Message-ID: <eac5f55f-8aeb-4a6d-9aca-820c5ad4c3a7@linux.dev> (raw)
If bpf program has an uninitialized variable, clang compiler
may take advantage of it to do some optimization. The resulted
bpf program may still survive verification but get wrong result.
Users then may take quite some time to understand the real
reason by inspecting asm codes.
The compiler flags '-Wall -Werror' are supposed to issue errors
if an uninitialized variable impacts the final result. But in
reality, since compiler may not be 100% sure a variable is
uninitalized due to limited analysis, the error may not be emitted.
gcc has '-Wmaybe-uninitialized' flag to issue warnings for some
possible uninit variables but still may miss some others.
clang does not support '-Wmaybe-uninitialized' flag.
There are already some discussion in llvm community for this ([1]).
I would like to elaborate more with some examples, e.g. how llvm
internal handle uninit variables, and discuss how we could do
something to expose harmful uninit variable earlier.
[1] https://discourse.llvm.org/t/detect-undefined-behavior-due-to-uninitialized-variables-in-bpf-programs/84116?u=yonghong-song
next reply other threads:[~2025-01-28 21:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 21:41 Yonghong Song [this message]
2025-01-30 0:53 ` [LSF/MM/BPF TOPIC] Uninitialized Variable In BPF Programs Alexei Starovoitov
2025-01-30 7:24 ` Yonghong Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eac5f55f-8aeb-4a6d-9aca-820c5ad4c3a7@linux.dev \
--to=yonghong.song@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=marc.sune@isovalent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox