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]
Message-Id: <4D792D41020000780006C482@vpn.id2.novell.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ