linux-kernel - Re: Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Mar 2016 15:40:26 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Jakub Jelinek <jakub@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Colin King <colin.king@...onical.com>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Richard Henderson <rth@...ddle.net>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Q: why didn't GCC warn about this uninitialized variable? (was:
 Re: [PATCH] perf tests: initialize sa.sa_flags)


* Jakub Jelinek <jakub@...hat.com> wrote:

> On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote:
> > I tried to distill a testcase out of it, and the following silly hack seems to 
> > trigger it:
> 
> ...
> 
> This is a known issue, which we don't have a solution for yet.
> The thing is, GCC has 2 uninitialized warning passes, one is done
> very early, on fairly unoptimized code, which warns for -O and above
> only about must be uninitialized cases in code that is executed
> unconditionally (if the containing function is executed, and doesn't
> have PHI handling code), and then a very late uninitialized pass,
> that warns also about maybe-uninitialized cases, has predicate aware
> handling in it, etc.; but this warns only about the cases where the
> uninitialized uses survived through the optimizations until that phase.
> In the testcase, the conditional uninitialized uses got optimized away,
> passes seeing that you can get alt_idx initialized say to 2 from one branch
> and uninitialized from another one just optimize it into 2.
> Warning right away at that spot when the optimization pass performs this
> might not be the right thing, as it could warn for stuff in dead code,
> or couldn't be backed up by the predicate aware uninit analysis which is
> costly and couldn't be done in every pass that just happens to optimize away
> some uninitialized stuff.  Not to mention that it doesn't have to be always
> even so obvious to the optimizing pass.  Say, when computing value ranges,
> the uninitialized uses should be ignored, because they can't be used in
> valid paths, so if say you have value range [2, 34] from one branch and
> uninitialized use from another branch, the resulting value range will be
> [2, 34].  Then later on, you just optimize based on this value range and
> perhaps the uninitialized use will go away because of that.
> We could handle the uninitialized uses pessimistically, by not optimizing
> PHI <initialized_2, uninited_3(D)> into just initialized_2, etc., by
> considering uninitialized uses as VARYING ([min, max] range) rather than
> something that doesn't happen, etc., and then the late uninitialized pass
> would warn here.  But then we'd trade the warning for less optimized code.
> GCC is primarily an optimizing compiler, rather than static analyzer, so
> that is why GCC chooses to do what it does.  Do you want us introduce
> -Ow mode, which will prefer warnings over generated code quality?
> 
> BTW, as for false positives and new warnings, my experience is that in the 
> kernel generally such warnings are just disabled, even if they helped discover 
> severe errors in other packages.

That's true to a certain degree, especially when the warning is about something 
that can often be used in 'healthy' patterns, and if the workaround for the 
warning generates _worse_ code.

One such example was -Wtype-limits.

We tend to disable new GCC warnings if they got enabled indiscriminately, and if 
they trigger many false positives that get worked around in the wrong fashion, 
with no sane way to write the code to avoid the warning.

Note that the usage in my suggested usecase would be different: we'd not enable 
the warning by default (a separate kernel config option would enable it, default 
disabled), and we'd not enable it for all C files, but would opt in gradually.

This would remove much of the pressure to hack around annoying warnings in default 
kernel builds. For example we had and have a _lot_ of false positive warnings from 
Sparse for example, still we gradually eliminated them, because Sparse checking 
builds are opt-in.

Thanks,

	Ingo