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]
Message-ID: <20110309160241.GC31249@elte.hu>
Date:	Wed, 9 Mar 2011 17:02:41 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"H.J. Lu" <hjl.tools@...il.com>
Cc:	sedat.dilek@...il.com, Sedat Dilek <sedat.dilek@...glemail.com>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	linux-next <linux-next@...r.kernel.org>,
	psomas@...ab.ece.ntua.gr, Jan Beulich <JBeulich@...ell.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: linux-next: Tree for March 8 (BROKEN:
 arch/x86/kernel/entry_32.S? Debian's binutils/as?)


* H.J. Lu <hjl.tools@...il.com> wrote:

> > Yes, the .size directive not matching up is technically a bug, but it was not 
> > checked by binutils before, for *years* - and you cannot just flip a switch and 
> > break who knows how much code.
> >
> > You need to at least emit a warning for some time to give people a *chance* to 
> > fix bugs - not just stuff an incompatible binutils down their throat and break 
> > the kernel build for thousands of commits and break bisection.
> 
> If kernel doesn't use/need symbol size, don't put it in assembly code.

What does that have to do with the question i raised: that of binutils backwards 
(in)compatibility to be able to build the Linux kernel?

> > This binutils change is breaking numerous upstream kernel builds (and is making 
> > bisection with new binutils impossible) for no particular good reason: binutils 
> > was capable to figure out the symbol name before this change.
> 
> That is totally false. The old assembler just generates incorrect size and It 
> couldn't read the programmer's mind to find the correct symbol name.

Still it didnt make the kernel not build and it did not make the kernel not boot. It 
at most confused some ELF symbol table - which the kernel does not need.

So all i'm trying to point out to you is that you appear to be seeing the world in a 
very binary way: 'broken' versus 'correct' and that it can be rather harmful if you 
project that binary view on the real world that in reality is not binary but is 
shades of grey.

You are turning a benign ELF symbol table detail (that does not affect the kernel's 
ability to boot/work) into a hard build breakage and bisection barrier, covering 
hundreds of commits.

I'm not denying that it's buggy code - I'm just asking you to *PLEASE* at minimum 
acknowledge that surprise flag days that turn a before-benign condition into a fatal 
build failure suck to everyone else outside your own little universe.

Thanks,

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ