public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: "Måns Rullgård" <mans@mansr.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Colin King <colin.king@canonical.com>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, Richard Henderson <rth@twiddle.net>,
	Jakub Jelinek <jakub@redhat.com>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: Q: why didn't GCC warn about this uninitialized variable?
Date: Thu, 3 Mar 2016 13:43:19 +0100	[thread overview]
Message-ID: <20160303124319.GA8781@gmail.com> (raw)
In-Reply-To: <yw1xegbr7neo.fsf@unicorn.mansr.com>


* Måns Rullgård <mans@mansr.com> wrote:

> > So the source of the bug was:
> >
> >         struct sigaction sa;
> >
> > 	...
> >
> >         sigfillset(&sa.sa_mask);
> >         sa.sa_sigaction = segfault_handler;
> >         sigaction(SIGSEGV, &sa, NULL);
> >
> > ... which uninitialized sa.sa_flags field GCC merrily accepted as
> > proper C code, despite us turning on essentially _all_ GCC warnings
> > for the perf build that exist under the sun:
> >
> >  gcc -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k \
> >     -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs \
> >     -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls \
> >     -Wshadow -Wstrict-aliasing=3 -Wstrict-prototypes -Wswitch-default -Wswitch-enum \
> >     -Wundef -Wwrite-strings -Wformat \
> >     -Werror -O6 -fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra -std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2
> >
> > This is a _trivial_ uninitialized variable bug, yet GCC never warned
> > about it.  Why?
> >
> > People build perf with a wide range of GCC versions, from old ones to
> > trunk. I cannot believe it that none of those GCC versions warned
> > about this trivial looking bug!
> >
> > And yes, I know that unitialized structures on the stack are valid C
> > code, yet it's one of the most fragile aspects of C and it was the
> > source of countless security holes in the past...
> 
> Passing a pointer to an uninitialised object is typically not warned about since 
> the purpose of the call might be to initialise it in the first place.  Now the 
> second argument of sigaction() is a pointer to const, so the compiler should be 
> able to see that this isn't the case.
> 
> Maybe it's not warning because some fields in the struct are initialised and the 
> function, as far as the compiler knows, might only be accessing those.  (There's 
> certainly code out there using that pattern.)  If this is the case here, a flag 
> to warn unless the object is fully initialised would be useful to catch bugs 
> like this.

So it would be absolutely fantastic if one of these solutions existed on GCC:

 - emit a warning if a structure is passed around uninitialized. A new GCC
   __attribute__((struct_fully_initialized)) could be used to annotate extern
   function arguments which fully initialize input arguments.

   (I'd personally migrate both tools/perf and kernel side code to use it, module
    by module.)

 - or memset() to zero all on-stack structures that GCC cannot prove are
   initialized fully.

The first solution takes extra work on the source level, the latter takes extra 
runtime profiling to find where the extra memset()s matter to performance. Any of 
these would be fantastic tools for C robustness and security.

Thanks,

	Ingo

  reply	other threads:[~2016-03-03 12:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-02 12:55 [PATCH] perf tests: initialize sa.sa_flags Colin King
2016-03-02 12:59 ` Peter Zijlstra
2016-03-02 13:03   ` Arnaldo Carvalho de Melo
2016-03-02 13:21     ` Peter Zijlstra
2016-03-02 13:23       ` Arnaldo Carvalho de Melo
2016-03-03 12:19         ` Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags) Ingo Molnar
2016-03-03 12:25           ` Q: why didn't GCC warn about this uninitialized variable? Colin Ian King
2016-03-03 12:31           ` Måns Rullgård
2016-03-03 12:43             ` Ingo Molnar [this message]
2016-03-03 12:49               ` Joe Perches
2016-03-03 12:55           ` Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags) Jakub Jelinek
2016-03-03 13:24             ` Ingo Molnar
2016-03-03 13:46               ` Jakub Jelinek
2016-03-03 14:04                 ` Ingo Molnar
2016-03-03 13:47               ` Ingo Molnar
2016-03-03 14:19                 ` Jakub Jelinek
2016-03-03 14:40                   ` Ingo Molnar
2016-03-03 14:53                   ` Ingo Molnar
2016-03-03 15:04                     ` Ingo Molnar
2016-03-02 13:02 ` [PATCH] perf tests: initialize sa.sa_flags Arnaldo Carvalho de Melo
2016-03-05  8:20 ` [tip:perf/core] perf tests: Initialize sa.sa_flags tip-bot for Colin Ian King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160303124319.GA8781@gmail.com \
    --to=mingo@kernel.org \
    --cc=acme@kernel.org \
    --cc=colin.king@canonical.com \
    --cc=dan.carpenter@oracle.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox