linux-kernel - Re: [PATCH] sdhci: 'scratch' may be used uninitialized

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:	Mon, 6 Oct 2008 08:30:35 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Noonan <steven@...inklabs.net>
Cc:	Adrian Bunk <bunk@...nel.org>, linux-kernel@...r.kernel.org,
	drzeus@...eus.cx
Subject: Re: [PATCH] sdhci: 'scratch' may be used uninitialized


* Steven Noonan <steven@...inklabs.net> wrote:

> On Sun, Oct 5, 2008 at 4:16 PM, Adrian Bunk <bunk@...nel.org> wrote:
> > On Sun, Oct 05, 2008 at 03:53:28PM -0700, Steven Noonan wrote:
> >> On Sun, Oct 5, 2008 at 7:28 AM, Adrian Bunk <bunk@...nel.org> wrote:
> >> > On Wed, Oct 01, 2008 at 01:50:25AM -0700, Steven Noonan wrote:
> >> >> The variable 'scratch' is always initialized before it's used. The
> >> >> conditional which is responsible for initialization of 'scratch' will
> >> >> always evaluate 'true' when the first loop iteration occurs, and thus,
> >> >> it's properly initialized. GCC doesn't see this, of course, so using
> >> >> the uninitialized_var() macro seems to work for silencing this case.
> >> >>
> >> >> Signed-off-by: Steven Noonan <steven@...inklabs.net>
> >> >> ---
> >> >>  drivers/mmc/host/sdhci.c |    2 +-
> >> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >> >>
> >> >> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> >> >> index e3a8133..6257677 100644
> >> >> --- a/drivers/mmc/host/sdhci.c
> >> >> +++ b/drivers/mmc/host/sdhci.c
> >> >> @@ -177,7 +177,7 @@ static void sdhci_read_block_pio(struct sdhci_host *host)
> >> >>  {
> >> >>       unsigned long flags;
> >> >>       size_t blksize, len, chunk;
> >> >> -     u32 scratch;
> >> >> +     u32 uninitialized_var(scratch);
> >> >>...
> >> >
> >> > With which gcc version?
> >> >
> >> > I'm not getting this warning with gcc 4.3, and IMHO it doesn't make
> >> > sense to clutter the source code with such workarounds for older gcc
> >> > versions (we officially support 6 years old compilers, and warning-free
> >> > compilations with all of them are not reasonably possible).
> >> >
> >> > cu
> >> > Adrian
> >>
> >> I've seen it on GCC 4.1 and 4.2. Since lots of distributions still
> >> haven't marked GCC >4.1 stable, it makes sense to me to kill warnings
> >> for GCC 4.1 and above. I don't know of any current distribution
> >> releases using less than GCC 4.1 at the moment.
> >
> > It will clutter our code with these workarounds forever.
> >
> > And due to silencing these false warnings we will no longer get a
> > warning when one of them becomes a real bug.
> >
> > Working on the remaining warnings that are visible with gcc 4.3 is a
> > worthwhile goal, but I see no point for silencing some warnings that
> > only occur with older gcc versions (especially as long as warnings
> > that are present with all gcc versions stay unfixed).
> >
> I feel like there's a logical fallacy here. Sure, we can fix GCC 4.3
> warnings, but what about when GCC 4.3 becomes an "old version"?
> uninitialized_var and other such workarounds will still exist in the
> code. It seems like the logical progression of your argument should be
> to never fix false warnings.

Correct. Would you be interested in sending a patch for a (default-off) 
debug feature that allows the disabling of all the gcc annotations? That 
way we can do regular sweeps to determine whether old annotations are 
still relevant on latest and greatest GCC.

Something like CONFIG_CC_DEBUG_ALLOW_WARNINGS=y in lib/Kconfig.debug, 
then use that to #ifdef the uninitialized_var() 
include/linux/compiler-gcc[34].h?

Also, please try Alan's suggestion as well: does the __attribute_ 
((unused)) trick work equally well? If yes then please introduce a 
__annotate_initialized tag instead of the weird-looking 
uninitialized_var() construct.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/