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

Bug #1972043 reported by Kees Cook
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
dpkg (Ubuntu)
Status tracked in Kinetic
Kinetic
New
Wishlist
Unassigned
gcc-12 (Ubuntu)
Status tracked in Kinetic
Kinetic
New
Wishlist
Unassigned

Bug Description

Please add "-ftrivial-auto-var-init=zero" for GCC 12 (which is the first release of GCC to provide this flag).

It goes well with the other important security flaw mitigation flags already enabled in Ubuntu for GCC:
https://wiki.ubuntu.com/ToolChain/CompilerFlags

While many variables are initialized (due to -Wuninitialized), there is a blind spot for variables passed by reference, padding, and cases where -Wuninitialized just fails to track it. Universally wiping the variables eliminates nearly the entire class of uninitialized stack variable use (https://cwe.mitre.org/data/definitions/457.html) with nearly no overhead (e.g. any duplicate assignments will already be squashed during dead store elimination, etc).

Revision history for this message
Julian Andres Klode (juliank) wrote :

Does Wuninitialized continue working with that flag?

Tobias Heider (tobhe)
Changed in gcc-12 (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Kees Cook (kees) wrote :

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

Revision history for this message
Alex Murray (alexmurray) wrote :

+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.

tags: added: rls-kk-incoming
Revision history for this message
Matthias Klose (doko) wrote :

please not, add it to dpkg instead

Changed in dpkg (Ubuntu Kinetic):
importance: Undecided → Wishlist
tags: added: fr-2368
tags: removed: rls-kk-incoming
Revision history for this message
Kees Cook (kees) wrote :

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.

Steve Beattie (sbeattie)
tags: added: sec-994
Revision history for this message
Alex Murray (alexmurray) wrote :

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?

Revision history for this message
Julian Andres Klode (juliank) wrote :

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.

Revision history for this message
Julian Andres Klode (juliank) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers