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

[Chris Lattner]

On Mar 5, 2008, at 4:47 PM, H. Peter Anvin wrote:

> Chris Lattner wrote:
>>>>> Richard Guenther wrote:
>>>>>> We didn't yet run into this issue and build openSUSE with 4.3  
>>>>>> since more
>>>>>> than
>>>>>> three month.
>>>>>
>>>>> Well, how often do you take a trap inside an overlapping  
>>>>> memmove()?
>>>>
>>>> How hard is it to change the kernel signal entry path from  
>>>> "pushf" to
>>>> "pushf;cld"?  Problem solved, no?
>>>
>>> The problem is with old kernels, which by definition stay unfixed.
>> My impression was that the problem occurs in GCC compiled code in  
>> the kernel itself, not in user space:
>
> That's wrong.
>
> The issue is that the kernel is entered (due to a trap, interrupt or  
> whatever) and the state is saved.  The kernel decides to revector  
> userspace to a signal handler.  The kernel modifies the userspace  
> state to do so, but doesn't set DF=0.
>
> Upon return to userspace, the modified state kicks in.  Thus the  
> signal handler is entered with DF from userspace at trap time, not  
> DF=0.
>
> So it's an asynchronous state leak from one piece of userspace to  
> another.

Fine, it can happen either way.  In either case, the distro vendor  
should fix the the signal handler in the kernels they distribute.  If  
you don't do that, you are still leaking information from one piece of  
user space code to another, you're just papering over it in a horrible  
way :)

GCC defines the direction flag to be clear before inline asm.  
Enforcing the semantics you propose would require issuing a cld before  
every inline asm, not just before every string operation.

-Chris