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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
