linux-kernel - Re: 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]

Message-ID: <47CFBF28.4060309@redhat.com>
Date:	Thu, 06 Mar 2008 09:53:44 +0000
From:	Andrew Haley <aph@...hat.com>
To:	Aurelien Jarno <aurelien@...el32.net>
CC:	"H. Peter Anvin" <hpa@...or.com>, Michael Matz <matz@...e.de>,
	Joe Buck <Joe.Buck@...opsys.COM>, linux-kernel@...r.kernel.org,
	gcc@....gnu.org
Subject: Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Aurelien Jarno wrote:
> H. Peter Anvin a écrit :
>> Michael Matz wrote:
>>>
>>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>>
>>>>> So I think gcc at least needs an *option* to revert to the old
>>>>> behavior,
>>>>> and there's a good argument to make it the default for now, at least
>>>>> for
>>>>> x86/x86-64 on Linux.
>>>> And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.0,
>>>> they have the same behaviour as Linux, that is they don't clear DF
>>>> before calling the signal handler.
>>> Sigh.  We could perhaps insert a cld for all functions which can be
>>> recognized as possible signal handlers and call other unknown or
>>> string functions.  But it's probably even faster to emit cld in front
>>> of the inline copies of mem functions again :-(
>>>
>> Well, there is a (slight) difference: you know that a called function
>> will not clobber your DF state; it's only the entry condition which is
>> imprecise.
>>
>> The best would be if this could be controlled by a flag, which we can
>> flip once kernel fixes has been around for long enough.
> 
> I have to agree there. Whatever the decision that gcc will take,
> distributions will reenable the old behaviour for some time for to allow
> upgrades from a previous version.
> 
> Providing a flag to switch the behaviour (whatever the default
> behaviour) will help a lot.

I think you've got the timescales wrong.  Anything that we do now in gcc will
take a while to percolate to the Linux distributions.  It is far quicker for
those distributions to fix their kernels as fast as possible.  By the time any
gcc fix is in the world all of this will be over.

I suppose one could apply the precautionary principle, but those systems that
don't update kernels won't update gcc either, so the solution won't work.

Andrew.

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