Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt directionflag
From: H. Peter Anvin
Date: Wed Mar 05 2008 - 19:51:28 EST
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.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/