linux-kernel - Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

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:	Thu, 06 Mar 2008 10:57:11 -0500
From:	Robert Dewar <dewar@...core.com>
To:	NightStrike <nightstrike@...il.com>
CC:	Olivier Galibert <galibert@...ox.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Chris Lattner <clattner@...le.com>,
	Michael Matz <matz@...e.de>,
	Richard Guenther <richard.guenther@...il.com>,
	Joe Buck <Joe.Buck@...opsys.com>, Jan Hubicka <hubicka@....cz>,
	Aurelien Jarno <aurelien@...el32.net>,
	linux-kernel@...r.kernel.org, gcc@....gnu.org
Subject: Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction
 flag

NightStrike wrote:
> On 3/6/08, Olivier Galibert <galibert@...ox.com> wrote:
>> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>>> It's a kernel bug, and it needs to be fixed.
>> I'm not convinced.  It's been that way for 15 years, it's that way in
>> the BSD kernels, at that point it's a feature.  The bug is in the
>> documentation, nowhere else.  And in gcc for blindly trusting the
>> documentation.
> 
> The issue should not be evaluated as: "It's always been that way,
> therefore, it's right."  Instead, it should be: "What's the right way
> to do it?"
> 
> You don't just change documentation because no existing code meets the
> requirement -- UNLESS -- the non-conforming code is actually the right
> way to do things.

Sounds good, but has almost nothing to do with the real world. I 
remember back in Realia COBOL days, we had to carefully copy IBM
bugs in the IBM mainframe COBOL compiler. Doing things right and
fixing the bug would have been the right thing to do, but no one
would have used Realia COBOL :-)

Another story, the sad story of the intel chip (I think it was
the 80188) where Intel made use of Int 5, which was documented
as reserved. Unfortunately, Microsoft/IBM had used this for
print screen or some such. Intel was absolutely right that
their documentation was clear and it was wrong to have used
these interrupts .. but the result was a warehouse of unused
chips.
--
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/