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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 3 Mar 2016 15:04:59 +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:24:34PM +0100, Ingo Molnar wrote:
> > 6 hours of PeterZ time translates to quite a bit of code restructuring overhead to 
> > eliminate false positive warnings...
> 
> I'll file a bugzilla enhancement request for this (with new attribute),
> perhaps we could do it in FRE that is able to see through memory
> stores/loads even in addressable structures in some cases.
> Though, certainly GCC 7 material.

> And, in this particular case it couldn't do anything anyway, because
> the sigfillset call is not inlined, and takes address of a field in the
> structure.  The compiler can't know if it doesn't cast it back to struct
> sigaction and initialize the other fields.

That's true - but I think in the typical case it's a pretty fragile pattern to go 
outside the bounds of a on-stack structure you get passed, so I wouldn't mind a 
(default-disabled) warning for it, even if it generates false positives that have 
to be annotated for the few cases where it's a legitimate technique.

I am 99% sure that a fair number of security critical projects would migrate to 
the usage of such a warning, combined with -Werror. I'm 100% sure that perf would 
migrate to it.

> BTW, valgrind should be able to detect this.

Yes - assuming the uninitialized value gets used. Often they are in rarely used 
code and error paths, only triggered by exploits.

It would be far better if GCC allowed a (non-default) C variant that makes it 
impossible to introduce uninitialized values via on-stack variables. The 
maintenance cost of the false positives is the price paid for that (very valuable) 
guarantee.

Thanks,

	Ingo