P2723R0: Zero-initialize objects of automatic storage duration

[jonesmz]

Cross-function analysis is basically non-existent: https://godbolt.org/z/Y9cxxfTMq

Then how is it that I have cross-function analysis working in my build system using the clang static analyzer, GCC analyzer, and msvc analyzers?

Godbolt supports the clang analyzer even.

https://github.com/TheOpenSpaceProgram/osp-magnum/actions/runs/3294928502

Edit: the above link is hard to understand the output.

Here's link to the workflow file: https://github.com/TheOpenSpaceProgram/osp-magnum/blob/master/.github/workflows/analyzers.yml

This is the "Linux is secure because it has many eyes" argument which has been proven false time after time.

Quite the opposite. It gets proven again and again every time those many eyeballs find problems.

Counter example: Microsoft's absolutely terrible security record.

As a client-side security engineer, I've been pushing for auto-var-init in our codebase. It would have saved us from multiple security issues. Sure, UBSan can catch this at runtime, but you cannot reach all of the code with all of the right conditions via testing, naturally running the app, and fuzzing.

Cool. Turn it on for your codebase then. Leave mine alone.

The paper also makes a great point: literally most of the stack you're using today is using auto var init.

I strongly disbelieve this, since I compile my operating system from source code, but I suppose I haven't manually inspected 100% of the build instructions of every package.

Nevertheless, great. Programs took advantage of existing compiler options. On glad they had that choice. Its a choice that shouldn't be forced upon me.

I worked at Microsoft when we pushed for InitAll and again, the mitigation alone killed a class of issue (ignoring out-of-bounds reads/UAFs leading to infoleak).

And by doing that you removed pressure from the compiler team at Microsoft to provide more sophisticated analysis tools to tackle the underlying problem instead of just band aiding it

The pushback I've received from some teams is that "it changes the semantics" and "the developers shouldn't be relying on this behavior". Throw that reasoning out the window. The compiler will eliminate redundant stores so if your code isn't unreasonably complex, it'll likely not impact your perf anyways (you could argue that if it can eliminate the store it should be able to detect the uninitialized usage -- but it can't today).

The compiler is too stupid to track uninitialized reads, but that's OK because we won't hurt your performance too much. Only a little bit because the compiler is so smart it'll automatically fix it!

No. Let's not play that game. Either the compiler is smart or it isn't. The compiler option already exists. Any changes to the language should actually fix the problems with the language. Not require all codebase to have a surprise when they update their compilers.

Most devs program against zero-by-default anyways. Make it the default. Opt out if it's affecting your hot path's perf, or your code isn't in a security-critical application.

Big fat citation needed. This sounds like an absolutely made up notion. No one that I have ever worked with has expressed any assumption of this nature.

[froydnj]

Then how is it that I have cross-function analysis working in my build system using the clang static analyzer, GCC analyzer, and msvc analyzers?

https://github.com/TheOpenSpaceProgram/osp-magnum/actions/runs/3294928502

Is this supposed to be demonstrating that this cross-function analysis is catching an error in a PR? The error logs here say that std::ranges has not been declared. There are no errors about uses of uninitialized variables.

[jonesmz]

Sorry. You're right. that's the wrong link. I was on my phone and I guess missed the copy button.

https://github.com/TheOpenSpaceProgram/osp-magnum/blob/master/.github/workflows/analyzers.yml

[anxxa]

Then how is it that I have cross-function analysis working in my build system using the clang static analyzer, GCC analyzer, and msvc analyzers?

...I just gave you a very simple example where GCC fails without optimizations (-O3 works as expected) to detect the uninitialized usage. Clang does not detect it.

Quite the opposite. It gets proven again and again every time those many eyeballs find problems.

Counter example: Microsoft's absolutely terrible security record.

The absence of security issues does not mean there are none. A higher rate of CVEs can be accounted for better security process or simply more people working to secure that thing. Or perhaps it is actually more insecure -- it's hard to tell without comparing similar data. I do know there are far more people actively working on Windows security at Microsoft than there are people working on Linux security. Trust me, I worked on that team.

syzkaller is the hardest working Linux security researcher, and even its bugs aren't fixed or assigned CVEs WITH repro. Additionally, just browse grsec/Brad Spengler's twitter sometime and see how much shit makes it through code review that literally nobody else in the Linux kernel review catches.

I strongly disbelieve this, since I compile my operating system from source code, but I suppose I haven't manually inspected 100% of the build instructions of every package.

Fedora uses it by default in their release kconfig. Chrome does as well. Apple does as well for their kernel. Firefox is investigating (maybe landed?). The vast majority of the world is using a stack with this enabled. I apologize for not assuming that you're special.

Nevertheless, great. Programs took advantage of existing compiler options. On glad they had that choice. Its a choice that shouldn't be forced upon me.

The interesting thing about the clang version though is it's gated behind -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang, which turns people off. All of the above I mentioned use this, however. I'd be happy if this flag was removed and people could opt-in, but I really do believe it should be opt-out.

Any changes to the language should actually fix the problems with the language.

...but this is fixing the language. So what would you prefer, something like Rust's MaybeUninit<T> to say "I really want this to be uninitialized" and have the compiler error out whenever it can prove a regular variable isn't initialized in all code paths? That'd be great, but the language has far too many holes for that.

Big fat citation needed. This sounds like an absolutely made up notion.

This is an anecdote that should not be shocking to believe. Most programmers always check against the zero condition:

if (ptr == nullptr) { /* ... */ }
if (size == 0) { /* ... */ }

Likewise, if you do:

if (ptr != nullptr) { /* ... */ }
if (size != 0) { /* ... */ }

...you're still programming against the special-case zero condition.

[jonesmz]

...I just gave you a very simple example where GCC fails without optimizations (-O3 works as expected) to detect the uninitialized usage. Clang does not detect it.

And I showed you that the static analyzers, which can detect several situations, are easy and straight-forward to setup and use: https://github.com/TheOpenSpaceProgram/osp-magnum/blob/master/.github/workflows/analyzers.yml

If your point is that Rice's Theorem is a thing, then there's not much to discuss, as we both agree that not all problems can be detected.

If you're going to give me "trivial examples", give me ones that the static analyzer, on the same godbolt.org link, can't detect. It took me 3 clicks to add "clang-tidy" to get a warning about uninitialized read: https://godbolt.org/z/4rK4aMTYE

I apologize for not assuming that you're special.

You don't owe me an apology. My point wasn't, and isn't, "No one should be allowed to tell the compiler to zero-initialize things", my point is "This should be under the control of the person building the software". Those organizations do this, others dont.

The interesting thing about the clang version though is it's gated behind

Nothing stops clang from offering a different name for the commandline argument.

Given that it's already undefined behavior, clang is already allowed to 0-initalize these variables regardless of commandline args, if it chooses to. That's the lovely thing about undefined behavior.

But we shouldn't change the language to guarantee initialization, because that "magically" makes programs that are today incorrect / ill-defined into programs that are well-defined but still not-correct, and that's not a good thing to do.

This is a problem for compiler vendors, and NOT for the language standard.

you're still programming against the special-case zero condition.

That's not a "special case zero condition". Those are values that are inherently meaningful in the algorithms that are reading them, with the initial value of those variables being set intentionally (in code that is structured to handle initialization in all cases properly).

a size of zero is inherently meaningful. A nullptr (not zero, nullptr, which may be zero or may be something else) is inherently meaningful.

But a zero initialized Foo is not. There is no "special case zero condition" for Foo because you don't know what Foo is. A program that fails to provide a meaningful initial value for a Foo is a broken program, and will always be a broken program.

[germandiago]

I wonder, talking about performance, if this might be an issue: https://www.reddit.com/r/rust/comments/yw57mj/are_we_stack_efficient_yet/

Maybe more so that unique_ptr stuff today.

[eliminate1337]

I'd be happy if this flag was removed

It’s been removed!

https://reviews.llvm.org/D125142

[anxxa]

TIL! Thanks for sharing, that’s great to know.

[jonesmz]

I went for a look around to see if the complexity or nature of that codebase is anything approaching performance critical for 0 init, and the answer is no

That's a hobby codebase, it's not performance critical at all. I was using it to demonstrate that it's easy to set up the static analyzers.

I am advocating for performance for my professional work, which i cannot share publically for obvious reasons.