Hi,
On Thu, 2022-01-20 at 17:56 -0500, Marek Polacek wrote:
On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
> On 1/11/22 13:00, Steve Grubb wrote:
> > Reading through the GCC 12 changes, there is a significant new feature to GCC
> > that would appear to be useful for security. There is a new:
> >
> > -ftrivial-auto-var-init=zero
> >
> > flag that initializes all stack variables to zero. Zero being a nice safe
> > value that makes programs crash instead of being exploitable.
> >
> > Are there plans to enable this flag so that all applications, but more
> > importantly the kernel, are hardened against uninitialized stack variables?
> > This is one of the major classes of security bugs that could potentially be
> > eliminated during this mass rebuild.
>
> There are currently no plans that I am aware of that involve turning on
> '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing
Jakub
> and Marek to comment.
Also not aware of any plans to always enable it.
> It is something that should be discussed, turned on in Rawhide first,
> and likely via redhat-rpm-config default flags first, and then we should
> fix any fallout.
>
> I'd only be comfortable if we did it early and worked through the consequences.
> So it could be something to discuss for F37.
Right. It reminds me of MALLOC_PERTURB_, but for automatic variables.
Obviously it's always important to measure its slowdown (maybe run a SPEC
benchmark) / compile time / stack usage. Some of it has been done:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html
but that was an early version of the patch. Still, it seems like it'd be
acceptable.
It's a new feature, only present in GCC 12 (which hasn't been released as of
now), so I think it needs more testing before it could be (considered to be)
enabled by default.
A good thing is that it doesn't suppress the -Wuninitialized warning so
you still get a chance to fix your bugs. It also comes with an attribute
to keep variables uninitialized even when the options is turned on.
Note that it does make it impossible for valgrind memcheck to track use
of uninitialized (stack) values because it will believe they have been
initialized with zero in any code that is build with this flag, and it
will assume that zero is a valid value.
Obviously as a valgrind hacker I am biased, believing lots of people
run valgrind on production code. So I do think that makes it harder to
find real security issues. Now the code will just appear to work using
a possibly bogus value of zero instead of valgrind memcheck pointing
out where and why you are using an uninitialized value.
Cheers,
Mark