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]
Message-ID: <alpine.LFD.2.01.0907200848530.13838@localhost.localdomain>
Date:	Mon, 20 Jul 2009 09:01:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Greg KH <gregkh@...e.de>
cc:	Krzysztof Oledzki <olel@....pl>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, stable@...nel.org,
	lwn@....net
Subject: Re: Linux 2.6.27.27



On Mon, 20 Jul 2009, Greg KH wrote:
>
> > >Linus Torvalds (1):
> > >      Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x
> > 
> > I'm very sorry to say that but 2.6.27.27 compiled with gcc-4.2.4
> > hangs during boot and it is caused by this fix.
> > 
> > I extended http://bugzilla.kernel.org/show_bug.cgi?id=13012 with
> > additional info & .config.
> 
> Wierd.  Linus, any thoughts?  Do we need to check the version of the
> compiler that we are using before turning that option off?

Dang. That was what we hoped to avoid by not using -fwrapv - we didn't 
know which compilers were buggy, although it _looked_ like just 4.1.x (I 
have some dim memory of somebody suspecting a 4.2.x version too, but that 
may have been just a "we know it should only be needed in 4.3.x, so maybe 
we shouldn't use it in 4.2.x either").

But it looks like the "buggy window" for -fno-strict-overflow is 
potentially even _larger_ than it ever was with -fwrapv. And I suspect 
that in both cases the real problem is that almost nobody ever uses either 
optimization flag, so coverage is way way smaller.

For now, I suspect we need to do something like this: go back to -fwrapv 
(because it has gotten more testing), but limit it to 4.2.x and newer.

However, it would be really good to figure out _why_ it breaks. It's 
probably some specific configuration issue in addition to the particular 
kernel vesion (and maybe it even needs some particular hardware to show 
the bug - ie a specific driver that triggers it or whatever).

			Linus

---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 79957b3..47a3a1a 100644
--- a/Makefile
+++ b/Makefile
@@ -566,7 +566,7 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
 KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
 
 # disable invalid "can't wrap" optimizations for signed / pointers
-KBUILD_CFLAGS	+= $(call cc-option,-fno-strict-overflow)
+KBUILD_CFLAGS	+= $(call cc-ifversion, -ge, 0402, -fwrapv)
 
 # revert to pre-gcc-4.4 behaviour of .eh_frame
 KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ