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

[Yonghong Song <yonghong.song@linux.dev>]

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.