Please add -ftrivial-auto-var-init=zero to default build flags

Does Wuninitialized continue working with that flag?

Yes, -Wuninitialized continues to warn, even if they were auto-initialized.

+1 from the Security team on this - looks like a good easy win for security with no overhead or other impact from what I can see.

please not, add it to dpkg instead

Adding it to the compiler means *all* builds benefit, which is the reason this was done on the other options. People build their local projects, newer versions of tools from GitHub, etc etc.

This needs to be in the compiler directly.

doko can you please provide more details on why you think this should be done in dpkg instead of gcc (as we have done for almost all the other hardening options)? As Kees says, adding it to gcc means not only does this benefit Ubuntu archive packages, but also any software which is built on a Ubuntu machine using gcc (ie snaps built by launchpad, packages built on Github using Ubuntu as the CI backend etc) - which is a great benefit IMO.

What advantages do you see in adding this to dpkg rather than gcc?

Oh I have another question: Does this actually turn accessing the uninitialized variables into defined behavior, or can the optimizer still treat it as undefined behavior and thus do whatever it want?

Given that this *is* undefined behavior, turning it into defined behavior with a 0 value would be incredibly useful. It likely also breaks some code written to exploit legacy gcc behaviour, but oh well, that is broken anyway.

I want to note the discussions on clang which recommend pattern instead of zero, as zero hides bugs and creates a new stuff. They did not intend to support zero long term.

https://reviews.llvm.org/D54604
https://reviews.llvm.org/D64742

Status changed to 'Confirmed' because the bug affects multiple users.

FWIW, I recently measured the overhead of -ftrivial-auto-var-init=zero for postgres, and the overhead for *some* workloads could not fairly be described with "nearly no overhead". For read-only OLTP the overhead was in the 1-3% range, but for OLAP style queries it was higher, between 0-20% for the different queries in TPC-H.

Any pathological workloads for specific projects should be analyzed to identify the source of the overhead (which is usually rapid large allocations that are immediately filled, so pre-initialization is not helpful). For these variables, projects can use the "uninitialized" variable attribute to opt out of the initialization.

But as a global option, it should stand.

@andres can this flag be added to CI builds and start to identify codepaths that are hindered by this? And start marking them for uninitialised. Or contribute back to GCC to identify things that are allocated staright away and skip auto-init of those?

@alexmurray, I never said, that it has to be done in dpkg *only*. The bad thing of doing it in the compiler only is that nobody knows about it. Having the change *also* in dpkg lets these new flags appear in the build output, and people can see these compiler options.

On Thu, Jul 06, 2023 at 12:16:46PM -0000, Matthias Klose wrote:
> @alexmurray, I never said, that it has to be done in dpkg *only*. The
> bad thing of doing it in the compiler only is that nobody knows about
> it. Having the change *also* in dpkg lets these new flags appear in the
> build output, and people can see these compiler options.

I can appreciate wanting the flags more visible in build logs, but I think
having them set twice: once loudly, once silently, will make debugging
problems more confusing than if they're only set once, even if silent.

Could we emit our special flags as part of standard output, so they'd be
more visible to developers when troubleshooting?

Thanks

I don't agree on the "more confusing". The command line is printed out by the build system, not gcc. You can see the flags passed to cc1/cc1plus when using the -v option for gcc.