linux-kernel - Re: linux-next: Tree for March 8 (BROKEN: arch/x86/kernel/entry_32.S? (Offensive Word Found In Message) Debian's binutils/as?)

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>] [day] [month] [year] [list]

Date:	Thu, 10 Mar 2011 19:57:52 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	<mingo@...e.hu>, <hjl.tools@...il.com>
Cc:	<psomas@...ab.ece.ntua.gr>, <heukelum@...tmail.fm>,
	<sedat.dilek@...il.com>, <sedat.dilek@...glemail.com>,
	<akpm@...ux-foundation.org>, <torvalds@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <linux-next@...r.kernel.org>,
	<hpa@...or.com>
Subject: Re: linux-next: Tree for March 8 (BROKEN:
	 arch/x86/kernel/entry_32.S? (Offensive Word Found In Message)
	 Debian's binutils/as?)

>>> "H.J. Lu"  03/09/11 8:05 PM >>>
>On Wed, Mar 9, 2011 at 8:02 AM, Ingo Molnar  wrote:
>> 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.
>>
>
>There is no way for assembler to know if a bug in input source code is
>"benign" or
>not. For assembler, a bug in input is a bug in input.  Assembly programmers
>should appreciate this assembler change for helping him/her catch such bugs
>in his/her codes.

I can only support Ingo here, particularly since the bug fixed in gas
is very unlikely to affect functionality of anyone's code - it's rather
that debuggability would have suffered. Clearly, as Ingo says, a
warning would have been enough for the next couple of years (in
my opinion, actually forever for that very reason), or at least a
diagnostic that's an error by default and can be turned into a
warning by the user. After all, it's not like the assembler couldn't
continue past that point (it can simply ignore the bogus directive),
but it ought to be only that condition which should cause an error.

Jan

--
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/