[LSF/MM/BPF TOPIC] Uninitialized Variable In BPF Programs

[LSF/MM/BPF TOPIC] Uninitialized Variable In BPF Programs

[Yonghong Song]

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

Re: [LSF/MM/BPF TOPIC] Uninitialized Variable In BPF Programs

[Alexei Starovoitov]

On Tue, Jan 28, 2025 at 1:42 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>
> 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
>

Compilers maliciously making advantage of unint vars is a tip
of the iceberg. They do equally nasty "optimizations" for all
undefined things. It's a real issue for all backends.
We can experiment -ftrivial-auto-var-init=zero and/or
introduce similar workarounds.
The problem is clearly not limited to bpf.

But the main concern is that this discussion cannot happen without
llvm and gcc involvement, but only gcc folks might be present at lsfmm.

We also still have an issue of missing suffixes when llvm optimizes
funcs, compilers doing things that messes with the verifier,
gcc is still missing decl_tag support, etc.

I suggest to fold the status update (not a discussion) into one
slot that will cover all outstanding gcc and llvm issues.

Re: [LSF/MM/BPF TOPIC] Uninitialized Variable In BPF Programs

[Yonghong Song]

On 1/29/25 4:53 PM, Alexei Starovoitov wrote:
> On Tue, Jan 28, 2025 at 1:42 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>> 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
>>
> Compilers maliciously making advantage of unint vars is a tip
> of the iceberg. They do equally nasty "optimizations" for all
> undefined things. It's a real issue for all backends.
> We can experiment -ftrivial-auto-var-init=zero and/or
> introduce similar workarounds.
> The problem is clearly not limited to bpf.
>
> But the main concern is that this discussion cannot happen without
> llvm and gcc involvement, but only gcc folks might be present at lsfmm.
>
> We also still have an issue of missing suffixes when llvm optimizes
> funcs, compilers doing things that messes with the verifier,
> gcc is still missing decl_tag support, etc.
>
> I suggest to fold the status update (not a discussion) into one
> slot that will cover all outstanding gcc and llvm issues.

Good point. Let us discuss the progress of various compiler
related issues at once. Will coordinate with Jose etc.