* Linux doesn't follow x86/x86-64 ABI wrt direction flag @ 2008-03-05 15:30 Aurelien Jarno 2008-03-05 16:00 ` H. Peter Anvin ` (2 more replies) 0 siblings, 3 replies; 98+ messages in thread From: Aurelien Jarno @ 2008-03-05 15:30 UTC (permalink / raw) To: linux-kernel; +Cc: gcc Hi all, Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 ABI and the direction flag, that is it now assumes that the direction flag is cleared at the entry of a function and it doesn't clear once more if needed. This causes some problems with the Linux kernel which does not clear the direction flag when entering a signal handler. The small code below (for x86-64) demonstrates that. If the signal handler is using code that need the direction flag cleared (for example bzero() or memset()), the code is incorrectly executed. I guess this has to be fixed on the kernel side, but also gcc-4.3 could revert back to the old behaviour, that is clearing the direction flag when entering a routine that touches it until most people are running a fixed kernel. Kind regards, Aurelien [1] http://gcc.gnu.org/gcc-4.3/changes.html #include <stdint.h> #include <stdlib.h> #include <stdio.h> #include <signal.h> void handler(int signal) { uint64_t rflags; asm volatile("pushfq ; popq %0" : "=g" (rflags)); if (rflags & (1 << 10)) printf("DF = 1\n"); else printf("DF = 0\n"); } int main() { signal(SIGUSR1, handler); while(1) { asm volatile("std\r\n"); } return 0; } -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 15:30 Linux doesn't follow x86/x86-64 ABI wrt direction flag Aurelien Jarno @ 2008-03-05 16:00 ` H. Peter Anvin 2008-03-05 19:58 ` Joe Buck 2008-03-05 16:56 ` H.J. Lu 2008-03-05 18:14 ` [PATCH] x86: Clear DF before calling signal handler Aurelien Jarno 2 siblings, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 16:00 UTC (permalink / raw) To: Aurelien Jarno, linux-kernel, gcc Aurelien Jarno wrote: > Hi all, > > Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 > ABI and the direction flag, that is it now assumes that the direction > flag is cleared at the entry of a function and it doesn't clear once > more if needed. > > This causes some problems with the Linux kernel which does not clear > the direction flag when entering a signal handler. The small code below > (for x86-64) demonstrates that. > > If the signal handler is using code that need the direction flag cleared > (for example bzero() or memset()), the code is incorrectly executed. > > I guess this has to be fixed on the kernel side, but also gcc-4.3 could > revert back to the old behaviour, that is clearing the direction flag > when entering a routine that touches it until most people are running a > fixed kernel. > Linux should definitely follow the ABI. This is a bug, and a pretty serious such. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 16:00 ` H. Peter Anvin @ 2008-03-05 19:58 ` Joe Buck 2008-03-05 20:23 ` Aurelien Jarno 0 siblings, 1 reply; 98+ messages in thread From: Joe Buck @ 2008-03-05 19:58 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Aurelien Jarno, linux-kernel, gcc Aurelien Jarno wrote: > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 > >ABI and the direction flag, that is it now assumes that the direction > >flag is cleared at the entry of a function and it doesn't clear once > >more if needed. > >... > >I guess this has to be fixed on the kernel side, but also gcc-4.3 could > >revert back to the old behaviour, that is clearing the direction flag > >when entering a routine that touches it until most people are running a > >fixed kernel. On Wed, Mar 05, 2008 at 08:00:42AM -0800, H. Peter Anvin wrote: > Linux should definitely follow the ABI. This is a bug, and a pretty > serious such. Unfortunately, there are a lot of kernels out there already with this problem, and the symptoms are likely to be subtle. So even if it is true that it is the kernel that is "in the wrong", I think we still are going to need to give users a workaround from the gcc side as well. 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. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 19:58 ` Joe Buck @ 2008-03-05 20:23 ` Aurelien Jarno 2008-03-05 20:38 ` Michael Matz 2008-03-06 9:45 ` Mikael Pettersson 0 siblings, 2 replies; 98+ messages in thread From: Aurelien Jarno @ 2008-03-05 20:23 UTC (permalink / raw) To: Joe Buck; +Cc: H. Peter Anvin, linux-kernel, gcc On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote: > > Aurelien Jarno wrote: > > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 > > >ABI and the direction flag, that is it now assumes that the direction > > >flag is cleared at the entry of a function and it doesn't clear once > > >more if needed. > > >... > > >I guess this has to be fixed on the kernel side, but also gcc-4.3 could > > >revert back to the old behaviour, that is clearing the direction flag > > >when entering a routine that touches it until most people are running a > > >fixed kernel. > > On Wed, Mar 05, 2008 at 08:00:42AM -0800, H. Peter Anvin wrote: > > Linux should definitely follow the ABI. This is a bug, and a pretty > > serious such. > > Unfortunately, there are a lot of kernels out there already with this > problem, and the symptoms are likely to be subtle. So even if it is true > that it is the kernel that is "in the wrong", I think we still are going > to need to give users a workaround from the gcc side as well. > > 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. I also tested Hurd, and it causes a kernel crash. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:23 ` Aurelien Jarno @ 2008-03-05 20:38 ` Michael Matz 2008-03-05 20:42 ` Joe Buck 2008-03-05 20:44 ` H. Peter Anvin 2008-03-06 9:45 ` Mikael Pettersson 1 sibling, 2 replies; 98+ messages in thread From: Michael Matz @ 2008-03-05 20:38 UTC (permalink / raw) To: Aurelien Jarno; +Cc: Joe Buck, H. Peter Anvin, linux-kernel, gcc Hi, 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 :-( Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:38 ` Michael Matz @ 2008-03-05 20:42 ` Joe Buck 2008-03-05 20:49 ` Jan Hubicka 2008-03-05 20:44 ` H. Peter Anvin 1 sibling, 1 reply; 98+ messages in thread From: Joe Buck @ 2008-03-05 20:42 UTC (permalink / raw) To: Michael Matz; +Cc: Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote: > Hi, > > 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 :-( Yes, if there are four kernels that get it "wrong", that effectively means that the ABI document doesn't describe reality and gcc has to adjust. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:42 ` Joe Buck @ 2008-03-05 20:49 ` Jan Hubicka 2008-03-05 21:02 ` Michael Matz 2008-03-05 21:07 ` H. Peter Anvin 0 siblings, 2 replies; 98+ messages in thread From: Jan Hubicka @ 2008-03-05 20:49 UTC (permalink / raw) To: Joe Buck; +Cc: Michael Matz, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc > On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote: > > Hi, > > > > 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 :-( > > Yes, if there are four kernels that get it "wrong", that effectively means > that the ABI document doesn't describe reality and gcc has to adjust. Kernels almost never follow ABI used by applications to last detail. Linux kernel is disabling red zone and use kernel code model, yet the ABI is not going to be adjusted for that. This is resonably easy to fix on kernel side in signal handling, or by removing std usage completely (I believe it is not performance win, but some benchmarking would be needed to double check) Honza ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:49 ` Jan Hubicka @ 2008-03-05 21:02 ` Michael Matz 2008-03-05 21:20 ` RELEASE BLOCKER: " Joe Buck 2008-03-05 21:07 ` H. Peter Anvin 1 sibling, 1 reply; 98+ messages in thread From: Michael Matz @ 2008-03-05 21:02 UTC (permalink / raw) To: Jan Hubicka; +Cc: Joe Buck, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc Hi, On Wed, 5 Mar 2008, Jan Hubicka wrote: > Kernels almost never follow ABI used by applications to last detail. But we aren't talking about the ABI the kernel uses internally, but about what is exposed to user-space via signal handlers. _That_ part needs to be followed, and if it isn't it's a serious problem we somehow have to hack around. > Linux kernel is disabling red zone and use kernel code model, yet the > ABI is not going to be adjusted for that. > > This is resonably easy to fix on kernel side in signal handling, or by > removing std usage completely That is true. But it requires updating the kernel to a fixed one if you want to run your programs compiled by 4.3 :-/ Not something we'd like to demand. Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:02 ` Michael Matz @ 2008-03-05 21:20 ` Joe Buck 2008-03-05 21:32 ` Richard Guenther ` (2 more replies) 0 siblings, 3 replies; 98+ messages in thread From: Joe Buck @ 2008-03-05 21:20 UTC (permalink / raw) To: Michael Matz Cc: Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Wed, 5 Mar 2008, Jan Hubicka wrote: > > Linux kernel is disabling red zone and use kernel code model, yet the > > ABI is not going to be adjusted for that. > > > > This is resonably easy to fix on kernel side in signal handling, or by > > removing std usage completely On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: > That is true. But it requires updating the kernel to a fixed one if you > want to run your programs compiled by 4.3 :-/ Not something we'd like to > demand. I changed the title just for emphasis. I think that we can't ship 4.3.0 if signal handlers on x86/x86_64 platforms for both Linux and BSD systems will mysteriously (to the users) fail, and it doesn't matter whose fault it is. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:20 ` RELEASE BLOCKER: " Joe Buck @ 2008-03-05 21:32 ` Richard Guenther 2008-03-05 21:34 ` H. Peter Anvin 2008-03-05 21:45 ` Aurelien Jarno 2008-03-05 21:43 ` Andrew Pinski 2008-03-05 21:43 ` Michael Matz 2 siblings, 2 replies; 98+ messages in thread From: Richard Guenther @ 2008-03-05 21:32 UTC (permalink / raw) To: Joe Buck Cc: Michael Matz, Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <Joe.Buck@synopsys.com> wrote: > > > On Wed, 5 Mar 2008, Jan Hubicka wrote: > > > Linux kernel is disabling red zone and use kernel code model, yet the > > > ABI is not going to be adjusted for that. > > > > > > This is resonably easy to fix on kernel side in signal handling, or by > > > removing std usage completely > > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: > > That is true. But it requires updating the kernel to a fixed one if you > > want to run your programs compiled by 4.3 :-/ Not something we'd like to > > demand. > > I changed the title just for emphasis. > > I think that we can't ship 4.3.0 if signal handlers on x86/x86_64 > platforms for both Linux and BSD systems will mysteriously (to the users) > fail, and it doesn't matter whose fault it is. We didn't yet run into this issue and build openSUSE with 4.3 since more than three month. Richard. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:32 ` Richard Guenther @ 2008-03-05 21:34 ` H. Peter Anvin 2008-03-05 21:40 ` Richard Guenther ` (3 more replies) 2008-03-05 21:45 ` Aurelien Jarno 1 sibling, 4 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 21:34 UTC (permalink / raw) To: Richard Guenther Cc: Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc 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()? -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:34 ` H. Peter Anvin @ 2008-03-05 21:40 ` Richard Guenther 2008-03-05 22:16 ` David Miller 2008-03-05 21:43 ` Joe Buck ` (2 subsequent siblings) 3 siblings, 1 reply; 98+ messages in thread From: Richard Guenther @ 2008-03-05 21:40 UTC (permalink / raw) To: H. Peter Anvin Cc: Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Wed, Mar 5, 2008 at 10:34 PM, H. Peter Anvin <hpa@zytor.com> 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()? Right. So this problem is over-exaggerated. It's not like "any binary you create on that system will be broken on any other existing system." Richard. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:40 ` Richard Guenther @ 2008-03-05 22:16 ` David Miller 2008-03-05 22:37 ` Joe Buck 2008-03-05 22:51 ` Michael Matz 0 siblings, 2 replies; 98+ messages in thread From: David Miller @ 2008-03-05 22:16 UTC (permalink / raw) To: richard.guenther Cc: hpa, Joe.Buck, matz, hubicka, aurelien, linux-kernel, gcc From: "Richard Guenther" <richard.guenther@gmail.com> Date: Wed, 5 Mar 2008 22:40:59 +0100 > Right. So this problem is over-exaggerated. It's not like > "any binary you create on that system will be broken on any > other existing system." I will be sure to hunt you down to help debug when someone reports that once every few weeks their multi-day simulation gives incorrect results :-) This is one of those cases where the bug is going to be a huge issue to people who actually hit it, and since we know about the problem, knowingly shipping something in that state is unforgivable. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:16 ` David Miller @ 2008-03-05 22:37 ` Joe Buck 2008-03-05 22:51 ` Michael Matz 1 sibling, 0 replies; 98+ messages in thread From: Joe Buck @ 2008-03-05 22:37 UTC (permalink / raw) To: David Miller Cc: richard.guenther, hpa, matz, hubicka, aurelien, linux-kernel, gcc On Wed, Mar 05, 2008 at 02:16:22PM -0800, David Miller wrote: > From: "Richard Guenther" <richard.guenther@gmail.com> > Date: Wed, 5 Mar 2008 22:40:59 +0100 > > > Right. So this problem is over-exaggerated. It's not like > > "any binary you create on that system will be broken on any > > other existing system." > > I will be sure to hunt you down to help debug when someone reports > that once every few weeks their multi-day simulation gives incorrect > results :-) > > This is one of those cases where the bug is going to be a huge > issue to people who actually hit it, and since we know about the > problem, knowingly shipping something in that state is unforgivable. In this case, it appears that the 4.3.0 tarballs already hit the servers before the issue was discovered. It's not the end of the world; quite often .0 releases have some issue, and we can patch the 4_3 branch and recommend that the patch be used. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:16 ` David Miller 2008-03-05 22:37 ` Joe Buck @ 2008-03-05 22:51 ` Michael Matz 2008-03-05 22:58 ` H. Peter Anvin 1 sibling, 1 reply; 98+ messages in thread From: Michael Matz @ 2008-03-05 22:51 UTC (permalink / raw) To: David Miller Cc: richard.guenther, hpa, Joe.Buck, hubicka, aurelien, linux-kernel, gcc Hi, On Wed, 5 Mar 2008, David Miller wrote: > I will be sure to hunt you down to help debug when someone reports that > once every few weeks their multi-day simulation gives incorrect results > :-) Give them a LD_PRELOADable DSO that intercepts signal() and sig_action(), installing a trampoline that first does "cld" and then jumps to the real handler. That ought to be a quick test if it's this or a different issue. A hack, yes, but well... :) > This is one of those cases where the bug is going to be a huge issue to > people who actually hit it, and since we know about the problem, > knowingly shipping something in that state is unforgivable. Many bugs are a big issue to people who actually hit them, and we had (and probably still have) far nastier corner case miscompilations here and there and nevertheless released. It never was the end of the world :) Let it be a data point that nobody noticed the problem which existed in trunk since more than a year (since 2006-12-06 to be precise). Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:51 ` Michael Matz @ 2008-03-05 22:58 ` H. Peter Anvin 2008-03-05 23:07 ` Michael Matz 0 siblings, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 22:58 UTC (permalink / raw) To: Michael Matz Cc: David Miller, richard.guenther, Joe.Buck, hubicka, aurelien, linux-kernel, gcc Michael Matz wrote: > > Many bugs are a big issue to people who actually hit them, and we had (and > probably still have) far nastier corner case miscompilations here and > there and nevertheless released. It never was the end of the world :) > This is the sort of stuff that security holes are made from. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:58 ` H. Peter Anvin @ 2008-03-05 23:07 ` Michael Matz 2008-03-05 23:10 ` David Miller 2008-03-05 23:12 ` Olivier Galibert 0 siblings, 2 replies; 98+ messages in thread From: Michael Matz @ 2008-03-05 23:07 UTC (permalink / raw) To: H. Peter Anvin Cc: David Miller, richard.guenther, Joe.Buck, hubicka, aurelien, linux-kernel, gcc Hi, On Wed, 5 Mar 2008, H. Peter Anvin wrote: > Michael Matz wrote: > > > > Many bugs are a big issue to people who actually hit them, and we had (and > > probably still have) far nastier corner case miscompilations here and there > > and nevertheless released. It never was the end of the world :) > > > > This is the sort of stuff that security holes are made from. For security problems I prefer fixes over work-arounds. The fix lies in the kernel, the work-around in gcc. Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 23:07 ` Michael Matz @ 2008-03-05 23:10 ` David Miller 2008-03-05 23:16 ` Joe Buck 2008-03-05 23:12 ` Olivier Galibert 1 sibling, 1 reply; 98+ messages in thread From: David Miller @ 2008-03-05 23:10 UTC (permalink / raw) To: matz Cc: hpa, richard.guenther, Joe.Buck, hubicka, aurelien, linux-kernel, gcc From: Michael Matz <matz@suse.de> Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET) > The fix lies in the kernel, the work-around in gcc. This depends upon how you interpret this ABI situation. There is at least some agreement that how things have actually been implemented by these kernels for more than 15 years trumps whatever a paper standard states. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 23:10 ` David Miller @ 2008-03-05 23:16 ` Joe Buck 0 siblings, 0 replies; 98+ messages in thread From: Joe Buck @ 2008-03-05 23:16 UTC (permalink / raw) To: David Miller Cc: matz, hpa, richard.guenther, hubicka, aurelien, linux-kernel, gcc On Wed, Mar 05, 2008 at 03:10:12PM -0800, David Miller wrote: > From: Michael Matz <matz@suse.de> > Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET) > > > The fix lies in the kernel, the work-around in gcc. > > This depends upon how you interpret this ABI situation. > > There is at least some agreement that how things have > actually been implemented by these kernels for more > than 15 years trumps whatever a paper standard states. We had a similar argument about the undefinedness of signed int overflow. That's what the standard says, yet code that assumes otherwise is pervasive, including in gcc itself. If a standard is widely violated in a very consistent way, the violation in effect becomes standard. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 23:07 ` Michael Matz 2008-03-05 23:10 ` David Miller @ 2008-03-05 23:12 ` Olivier Galibert 1 sibling, 0 replies; 98+ messages in thread From: Olivier Galibert @ 2008-03-05 23:12 UTC (permalink / raw) To: Michael Matz Cc: H. Peter Anvin, David Miller, richard.guenther, Joe.Buck, hubicka, aurelien, linux-kernel, gcc On Thu, Mar 06, 2008 at 12:07:39AM +0100, Michael Matz wrote: > For security problems I prefer fixes over work-arounds. The fix lies in > the kernel, the work-around in gcc. Incorrect. The bugs are in the ABI documentation and in gcc, and the fixes should be done there. Doing it in the kernel is the workaround. OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:34 ` H. Peter Anvin 2008-03-05 21:40 ` Richard Guenther @ 2008-03-05 21:43 ` Joe Buck 2008-03-05 21:44 ` Richard Guenther [not found] ` <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com> 2008-03-06 8:44 ` Andi Kleen 3 siblings, 1 reply; 98+ messages in thread From: Joe Buck @ 2008-03-05 21:43 UTC (permalink / raw) To: H. Peter Anvin Cc: Richard Guenther, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin 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()? Also, would it be possible to produce an exploit? If you can get string instructions to work "the wrong way", you might be able to overwrite data. "We haven't seen a problem" isn't the right answer. Can someone deliberately *create* a problem? And if we aren't sure, we should err on the side of safety. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:43 ` Joe Buck @ 2008-03-05 21:44 ` Richard Guenther 0 siblings, 0 replies; 98+ messages in thread From: Richard Guenther @ 2008-03-05 21:44 UTC (permalink / raw) To: Joe Buck Cc: H. Peter Anvin, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Wed, Mar 5, 2008 at 10:43 PM, Joe Buck <Joe.Buck@synopsys.com> wrote: > > On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin 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()? > > Also, would it be possible to produce an exploit? If you can get string > instructions to work "the wrong way", you might be able to overwrite data. > > "We haven't seen a problem" isn't the right answer. Can someone > deliberately *create* a problem? > > And if we aren't sure, we should err on the side of safety. Oh, you mean releasing a kernel security update? ;) What does ICC or other compilers do? Richard. ^ permalink raw reply [flat|nested] 98+ messages in thread
[parent not found: <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com>]
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag [not found] ` <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com> @ 2008-03-05 21:59 ` Michael Matz 2008-03-05 22:13 ` Adrian Bunk 2008-03-06 0:36 ` Chris Lattner 2008-03-05 22:05 ` H. Peter Anvin 1 sibling, 2 replies; 98+ messages in thread From: Michael Matz @ 2008-03-05 21:59 UTC (permalink / raw) To: Chris Lattner Cc: H.Peter Anvin, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Hi, On Wed, 5 Mar 2008, Chris Lattner wrote: > > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin 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. Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:59 ` Michael Matz @ 2008-03-05 22:13 ` Adrian Bunk 2008-03-05 22:21 ` David Miller 2008-03-05 23:13 ` Olivier Galibert 2008-03-06 0:36 ` Chris Lattner 1 sibling, 2 replies; 98+ messages in thread From: Adrian Bunk @ 2008-03-05 22:13 UTC (permalink / raw) To: Michael Matz Cc: Chris Lattner, H.Peter Anvin, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote: > Hi, > > On Wed, 5 Mar 2008, Chris Lattner wrote: > > > > > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin 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. Compiling older kernels with new gcc versions has never been supported. You are e.g. aware that for many 32bit architectures (including i386) and kernels up to and including 2.6.25-rc4 even the build fails with gcc 4.3? > Ciao, > Michael. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:13 ` Adrian Bunk @ 2008-03-05 22:21 ` David Miller 2008-03-05 23:13 ` Olivier Galibert 1 sibling, 0 replies; 98+ messages in thread From: David Miller @ 2008-03-05 22:21 UTC (permalink / raw) To: bunk Cc: matz, clattner, hpa, richard.guenther, Joe.Buck, hubicka, aurelien, linux-kernel, gcc From: Adrian Bunk <bunk@kernel.org> Date: Thu, 6 Mar 2008 00:13:04 +0200 > On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote: > > The problem is with old kernels, which by definition stay unfixed. > > Compiling older kernels with new gcc versions has never been supported. Adrian we're talking about userland binaries compiled by gcc-4.3, not the kernel. Please follow the discussion if you'd like to contribute. Thanks. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:13 ` Adrian Bunk 2008-03-05 22:21 ` David Miller @ 2008-03-05 23:13 ` Olivier Galibert 1 sibling, 0 replies; 98+ messages in thread From: Olivier Galibert @ 2008-03-05 23:13 UTC (permalink / raw) To: Adrian Bunk Cc: Michael Matz, Chris Lattner, H.Peter Anvin, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 06, 2008 at 12:13:04AM +0200, Adrian Bunk wrote: > Compiling older kernels with new gcc versions has never been supported. You read the thread too fast. It's not at all about compiling the kernel. OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:59 ` Michael Matz 2008-03-05 22:13 ` Adrian Bunk @ 2008-03-06 0:36 ` Chris Lattner 2008-03-06 0:47 ` H. Peter Anvin 2008-03-06 0:49 ` Aurelien Jarno 1 sibling, 2 replies; 98+ messages in thread From: Chris Lattner @ 2008-03-06 0:36 UTC (permalink / raw) To: Michael Matz Cc: H.Peter Anvin, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc >>> 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: 1. User space has direction flag set. 2. signal occurs 3. kernel code is entered 4. kernel code does string operation <boom> Fixing this instance of the problem by changing GCC requires (at least) recompiling the kernel. Changing the ABI for this seems like a pretty crazy solution to a very minor and easily fixable kernel bug. Distros have control over what kernels they ship, they have absolute power to ensure this doesn't affect their users when running default kernels - without changing the compiler. -Chris ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 0:36 ` Chris Lattner @ 2008-03-06 0:47 ` H. Peter Anvin [not found] ` <578FCA7D-D7A6-44F6-9310-4A97C13CDCBE@apple.com> 2008-03-06 0:49 ` Aurelien Jarno 1 sibling, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 0:47 UTC (permalink / raw) To: Chris Lattner Cc: Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc 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 ^ permalink raw reply [flat|nested] 98+ messages in thread
[parent not found: <578FCA7D-D7A6-44F6-9310-4A97C13CDCBE@apple.com>]
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag [not found] ` <578FCA7D-D7A6-44F6-9310-4A97C13CDCBE@apple.com> @ 2008-03-06 1:12 ` H. Peter Anvin 2008-03-06 9:17 ` Jakub Jelinek 2008-03-06 13:51 ` Olivier Galibert 0 siblings, 2 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 1:12 UTC (permalink / raw) To: Chris Lattner Cc: Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Chris Lattner wrote: >> >> 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. > It's a kernel bug, and it needs to be fixed. The discussion is about what to do in the meantime. (And yes, you're absolutely right: between global subroutine entry and the first asm or string operation, you'd have to emit cld.) -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 1:12 ` H. Peter Anvin @ 2008-03-06 9:17 ` Jakub Jelinek 2008-03-06 13:51 ` Olivier Galibert 1 sibling, 0 replies; 98+ messages in thread From: Jakub Jelinek @ 2008-03-06 9:17 UTC (permalink / raw) To: H. Peter Anvin Cc: Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc 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. The discussion is about > what to do in the meantime. While it is known that 32-bit glibc memmove and also <string.h> inlines for memmove and memrchr use std; some string op; cld;, 64-bit glibc doesn't ever use std instruction. gcc itself never generates std instruction. So, I've disassebled the whole Fedora/x86_64 distro (64-bit binaries/shared libraries/archives/object files, unpacked over 12000 rpms) to see how common is std insn in 64-bit code. The only positive hits were the kernel (/boot/xen-syms-2.6.21.7-2897.fc9 in particular, whatever that is) and libpolyml.so.1.0.0 (polyml-libs - this one has handwritten assembly in NASM), though I had to skim through some false positives (0xfd byte appearing in data within code sections, but it is easy to see if 0xfd is surrounded by invalid or nonsensical instructions that it is actually data). The conclusion is that DF=1 in x86_64 64-bit code is extremely rare. Therefore, if we decide to apply a workaround for the kernel bug in gcc (I'm not convinced we should), it should be IMNSHO limited to 32-bit code. Jakub ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 1:12 ` H. Peter Anvin 2008-03-06 9:17 ` Jakub Jelinek @ 2008-03-06 13:51 ` Olivier Galibert 2008-03-06 14:03 ` Paolo Bonzini ` (3 more replies) 1 sibling, 4 replies; 98+ messages in thread From: Olivier Galibert @ 2008-03-06 13:51 UTC (permalink / raw) To: H. Peter Anvin Cc: Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc 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. OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 13:51 ` Olivier Galibert @ 2008-03-06 14:03 ` Paolo Bonzini 2008-03-06 14:12 ` Olivier Galibert 2008-03-06 15:09 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 1 reply; 98+ messages in thread From: Paolo Bonzini @ 2008-03-06 14:03 UTC (permalink / raw) To: Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Olivier Galibert 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. No, the bug *in the kernel* was already present (if you had a signal raised during a call to memmove). It's just more visible with GCC 4.3. Paolo ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 14:03 ` Paolo Bonzini @ 2008-03-06 14:12 ` Olivier Galibert 2008-03-06 14:15 ` Andrew Haley 2008-03-06 17:58 ` Joe Buck 0 siblings, 2 replies; 98+ messages in thread From: Olivier Galibert @ 2008-03-06 14:12 UTC (permalink / raw) To: Paolo Bonzini Cc: H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote: > Olivier Galibert 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. > > No, the bug *in the kernel* was already present (if you had a signal > raised during a call to memmove). It's just more visible with GCC 4.3. I'm curious, since when paper documentation became the Truth and reality became a bug? OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 14:12 ` Olivier Galibert @ 2008-03-06 14:15 ` Andrew Haley 2008-03-06 17:58 ` Joe Buck 1 sibling, 0 replies; 98+ messages in thread From: Andrew Haley @ 2008-03-06 14:15 UTC (permalink / raw) To: Olivier Galibert, Paolo Bonzini, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Olivier Galibert wrote: > On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote: >> Olivier Galibert 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. >> No, the bug *in the kernel* was already present (if you had a signal >> raised during a call to memmove). It's just more visible with GCC 4.3. > > I'm curious, since when paper documentation became the Truth and > reality became a bug? Isn't that the definition of a bug? That a program does not meet its specification? Andrew. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 14:12 ` Olivier Galibert 2008-03-06 14:15 ` Andrew Haley @ 2008-03-06 17:58 ` Joe Buck 2008-03-06 18:10 ` Olivier Galibert 1 sibling, 1 reply; 98+ messages in thread From: Joe Buck @ 2008-03-06 17:58 UTC (permalink / raw) To: Olivier Galibert, Paolo Bonzini, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 06, 2008 at 03:12:21PM +0100, Olivier Galibert wrote: > On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote: > > Olivier Galibert 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. > > > > No, the bug *in the kernel* was already present (if you had a signal > > raised during a call to memmove). It's just more visible with GCC 4.3. > > I'm curious, since when paper documentation became the Truth and > reality became a bug? If the kernel allows state to leak from one process to another, for example from a process running as root to a process running as an ordinary user, it's a bug, with possible security implications. In this particular case not much can be communicated through a one-bit flag, so it would only be relevant in those situations where you want to forbid any communication channels from a given process. So the kernel developers might consider it a trivial bug. Or, they could just fix it, which I understand is the plan. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:58 ` Joe Buck @ 2008-03-06 18:10 ` Olivier Galibert 2008-03-06 18:13 ` Paolo Bonzini 0 siblings, 1 reply; 98+ messages in thread From: Olivier Galibert @ 2008-03-06 18:10 UTC (permalink / raw) To: Joe Buck Cc: Paolo Bonzini, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote: > If the kernel allows state to leak from one process to another, > for example from a process running as root to a process running as an > ordinary user, it's a bug, with possible security implications. I don't think that it is relevant in your case. If you have the signal handler in something that does not share the VM with the interrupted thread, you will have a context switch which is supposed to store the direction flag and restore the one from the handling thread. If you share the VM there is no context switch but you have access to the exact same memory with the exact same rights, making the leak irrelevant. OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 18:10 ` Olivier Galibert @ 2008-03-06 18:13 ` Paolo Bonzini 2008-03-06 18:31 ` Jack Lloyd 0 siblings, 1 reply; 98+ messages in thread From: Paolo Bonzini @ 2008-03-06 18:13 UTC (permalink / raw) To: Olivier Galibert, Joe Buck, Paolo Bonzini, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Olivier Galibert wrote: > On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote: >> If the kernel allows state to leak from one process to another, >> for example from a process running as root to a process running as an >> ordinary user, it's a bug, with possible security implications. > > I don't think that it is relevant in your case. If you have the > signal handler in something that does not share the VM with the > interrupted thread, you will have a context switch which is supposed > to store the direction flag and restore the one from the handling > thread. If you share the VM there is no context switch but you have > access to the exact same memory with the exact same rights, making the > leak irrelevant. A process can send a signal via kill. IOW, a malicious process can *control when the process would be interrupted* in order to get it into the signal handler with DF=1. Paolo ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 18:13 ` Paolo Bonzini @ 2008-03-06 18:31 ` Jack Lloyd 2008-03-06 18:35 ` Andrew Pinski 2008-03-06 19:43 ` Paolo Bonzini 0 siblings, 2 replies; 98+ messages in thread From: Jack Lloyd @ 2008-03-06 18:31 UTC (permalink / raw) To: gcc, linux-kernel On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: > A process can send a signal via kill. IOW, a malicious process can > *control when the process would be interrupted* in order to get it into > the signal handler with DF=1. If the malicious process can send a signal to another process, it could also ptrace() it. Which is more useful, if you wanted to be malicious? Jack ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 18:31 ` Jack Lloyd @ 2008-03-06 18:35 ` Andrew Pinski 2008-03-06 19:44 ` Paolo Bonzini 2008-03-06 19:43 ` Paolo Bonzini 1 sibling, 1 reply; 98+ messages in thread From: Andrew Pinski @ 2008-03-06 18:35 UTC (permalink / raw) To: gcc, linux-kernel On 3/6/08, Jack Lloyd <lloyd@randombit.net> wrote: > On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: > > A process can send a signal via kill. IOW, a malicious process can > > *control when the process would be interrupted* in order to get it into > > the signal handler with DF=1. > > If the malicious process can send a signal to another process, it > could also ptrace() it. Which is more useful, if you wanted to be > malicious? And more to the point, it can happen before GCC 4.3.0. So why does GCC have do something that just happens more often now? I still don't see why we have to work around a bug in the kernel which could show up before GCC 4.3.0. -- Pinski ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 18:35 ` Andrew Pinski @ 2008-03-06 19:44 ` Paolo Bonzini 0 siblings, 0 replies; 98+ messages in thread From: Paolo Bonzini @ 2008-03-06 19:44 UTC (permalink / raw) To: Andrew Pinski; +Cc: gcc, linux-kernel >> If the malicious process can send a signal to another process, it >> could also ptrace() it. Which is more useful, if you wanted to be >> malicious? > > And more to the point, it can happen before GCC 4.3.0. Yes, and that's why the kernel should just fix it, and the fix should be backported and treated like any other security fix. Paolo ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 18:31 ` Jack Lloyd 2008-03-06 18:35 ` Andrew Pinski @ 2008-03-06 19:43 ` Paolo Bonzini 2008-03-06 20:16 ` Jack Lloyd 1 sibling, 1 reply; 98+ messages in thread From: Paolo Bonzini @ 2008-03-06 19:43 UTC (permalink / raw) To: gcc, linux-kernel Jack Lloyd wrote: > On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: >> A process can send a signal via kill. IOW, a malicious process can >> *control when the process would be interrupted* in order to get it into >> the signal handler with DF=1. > > If the malicious process can send a signal to another process, it > could also ptrace() it. Which is more useful, if you wanted to be > malicious? 1) capabilities(7) 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1)... Paolo ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 19:43 ` Paolo Bonzini @ 2008-03-06 20:16 ` Jack Lloyd 2008-03-06 21:37 ` Artur Skawina 0 siblings, 1 reply; 98+ messages in thread From: Jack Lloyd @ 2008-03-06 20:16 UTC (permalink / raw) To: gcc, linux-kernel On Thu, Mar 06, 2008 at 08:43:27PM +0100, Paolo Bonzini wrote: > Jack Lloyd wrote: > >On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: > >>A process can send a signal via kill. IOW, a malicious process can > >>*control when the process would be interrupted* in order to get it into > >>the signal handler with DF=1. > > > >If the malicious process can send a signal to another process, it > >could also ptrace() it. Which is more useful, if you wanted to be > >malicious? > > 1) capabilities(7) Ah you are right, I misinterpreted something from the man page ("non-root processes cannot trace processes that they cannot send signals to") to mean something it did not (basically, that CAP_KILL implied CAP_SYS_PTRACE, which from reading the kernel source is clearly not the case...) But still: so the threat here is of a malicious process with the ability to send arbitrary signals to any process using CAP_KILL (since in any other case when a process can send a signal, it can do much more damage in other ways), which could leverage that into (potentially) uid==0 using misexecuted code in a signal handler. As a correctness issue, obviously this should be fixed/patched around, if feasible. But as a security flaw? I'm not seeing much that is compelling. > 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1) I don't understand how this is a problem - unless these setuid programs, while not malicious, can be tricked into signalling a process they did not intend to. (In which case they already have a major bug, df bit being cleared or not). -Jack ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 20:16 ` Jack Lloyd @ 2008-03-06 21:37 ` Artur Skawina 0 siblings, 0 replies; 98+ messages in thread From: Artur Skawina @ 2008-03-06 21:37 UTC (permalink / raw) To: gcc, linux-kernel Jack Lloyd wrote: > But still: so the threat here is of a malicious process with the > ability to send arbitrary signals to any process using CAP_KILL (since > in any other case when a process can send a signal, it can do much > more damage in other ways), which could leverage that into > (potentially) uid==0 using misexecuted code in a signal handler. > > As a correctness issue, obviously this should be fixed/patched around, > if feasible. But as a security flaw? I'm not seeing much that is > compelling. > >> 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1) > > I don't understand how this is a problem - unless these setuid > programs, while not malicious, can be tricked into signalling a > process they did not intend to. (In which case they already have a > major bug, df bit being cleared or not). think apps keeping crypto keys etc in ram and wiping them from signal handlers. eg gnupg does this; fortunately it seems to have moved from memset() to a open coded solution, so probably isn't affected. OTOH it wouldn't surprise me these days if the compiler would emit string ops even w/o an explicit mem* call. Copying a private memory region to some public buffer could also lead to interesting results... IOW being able to avoid a memset (or copying the wrong data) certainly could have security consequences. artur ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 13:51 ` Olivier Galibert 2008-03-06 14:03 ` Paolo Bonzini @ 2008-03-06 15:09 ` Robert Dewar 2008-03-06 15:37 ` NightStrike 2008-03-06 16:14 ` Artur Skawina 3 siblings, 0 replies; 98+ messages in thread From: Robert Dewar @ 2008-03-06 15:09 UTC (permalink / raw) To: Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Olivier Galibert 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. I agree, it reminds me of Burroughs on the 5500 believing the Fortran standard which carefully allowed for a stack based implementation of Fortran, Algol-style, unfortunately no real Fortran programs worked with this semantics, and it was one of the factors contributing the demise of the 5500. > > OG. > ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 13:51 ` Olivier Galibert 2008-03-06 14:03 ` Paolo Bonzini 2008-03-06 15:09 ` Robert Dewar @ 2008-03-06 15:37 ` NightStrike 2008-03-06 15:43 ` H.J. Lu 2008-03-06 15:57 ` Robert Dewar 2008-03-06 16:14 ` Artur Skawina 3 siblings, 2 replies; 98+ messages in thread From: NightStrike @ 2008-03-06 15:37 UTC (permalink / raw) To: Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On 3/6/08, Olivier Galibert <galibert@pobox.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. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 15:37 ` NightStrike @ 2008-03-06 15:43 ` H.J. Lu 2008-03-06 15:50 ` H. Peter Anvin 2008-03-06 15:57 ` Robert Dewar 1 sibling, 1 reply; 98+ messages in thread From: H.J. Lu @ 2008-03-06 15:43 UTC (permalink / raw) To: NightStrike Cc: Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc I agree with it. There is no right or wrong here Let's start from scratch and figure out what is the best way to handle this, assuming we are defining a new psABI. H.J. On Thu, Mar 6, 2008 at 7:37 AM, NightStrike <nightstrike@gmail.com> wrote: > > On 3/6/08, Olivier Galibert <galibert@pobox.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. > ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 15:43 ` H.J. Lu @ 2008-03-06 15:50 ` H. Peter Anvin 2008-03-06 16:23 ` Jakub Jelinek 0 siblings, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 15:50 UTC (permalink / raw) To: H.J. Lu Cc: NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc H.J. Lu wrote: > I agree with it. There is no right or wrong here Let's start from > scratch and figure out > what is the best way to handle this, assuming we are defining a new psABI. No, I believe the right way to approach this is by applying the good old-fashioned principle from Ask Mr. Protocol: Be liberal in what you receive, conservative in what you send In other words: a. Fix the kernel. Already in progress. b. Do *not* make gcc assume DF is clean for now. Adding a switch would be a useful thing, since if nothing else it would benefit embedded environments. We might assume DF is clean on 64 bits, since it appears it is rarely used anyway, and 64 bits is more important in the long run. c. Once fixed kernels have been out long enough, we can flip the default of the switch, one platform at a time if need be (e.g. there may never be another SCO OpenServer.) -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 15:50 ` H. Peter Anvin @ 2008-03-06 16:23 ` Jakub Jelinek 2008-03-06 16:27 ` İsmail Dönmez 2008-03-06 16:58 ` H.J. Lu 0 siblings, 2 replies; 98+ messages in thread From: Jakub Jelinek @ 2008-03-06 16:23 UTC (permalink / raw) To: H. Peter Anvin Cc: H.J. Lu, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote: > H.J. Lu wrote: > >I agree with it. There is no right or wrong here Let's start from > >scratch and figure out > >what is the best way to handle this, assuming we are defining a new psABI. BTW, just tested icc and icc doesn't generate cld either (so it matches the new gcc behavior). char buf1[32], buf2[32]; void bar (void); void foo (void) { __builtin_memset (buf1, 0, 32); bar (); __builtin_memset (buf2, 0, 32); } Jakub ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 16:23 ` Jakub Jelinek @ 2008-03-06 16:27 ` İsmail Dönmez 2008-03-06 16:58 ` H.J. Lu 1 sibling, 0 replies; 98+ messages in thread From: İsmail Dönmez @ 2008-03-06 16:27 UTC (permalink / raw) To: Jakub Jelinek Cc: H. Peter Anvin, H.J. Lu, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Hi, On Thu, Mar 6, 2008 at 6:23 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote: > > H.J. Lu wrote: > > >I agree with it. There is no right or wrong here Let's start from > > >scratch and figure out > > >what is the best way to handle this, assuming we are defining a new psABI. > > BTW, just tested icc and icc doesn't generate cld either (so it matches the > new gcc behavior). > char buf1[32], buf2[32]; > void bar (void); > void foo (void) > { > __builtin_memset (buf1, 0, 32); > bar (); > __builtin_memset (buf2, 0, 32); > } Also LKML discussion pointed out that Solaris gets this right too. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 16:23 ` Jakub Jelinek 2008-03-06 16:27 ` İsmail Dönmez @ 2008-03-06 16:58 ` H.J. Lu 2008-03-06 17:06 ` H. Peter Anvin 1 sibling, 1 reply; 98+ messages in thread From: H.J. Lu @ 2008-03-06 16:58 UTC (permalink / raw) To: Jakub Jelinek Cc: H. Peter Anvin, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote: > > H.J. Lu wrote: > > >I agree with it. There is no right or wrong here Let's start from > > >scratch and figure out > > >what is the best way to handle this, assuming we are defining a new psABI. > > BTW, just tested icc and icc doesn't generate cld either (so it matches the > new gcc behavior). > char buf1[32], buf2[32]; > void bar (void); > void foo (void) > { > __builtin_memset (buf1, 0, 32); > bar (); > __builtin_memset (buf2, 0, 32); > } > Icc follows the psABI. If we are saying icc/gcc 4.3 need a fix, we'd better define a new psABI first. H.J. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 16:58 ` H.J. Lu @ 2008-03-06 17:06 ` H. Peter Anvin 2008-03-06 17:14 ` H.J. Lu 0 siblings, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 17:06 UTC (permalink / raw) To: H.J. Lu Cc: Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc H.J. Lu wrote: > On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote: >> > H.J. Lu wrote: >> > >I agree with it. There is no right or wrong here Let's start from >> > >scratch and figure out >> > >what is the best way to handle this, assuming we are defining a new psABI. >> >> BTW, just tested icc and icc doesn't generate cld either (so it matches the >> new gcc behavior). >> char buf1[32], buf2[32]; >> void bar (void); >> void foo (void) >> { >> __builtin_memset (buf1, 0, 32); >> bar (); >> __builtin_memset (buf2, 0, 32); >> } >> > > Icc follows the psABI. If we are saying icc/gcc 4.3 need a fix, we'd > better define > a new psABI first. > Not a fix, an (optional) workaround for a system bug. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:06 ` H. Peter Anvin @ 2008-03-06 17:14 ` H.J. Lu 2008-03-06 17:17 ` H. Peter Anvin 2008-03-06 17:18 ` Robert Dewar 0 siblings, 2 replies; 98+ messages in thread From: H.J. Lu @ 2008-03-06 17:14 UTC (permalink / raw) To: H. Peter Anvin Cc: Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 6, 2008 at 9:06 AM, H. Peter Anvin <hpa@zytor.com> wrote: > > H.J. Lu wrote: > > On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: > >> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote: > >> > H.J. Lu wrote: > >> > >I agree with it. There is no right or wrong here Let's start from > >> > >scratch and figure out > >> > >what is the best way to handle this, assuming we are defining a new psABI. > >> > >> BTW, just tested icc and icc doesn't generate cld either (so it matches the > >> new gcc behavior). > >> char buf1[32], buf2[32]; > >> void bar (void); > >> void foo (void) > >> { > >> __builtin_memset (buf1, 0, 32); > >> bar (); > >> __builtin_memset (buf2, 0, 32); > >> } > >> > > > > Icc follows the psABI. If we are saying icc/gcc 4.3 need a fix, we'd > > better define > > a new psABI first. > > > > Not a fix, an (optional) workaround for a system bug. > So that is the bug in the Linux kernel. Since fixing kernel is much easier than providing a workaround in compilers, I think kernel should be fixed and no need for icc/gcc fix. H.J. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:14 ` H.J. Lu @ 2008-03-06 17:17 ` H. Peter Anvin 2008-03-06 17:34 ` H.J. Lu 2008-03-06 17:18 ` Robert Dewar 1 sibling, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 17:17 UTC (permalink / raw) To: H.J. Lu Cc: Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc H.J. Lu wrote: >> >> Not a fix, an (optional) workaround for a system bug. > > So that is the bug in the Linux kernel. Since fixing kernel is much easier > than providing a workaround in compilers, I think kernel should be fixed > and no need for icc/gcc fix. > The problem is, you're going to have to be able to produce binaries compatible with old kernels for a *long* time for come. Are you honestly saying you'll tell those people "use gcc 4.2 or earlier"? If so, I think most distros will have to freeze gcc for the next several years. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:17 ` H. Peter Anvin @ 2008-03-06 17:34 ` H.J. Lu 2008-03-06 19:35 ` Robert Dewar 0 siblings, 1 reply; 98+ messages in thread From: H.J. Lu @ 2008-03-06 17:34 UTC (permalink / raw) To: H. Peter Anvin Cc: Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 6, 2008 at 9:17 AM, H. Peter Anvin <hpa@zytor.com> wrote: > H.J. Lu wrote: > >> > >> Not a fix, an (optional) workaround for a system bug. > > > > So that is the bug in the Linux kernel. Since fixing kernel is much easier > > than providing a workaround in compilers, I think kernel should be fixed > > and no need for icc/gcc fix. > > > > The problem is, you're going to have to be able to produce binaries > compatible with old kernels for a *long* time for come. Are you > honestly saying you'll tell those people "use gcc 4.2 or earlier"? If > so, I think most distros will have to freeze gcc for the next several years. > Icc has been following psABI for years on Linux and it doesn't stop people using icc on Linux. On the other hand, it may be a good idea to provide a workaround in gcc and enables it by default. OSVs can fix thekernel and disable it by default. We can even issue a message whenever the workaround is used. H.J. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:34 ` H.J. Lu @ 2008-03-06 19:35 ` Robert Dewar 0 siblings, 0 replies; 98+ messages in thread From: Robert Dewar @ 2008-03-06 19:35 UTC (permalink / raw) To: H.J. Lu Cc: H. Peter Anvin, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc H.J. Lu wrote: > Icc has been following psABI for years on Linux and it doesn't stop people > using icc on Linux. On the other hand, it may be a good idea to provide a > workaround in gcc and enables it by default. OSVs can fix thekernel and > disable it by default. How widely is icc used? I ask because we have not encocuntered one customer using icc. We have huge numbers of customers using gcc, and many using proprietary compilers from Sun, DEC etc, but never an icc user? > > We can even issue a message whenever the workaround is used. > > H.J. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:14 ` H.J. Lu 2008-03-06 17:17 ` H. Peter Anvin @ 2008-03-06 17:18 ` Robert Dewar 2008-03-06 17:19 ` H. Peter Anvin 1 sibling, 1 reply; 98+ messages in thread From: Robert Dewar @ 2008-03-06 17:18 UTC (permalink / raw) To: H.J. Lu Cc: H. Peter Anvin, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc H.J. Lu wrote: > So that is the bug in the Linux kernel. Since fixing kernel is much easier > than providing a workaround in compilers, I think kernel should be fixed > and no need for icc/gcc fix. Fixing a bug in the Linux kernel is not "much easier". You are taking a purely engineering viewpoint, but life is not like that. There are lots of copies of Linux kernels around and in use. The issue is not fixing the kernel per se, it is propagating that change to all Linux kernels in use -- THAT'S another matter entirely, and is far far more difficult than making sure that a kernel fix is qualified and widely proopagated. > > > H.J. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:18 ` Robert Dewar @ 2008-03-06 17:19 ` H. Peter Anvin 2008-03-06 19:25 ` Robert Dewar 2008-03-07 8:00 ` Andreas Jaeger 0 siblings, 2 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 17:19 UTC (permalink / raw) To: Robert Dewar Cc: H.J. Lu, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Robert Dewar wrote: > H.J. Lu wrote: > >> So that is the bug in the Linux kernel. Since fixing kernel is much >> easier >> than providing a workaround in compilers, I think kernel should be fixed >> and no need for icc/gcc fix. > > Fixing a bug in the Linux kernel is not "much easier". You are taking > a purely engineering viewpoint, but life is not like that. There are > lots of copies of Linux kernels around and in use. The issue is not > fixing the kernel per se, it is propagating that change to all > Linux kernels in use -- THAT'S another matter entirely, and is > far far more difficult than making sure that a kernel fix is > qualified and widely proopagated. > Not really, it's just a matter of time. Typical distro cycles are on the order of 3 years. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:19 ` H. Peter Anvin @ 2008-03-06 19:25 ` Robert Dewar 2008-03-06 20:37 ` H. Peter Anvin 2008-03-07 8:28 ` Florian Weimer 2008-03-07 8:00 ` Andreas Jaeger 1 sibling, 2 replies; 98+ messages in thread From: Robert Dewar @ 2008-03-06 19:25 UTC (permalink / raw) To: H. Peter Anvin Cc: H.J. Lu, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc H. Peter Anvin wrote: > Robert Dewar wrote: >> H.J. Lu wrote: >> >>> So that is the bug in the Linux kernel. Since fixing kernel is much >>> easier >>> than providing a workaround in compilers, I think kernel should be fixed >>> and no need for icc/gcc fix. >> Fixing a bug in the Linux kernel is not "much easier". You are taking >> a purely engineering viewpoint, but life is not like that. There are >> lots of copies of Linux kernels around and in use. The issue is not >> fixing the kernel per se, it is propagating that change to all >> Linux kernels in use -- THAT'S another matter entirely, and is >> far far more difficult than making sure that a kernel fix is >> qualified and widely proopagated. >> > > Not really, it's just a matter of time. Typical distro cycles are on > the order of 3 years. > > -hpa again, in the real world, there are MANY projects that are nothing like this interactive when it comes to moving to new versions of operating systems. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 19:25 ` Robert Dewar @ 2008-03-06 20:37 ` H. Peter Anvin 2008-03-07 8:28 ` Florian Weimer 1 sibling, 0 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 20:37 UTC (permalink / raw) To: Robert Dewar Cc: H.J. Lu, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Robert Dewar wrote: >> >> Not really, it's just a matter of time. Typical distro cycles are on >> the order of 3 years. >> >> -hpa > > again, in the real world, there are MANY projects that are nothing > like this interactive when it comes to moving to new versions of > operating systems. This is true, but beyond a certain point projects generally accept that they have to monitor their toolchain dependencies. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 19:25 ` Robert Dewar 2008-03-06 20:37 ` H. Peter Anvin @ 2008-03-07 8:28 ` Florian Weimer 1 sibling, 0 replies; 98+ messages in thread From: Florian Weimer @ 2008-03-07 8:28 UTC (permalink / raw) To: Robert Dewar Cc: H. Peter Anvin, H.J. Lu, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc * Robert Dewar: > again, in the real world, there are MANY projects that are nothing > like this interactive when it comes to moving to new versions of > operating systems. Sure, but how many of those get to see software compiled with GCC 4.3? If this has any real impact, it's more likely to show up in current systems, where both kernel, libc and GCC are regularly updated, and GCC happens to receive an update before the kernel. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:19 ` H. Peter Anvin 2008-03-06 19:25 ` Robert Dewar @ 2008-03-07 8:00 ` Andreas Jaeger 1 sibling, 0 replies; 98+ messages in thread From: Andreas Jaeger @ 2008-03-07 8:00 UTC (permalink / raw) To: H. Peter Anvin Cc: Robert Dewar, H.J. Lu, Jakub Jelinek, NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc [-- Attachment #1: Type: text/plain, Size: 1308 bytes --] "H. Peter Anvin" <hpa@zytor.com> writes: > Robert Dewar wrote: >> H.J. Lu wrote: >> >>> So that is the bug in the Linux kernel. Since fixing kernel is much >>> easier >>> than providing a workaround in compilers, I think kernel should be fixed >>> and no need for icc/gcc fix. >> >> Fixing a bug in the Linux kernel is not "much easier". You are taking >> a purely engineering viewpoint, but life is not like that. There are >> lots of copies of Linux kernels around and in use. The issue is not >> fixing the kernel per se, it is propagating that change to all >> Linux kernels in use -- THAT'S another matter entirely, and is >> far far more difficult than making sure that a kernel fix is >> qualified and widely proopagated. >> > > Not really, it's just a matter of time. Typical distro cycles are on > the order of 3 years. But distros release fixes regularly for their kernels - and adding a fix for this issue with their next security update is something that is possible for distros (at least for openSUSE ;-), Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 [-- Attachment #2: Type: application/pgp-signature, Size: 193 bytes --] ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 15:37 ` NightStrike 2008-03-06 15:43 ` H.J. Lu @ 2008-03-06 15:57 ` Robert Dewar 2008-03-06 16:29 ` Paolo Bonzini 2008-03-06 17:18 ` H. Peter Anvin 1 sibling, 2 replies; 98+ messages in thread From: Robert Dewar @ 2008-03-06 15:57 UTC (permalink / raw) To: NightStrike Cc: Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc NightStrike wrote: > On 3/6/08, Olivier Galibert <galibert@pobox.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. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 15:57 ` Robert Dewar @ 2008-03-06 16:29 ` Paolo Bonzini 2008-03-06 17:18 ` H. Peter Anvin 1 sibling, 0 replies; 98+ messages in thread From: Paolo Bonzini @ 2008-03-06 16:29 UTC (permalink / raw) To: Robert Dewar Cc: NightStrike, Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc > 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. Not really. Just, no one used the BOUND instruction. All computers running DOS (Intel, AMD, even the old NEC V20/V30 chips) still connect INT 5 to Print Screen. Paolo ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 15:57 ` Robert Dewar 2008-03-06 16:29 ` Paolo Bonzini @ 2008-03-06 17:18 ` H. Peter Anvin 1 sibling, 0 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 17:18 UTC (permalink / raw) To: Robert Dewar Cc: NightStrike, Olivier Galibert, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Robert Dewar wrote: > > 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. IBM used it for print screen (and other calls), because Microsoft cassette BASIC used all the non-reserved INT instructions as byte codes (they cut it down to *only* half the interrupt vectors in the disk version.) We're still stuck with the consequences of that hack. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 13:51 ` Olivier Galibert ` (2 preceding siblings ...) 2008-03-06 15:37 ` NightStrike @ 2008-03-06 16:14 ` Artur Skawina 3 siblings, 0 replies; 98+ messages in thread From: Artur Skawina @ 2008-03-06 16:14 UTC (permalink / raw) To: Olivier Galibert, H. Peter Anvin, Chris Lattner, Michael Matz, Richard Guenther, Joe Buck, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Olivier Galibert 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. well, you could see this either way -- either the kernel is buggy and needs to be fixed or the current behavior is correct and the abi needs an errata. If there were no performance implications i'd go for the latter, mostly because of the security aspect. But this thread made me dig up an old benchmark and apparently omitting the cld before the string ops makes a significant difference; on P2 it was ~8%, on P4 it's ~6% for 1480 byte copies; for 32 byte ones the gain is more like 90% on a P4 [1]. So the impact on small structure memcpy/memset etc is significant, hence fixing the kernel looks like a better long term plan. artur [1] P4 # ./bcsp m IACCK 0.9.29 Artur Skawina <...> [ exec time; lower is better ] [speed ] [ time ] [ok?] TIME-N+S TIME32 TIME33 TIME1480 MBYTES/S TIMEXXXX CSUM FUNCTION ( rdtsc_overhead=0 null=0 ) 0 0 0 0 inf 0 ffff csum_partial_copy_null 1885 375 389 156 7589.74 39350 0 generic_memcpy 10894 532 666 1696 698.11 108557 0 kernel_memcpylib 1804 325 346 151 7841.06 19614 0 kernel_memcpy686 1804 325 346 151 7841.06 19693 0 kernel_memcpy686ncld 1744 323 381 148 8000.00 19687 0 kernel_memcpy686as1 1332 157 232 139 8517.99 19235 0 kernel_memcpy686as1ncld 1782 318 339 148 8000.00 19607 0 kernel_memcpy686as2 1371 168 189 139 8517.99 19221 0 kernel_memcpy686as2ncld P2 # ./bcsp m IACKK 0.9.28 Artur Skawina <...> TIME-N+S TIME32 TIME33 TIME1480 MBYTES/S TIMEXXXX CKSUM FUNCTION ( rdtsc_overhead=1 null=0 ) 0 0 0 0 inf 0 : ffff csum_partial_copy_null 7121 746 1215 730 1621.92 127418 : 0 generic_memcpy 43604 2032 1709 6574 180.10 416409 : 0 kernel_memcpylib 7480 771 726 684 1730.99 96084 : 0 kernel_memcpy686 7036 735 543 685 1728.47 95508 : 0 kernel_memcpy686ncld 7498 1015 711 716 1653.63 92200 : 0 kernel_memcpy686as1 5826 438 489 662 1788.52 91598 : 0 kernel_memcpy686as1ncld 6667 657 488 708 1672.32 89366 : 0 kernel_memcpy686as2 6614 456 270 658 1799.39 91203 : 0 kernel_memcpy686as2ncld ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 0:36 ` Chris Lattner 2008-03-06 0:47 ` H. Peter Anvin @ 2008-03-06 0:49 ` Aurelien Jarno 1 sibling, 0 replies; 98+ messages in thread From: Aurelien Jarno @ 2008-03-06 0:49 UTC (permalink / raw) To: Chris Lattner Cc: Michael Matz, H.Peter Anvin, Richard Guenther, Joe Buck, Jan Hubicka, linux-kernel, gcc Chris Lattner a écrit : >>>> 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: > > 1. User space has direction flag set. > 2. signal occurs > 3. kernel code is entered > 4. kernel code does string operation <boom> Wrong. Except maybe for the Hurd kernel. For other kernels: 4. signal handler is called 5. signal handler does string operation <boom> The GCC used to compile the kernel doesn't matter. Using gcc 4.3 to compile the user code triggers the bug. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag [not found] ` <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com> 2008-03-05 21:59 ` Michael Matz @ 2008-03-05 22:05 ` H. Peter Anvin 2008-03-06 2:11 ` Krzysztof Halasa 1 sibling, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 22:05 UTC (permalink / raw) To: Chris Lattner Cc: Richard Guenther, Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Chris Lattner wrote: > > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin 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? Not quite, but fixing it in the kernel is easy. Still breaks for running on all old kernels. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 22:05 ` H. Peter Anvin @ 2008-03-06 2:11 ` Krzysztof Halasa 0 siblings, 0 replies; 98+ messages in thread From: Krzysztof Halasa @ 2008-03-06 2:11 UTC (permalink / raw) To: H. Peter Anvin Cc: Chris Lattner, Richard Guenther, Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc "H. Peter Anvin" <hpa@zytor.com> writes: > Not quite, but fixing it in the kernel is easy. > > Still breaks for running on all old kernels. Many more things break on old kernels. I guess it's not worse than a (local) root exploit, is it? *-stable and distributions should take care of it, as they do in others cases. -- Krzysztof Halasa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:34 ` H. Peter Anvin ` (2 preceding siblings ...) [not found] ` <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com> @ 2008-03-06 8:44 ` Andi Kleen 2008-03-06 9:01 ` Jakub Jelinek 3 siblings, 1 reply; 98+ messages in thread From: Andi Kleen @ 2008-03-06 8:44 UTC (permalink / raw) To: H. Peter Anvin Cc: Richard Guenther, Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc "H. Peter Anvin" <hpa@zytor.com> writes: > 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()? That was the state with older gcc, but with newer gcc it does not necessarily reset the flag before the next function call. so e.g. if you have memmove(...) for (... very long loop .... ) { /* no function calls */ /* signals happen */ } the signal could see the direction flag -Andi ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 8:44 ` Andi Kleen @ 2008-03-06 9:01 ` Jakub Jelinek 2008-03-06 15:20 ` H. Peter Anvin 0 siblings, 1 reply; 98+ messages in thread From: Jakub Jelinek @ 2008-03-06 9:01 UTC (permalink / raw) To: Andi Kleen Cc: H. Peter Anvin, Richard Guenther, Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote: > "H. Peter Anvin" <hpa@zytor.com> writes: > > > 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()? > > That was the state with older gcc, but with newer gcc it does not necessarily > reset the flag before the next function call. > > so e.g. if you have > > memmove(...) > for (... very long loop .... ) { > /* no function calls */ > /* signals happen */ > } > > the signal could see the direction flag memmove is supposed to (and does) do a cld insn after it finishes the backward copying. Jakub ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 9:01 ` Jakub Jelinek @ 2008-03-06 15:20 ` H. Peter Anvin 0 siblings, 0 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 15:20 UTC (permalink / raw) To: Jakub Jelinek Cc: Andi Kleen, Richard Guenther, Joe Buck, Michael Matz, Jan Hubicka, Aurelien Jarno, linux-kernel, gcc Jakub Jelinek wrote: > On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote: >> "H. Peter Anvin" <hpa@zytor.com> writes: >> >>> 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()? >> That was the state with older gcc, but with newer gcc it does not necessarily >> reset the flag before the next function call. If so, that's a much worse bug. >> so e.g. if you have >> >> memmove(...) >> for (... very long loop .... ) { >> /* no function calls */ >> /* signals happen */ >> } >> >> the signal could see the direction flag > > memmove is supposed to (and does) do a cld insn after it finishes the > backward copying. You can still take a signal inside memmove() itself, of course. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:32 ` Richard Guenther 2008-03-05 21:34 ` H. Peter Anvin @ 2008-03-05 21:45 ` Aurelien Jarno 1 sibling, 0 replies; 98+ messages in thread From: Aurelien Jarno @ 2008-03-05 21:45 UTC (permalink / raw) To: Richard Guenther Cc: Joe Buck, Michael Matz, Jan Hubicka, H. Peter Anvin, linux-kernel, gcc Richard Guenther a écrit : > On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <Joe.Buck@synopsys.com> wrote: >> >> On Wed, 5 Mar 2008, Jan Hubicka wrote: >> > > Linux kernel is disabling red zone and use kernel code model, yet the >> > > ABI is not going to be adjusted for that. >> > > >> > > This is resonably easy to fix on kernel side in signal handling, or by >> > > removing std usage completely >> >> On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: >> > That is true. But it requires updating the kernel to a fixed one if you >> > want to run your programs compiled by 4.3 :-/ Not something we'd like to >> > demand. >> >> I changed the title just for emphasis. >> >> I think that we can't ship 4.3.0 if signal handlers on x86/x86_64 >> platforms for both Linux and BSD systems will mysteriously (to the users) >> fail, and it doesn't matter whose fault it is. > > We didn't yet run into this issue and build openSUSE with 4.3 since more than > three month. > The problem can be easily reproduced by using a glibc built with gcc 4.3, with SBCL (the gcc version doesn't matter). The signal handler in SBCL calls sigemptyset() which uses memset(). -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:20 ` RELEASE BLOCKER: " Joe Buck 2008-03-05 21:32 ` Richard Guenther @ 2008-03-05 21:43 ` Andrew Pinski 2008-03-05 21:43 ` Michael Matz 2 siblings, 0 replies; 98+ messages in thread From: Andrew Pinski @ 2008-03-05 21:43 UTC (permalink / raw) To: Joe Buck Cc: Michael Matz, Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc There are already gcc 4.3.0 packages on the FTP site. Sent from my iPhone On Mar 5, 2008, at 13:20, Joe Buck <Joe.Buck@synopsys.COM> wrote: > > > On Wed, 5 Mar 2008, Jan Hubicka wrote: >>> Linux kernel is disabling red zone and use kernel code model, yet >>> the >>> ABI is not going to be adjusted for that. >>> >>> This is resonably easy to fix on kernel side in signal handling, >>> or by >>> removing std usage completely > > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: >> That is true. But it requires updating the kernel to a fixed one >> if you >> want to run your programs compiled by 4.3 :-/ Not something we'd >> like to >> demand. > > I changed the title just for emphasis. > > I think that we can't ship 4.3.0 if signal handlers on x86/x86_64 > platforms for both Linux and BSD systems will mysteriously (to the > users) > fail, and it doesn't matter whose fault it is. > > ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:20 ` RELEASE BLOCKER: " Joe Buck 2008-03-05 21:32 ` Richard Guenther 2008-03-05 21:43 ` Andrew Pinski @ 2008-03-05 21:43 ` Michael Matz 2008-03-05 22:12 ` Joe Buck ` (2 more replies) 2 siblings, 3 replies; 98+ messages in thread From: Michael Matz @ 2008-03-05 21:43 UTC (permalink / raw) To: Joe Buck; +Cc: Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc Hi, On Wed, 5 Mar 2008, Joe Buck wrote: > > > On Wed, 5 Mar 2008, Jan Hubicka wrote: > > > Linux kernel is disabling red zone and use kernel code model, yet the > > > ABI is not going to be adjusted for that. > > > > > > This is resonably easy to fix on kernel side in signal handling, or by > > > removing std usage completely > > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: > > That is true. But it requires updating the kernel to a fixed one if you > > want to run your programs compiled by 4.3 :-/ Not something we'd like to > > demand. > > I changed the title just for emphasis. > > I think that we can't ship 4.3.0 if signal handlers on x86/x86_64 > platforms for both Linux and BSD systems will mysteriously (to the users) > fail, and it doesn't matter whose fault it is. FWIW I don't think it's a release blocker for 4.3.0. The error is arcane and happens seldomly if at all. And only on unfixed kernels. A program needs to do std explicitely, which most don't do _and_ get hit by a signal while begin in a std region. This happens so seldom that it didn't occur in building the next openSuSE 11.0, and it continually builds packages with 4.3 since months. It should be worked around in 4.3.1 if at all. Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:43 ` Michael Matz @ 2008-03-05 22:12 ` Joe Buck 2008-03-05 22:17 ` David Miller 2008-03-05 23:17 ` Olivier Galibert 2 siblings, 0 replies; 98+ messages in thread From: Joe Buck @ 2008-03-05 22:12 UTC (permalink / raw) To: Michael Matz Cc: Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote: > Hi, > > On Wed, 5 Mar 2008, Joe Buck wrote: > > > > > > > On Wed, 5 Mar 2008, Jan Hubicka wrote: > > > > Linux kernel is disabling red zone and use kernel code model, yet the > > > > ABI is not going to be adjusted for that. > > > > > > > > This is resonably easy to fix on kernel side in signal handling, or by > > > > removing std usage completely > > > > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: > > > That is true. But it requires updating the kernel to a fixed one if you > > > want to run your programs compiled by 4.3 :-/ Not something we'd like to > > > demand. > > > > I changed the title just for emphasis. > > > > I think that we can't ship 4.3.0 if signal handlers on x86/x86_64 > > platforms for both Linux and BSD systems will mysteriously (to the users) > > fail, and it doesn't matter whose fault it is. > > FWIW I don't think it's a release blocker for 4.3.0. The error is arcane > and happens seldomly if at all. And only on unfixed kernels. A program > needs to do std explicitely, which most don't do _and_ get hit by a signal > while begin in a std region. This happens so seldom that it didn't occur > in building the next openSuSE 11.0, and it continually builds packages > with 4.3 since months. > > It should be worked around in 4.3.1 if at all. OK, I suppose that I over-reacted, and it seems that the ship has sailed in any case. I agree that it's obscure, and I think that the only reason to worry is if it introduces a means of attack, which seems unlikely. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:43 ` Michael Matz 2008-03-05 22:12 ` Joe Buck @ 2008-03-05 22:17 ` David Miller 2008-03-05 23:17 ` Olivier Galibert 2 siblings, 0 replies; 98+ messages in thread From: David Miller @ 2008-03-05 22:17 UTC (permalink / raw) To: matz; +Cc: Joe.Buck, hubicka, aurelien, hpa, linux-kernel, gcc From: Michael Matz <matz@suse.de> Date: Wed, 5 Mar 2008 22:43:33 +0100 (CET) > The error is arcane and happens seldomly if at all. And only on > unfixed kernels. Which translates right now into "all kernels." ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 21:43 ` Michael Matz 2008-03-05 22:12 ` Joe Buck 2008-03-05 22:17 ` David Miller @ 2008-03-05 23:17 ` Olivier Galibert 2008-03-05 23:21 ` David Daney 2 siblings, 1 reply; 98+ messages in thread From: Olivier Galibert @ 2008-03-05 23:17 UTC (permalink / raw) To: Michael Matz Cc: Joe Buck, Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote: > FWIW I don't think it's a release blocker for 4.3.0. The error is arcane > and happens seldomly if at all. And only on unfixed kernels. A program > needs to do std explicitely, which most don't do _and_ get hit by a signal > while begin in a std region. This happens so seldom that it didn't occur > in building the next openSuSE 11.0, and it continually builds packages > with 4.3 since months. How would you know whether it has happened? OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 23:17 ` Olivier Galibert @ 2008-03-05 23:21 ` David Daney 2008-03-06 14:06 ` Olivier Galibert 0 siblings, 1 reply; 98+ messages in thread From: David Daney @ 2008-03-05 23:21 UTC (permalink / raw) To: Olivier Galibert, Michael Matz, Joe Buck, Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc Olivier Galibert wrote: > On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote: >> FWIW I don't think it's a release blocker for 4.3.0. The error is arcane >> and happens seldomly if at all. And only on unfixed kernels. A program >> needs to do std explicitely, which most don't do _and_ get hit by a signal >> while begin in a std region. This happens so seldom that it didn't occur >> in building the next openSuSE 11.0, and it continually builds packages >> with 4.3 since months. > > How would you know whether it has happened? > The same way you do with other bugs: You would observe unexpected behavior. In this case probably either corrupted memory or a SIGSEGV. David Daney ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 23:21 ` David Daney @ 2008-03-06 14:06 ` Olivier Galibert 2008-03-08 19:10 ` Alexandre Oliva 0 siblings, 1 reply; 98+ messages in thread From: Olivier Galibert @ 2008-03-06 14:06 UTC (permalink / raw) To: David Daney Cc: Michael Matz, Joe Buck, Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Wed, Mar 05, 2008 at 03:21:43PM -0800, David Daney wrote: > Olivier Galibert wrote: > >On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote: > >>FWIW I don't think it's a release blocker for 4.3.0. The error is arcane > >>and happens seldomly if at all. And only on unfixed kernels. A program > >>needs to do std explicitely, which most don't do _and_ get hit by a > >>signal while begin in a std region. This happens so seldom that it > >>didn't occur in building the next openSuSE 11.0, and it continually > >>builds packages with 4.3 since months. > > > >How would you know whether it has happened? > > > > The same way you do with other bugs: You would observe unexpected behavior. > > In this case probably either corrupted memory or a SIGSEGV. So that probably means the programs you use for compiling packages probably aren't hit. Doesn't mean the packages you've compiled with it aren't hit. Compiling packages doesn't test what's in them at all. It's extremely rare, no doubt about it. It's just that it *yells* security issue in the making. It's not a source bug, i.e. not easily reviewable. It's related to signal handlers which are the mark of a server and/or more failure-conscious program than usual. It's obscure (breaking a stringop, probably memset, or a not-paranoid-enough inline asm in a signal handler through a running memmove in the main program, oh my) but reasonably predictable for someone looking for an exploitable flaw. It's gcc's job to adapt to the realities of its running environment, not the other way around. OG. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 14:06 ` Olivier Galibert @ 2008-03-08 19:10 ` Alexandre Oliva 0 siblings, 0 replies; 98+ messages in thread From: Alexandre Oliva @ 2008-03-08 19:10 UTC (permalink / raw) To: Olivier Galibert Cc: David Daney, Michael Matz, Joe Buck, Jan Hubicka, Aurelien Jarno, H. Peter Anvin, linux-kernel, gcc On Mar 6, 2008, Olivier Galibert <galibert@pobox.com> wrote: > It's extremely rare, no doubt about it. It's just that it *yells* > security issue in the making. It's not a source bug, i.e. not easily > reviewable. It's related to signal handlers which are the mark of a > server and/or more failure-conscious program than usual. It's obscure > (breaking a stringop, probably memset, or a not-paranoid-enough inline > asm in a signal handler through a running memmove in the main program, > oh my) but reasonably predictable for someone looking for an > exploitable flaw. > It's gcc's job to adapt to the realities of its running environment, > not the other way around. I smell a false dilemma here. The problem doesn't have to be fixed/worked-around in either the kernel or GCC. Per your argument, one might claim it's the userland library's, or even the application's job to adapt to the realities of its running environment. GCC doesn't know what functions are signal handlers to insert cld in them. How could it fix the problem, then? How could it possibly fix custom assembly? How could it possibly fix object code containing signal handlers, compiled by other compilers? A userland system library, in theory, knows what functions are signal handlers. It could wrap function pointers passed as arguments to signal() such that they get cld. But then, applications that couldn't care less about this would take a hit. Applications, on the other hand, know when they might need cld. So, per your argument, they should adapt to the realities of their running environment, and add asm("cld"); to signal handlers that might need it. At times, it may be hard for them to know whether they need it, because too many factors may affect this need. E.g.: - if the kernel does cld for them, then they don't need it. But that's a run-time property, so it can't be tested at build time: the code may run on a different kernel that doesn't do it. - if none of the libraries they use mess with this flag, or none of the libraries they use from signal handlers depend on this flag, then they don't need it. But then, again, libraries may vary over time, and you can't assume the (dynamic) library that's available at build time will behave the same way at run time. So an application would have to do it conservatively, adding cld to their signal handlers just in case. But then, it would be more convenient if the library did it. And then, by the same argument, it would be more convenient if the kernel did it. (Compiler can't do it, since it doesn't know what's a signal handler in the general case.) And that's an argument to support the ABI specs as they are. It would be just silly to try to work around this deviation from the specs, at a performance penalty, in every affected compiler, library *and* application. And anything less than fixing all of them would be an incomplete work around. Which is not an argument against providing work arounds where possible, just an argument in favor of fixing the problem where it can be fixed for good. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:49 ` Jan Hubicka 2008-03-05 21:02 ` Michael Matz @ 2008-03-05 21:07 ` H. Peter Anvin 1 sibling, 0 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 21:07 UTC (permalink / raw) To: Jan Hubicka; +Cc: Joe Buck, Michael Matz, Aurelien Jarno, linux-kernel, gcc Jan Hubicka wrote: >> Yes, if there are four kernels that get it "wrong", that effectively means >> that the ABI document doesn't describe reality and gcc has to adjust. > > Kernels almost never follow ABI used by applications to last detail. > Linux kernel is disabling red zone and use kernel code model, yet the > ABI is not going to be adjusted for that. > > This is resonably easy to fix on kernel side in signal handling, or by > removing std usage completely (I believe it is not performance win, but > some benchmarking would be needed to double check) That's not the issue. The issue is that the kernel leaks the DF from the code that took a signal to the signal handler. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:38 ` Michael Matz 2008-03-05 20:42 ` Joe Buck @ 2008-03-05 20:44 ` H. Peter Anvin 2008-03-05 20:52 ` Aurelien Jarno 1 sibling, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 20:44 UTC (permalink / raw) To: Michael Matz; +Cc: Aurelien Jarno, Joe Buck, linux-kernel, gcc Michael Matz wrote: > Hi, > > 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. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:44 ` H. Peter Anvin @ 2008-03-05 20:52 ` Aurelien Jarno 2008-03-05 21:23 ` David Miller 2008-03-06 9:53 ` Andrew Haley 0 siblings, 2 replies; 98+ messages in thread From: Aurelien Jarno @ 2008-03-05 20:52 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Michael Matz, Joe Buck, linux-kernel, gcc H. Peter Anvin a écrit : > Michael Matz wrote: >> Hi, >> >> 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. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:52 ` Aurelien Jarno @ 2008-03-05 21:23 ` David Miller 2008-03-06 9:53 ` Andrew Haley 1 sibling, 0 replies; 98+ messages in thread From: David Miller @ 2008-03-05 21:23 UTC (permalink / raw) To: aurelien; +Cc: hpa, matz, Joe.Buck, linux-kernel, gcc From: Aurelien Jarno <aurelien@aurel32.net> Date: Wed, 05 Mar 2008 21:52:14 +0100 > H. Peter Anvin a écrit : > > 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. I don't think this approach is tenable. If a distribution should ship with a "fixed" kernel and compiler enabling the new direction flag behavior, any binary you create on that system will be broken on any other existing system. I think we really are stuck with this forever, overwhelming practice over the past 15 years has dictated to us what the real ABI is. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:52 ` Aurelien Jarno 2008-03-05 21:23 ` David Miller @ 2008-03-06 9:53 ` Andrew Haley 2008-03-06 11:45 ` Andi Kleen 1 sibling, 1 reply; 98+ messages in thread From: Andrew Haley @ 2008-03-06 9:53 UTC (permalink / raw) To: Aurelien Jarno; +Cc: H. Peter Anvin, Michael Matz, Joe Buck, linux-kernel, gcc 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. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 9:53 ` Andrew Haley @ 2008-03-06 11:45 ` Andi Kleen 2008-03-06 12:06 ` Richard Guenther 0 siblings, 1 reply; 98+ messages in thread From: Andi Kleen @ 2008-03-06 11:45 UTC (permalink / raw) To: Andrew Haley Cc: Aurelien Jarno, H. Peter Anvin, Michael Matz, Joe Buck, linux-kernel, gcc Andrew Haley <aph@redhat.com> writes: > > 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. You seem to assume that running a gcc 4.3 compiled binary requires a gcc update. That is not necessarily true. -Andi ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 11:45 ` Andi Kleen @ 2008-03-06 12:06 ` Richard Guenther 2008-03-06 17:34 ` Joe Buck 0 siblings, 1 reply; 98+ messages in thread From: Richard Guenther @ 2008-03-06 12:06 UTC (permalink / raw) To: Andi Kleen Cc: Andrew Haley, Aurelien Jarno, H. Peter Anvin, Michael Matz, Joe Buck, linux-kernel, gcc On 06 Mar 2008 12:45:57 +0100, Andi Kleen <andi@firstfloor.org> wrote: > Andrew Haley <aph@redhat.com> writes: > > > > 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. > > You seem to assume that running a gcc 4.3 compiled binary requires a > gcc update. That is not necessarily true. It (sometimes) requires a libgcc and libstdc++ update. Richard. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 12:06 ` Richard Guenther @ 2008-03-06 17:34 ` Joe Buck 2008-03-06 20:54 ` Richard Guenther 0 siblings, 1 reply; 98+ messages in thread From: Joe Buck @ 2008-03-06 17:34 UTC (permalink / raw) To: Richard Guenther Cc: Andi Kleen, Andrew Haley, Aurelien Jarno, H. Peter Anvin, Michael Matz, linux-kernel, gcc On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote: > On 06 Mar 2008 12:45:57 +0100, Andi Kleen <andi@firstfloor.org> wrote: > > Andrew Haley <aph@redhat.com> writes: > > > > > > 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. > > > > You seem to assume that running a gcc 4.3 compiled binary requires a > > gcc update. That is not necessarily true. > > It (sometimes) requires a libgcc and libstdc++ update. "Sometimes" is correct; many users commonly run newer compilers on older distros, with LD_LIBRARY_PATH set to pick up the correct C++ support library. This is particularly common on servers, where you don't want to mess with a working system but you might need to run newer code. So, we've been arguing for a while, so the question is what to do. Using a principle based on the old IETF concept of being liberal in what you accept, and conservative in what you send, I think that both the Linux kernel and gcc should fix the problem. The kernel should fix the information leak, and gcc should remove the assumption that the direction flag is set in a given direction on function entry. The gcc patch will be too late for 4.3.0, but it would be on the 4.3 branch, and we would recommend that distros pick it up for any compilers they ship. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 17:34 ` Joe Buck @ 2008-03-06 20:54 ` Richard Guenther 2008-03-06 20:56 ` H. Peter Anvin 0 siblings, 1 reply; 98+ messages in thread From: Richard Guenther @ 2008-03-06 20:54 UTC (permalink / raw) To: Joe Buck Cc: Andi Kleen, Andrew Haley, Aurelien Jarno, H. Peter Anvin, Michael Matz, linux-kernel, gcc On Thu, Mar 6, 2008 at 6:34 PM, Joe Buck <Joe.Buck@synopsys.com> wrote: > > On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote: > > On 06 Mar 2008 12:45:57 +0100, Andi Kleen <andi@firstfloor.org> wrote: > > > Andrew Haley <aph@redhat.com> writes: > > > > > > > > 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. > > > > > > You seem to assume that running a gcc 4.3 compiled binary requires a > > > gcc update. That is not necessarily true. > > > > It (sometimes) requires a libgcc and libstdc++ update. > > "Sometimes" is correct; many users commonly run newer compilers on older > distros, with LD_LIBRARY_PATH set to pick up the correct C++ support > library. This is particularly common on servers, where you don't want to > mess with a working system but you might need to run newer code. > > So, we've been arguing for a while, so the question is what to do. > > Using a principle based on the old IETF concept of being liberal in what > you accept, and conservative in what you send, I think that both the Linux > kernel and gcc should fix the problem. The kernel should fix the > information leak, and gcc should remove the assumption that the direction > flag is set in a given direction on function entry. > > The gcc patch will be too late for 4.3.0, but it would be on the 4.3 > branch, and we would recommend that distros pick it up for any compilers > they ship. A patched GCC IMHO makes only sense if it is always-on, yet another option won't help in corner cases. And corner cases is exactly what people seem to care about. For this reason that we have this single release, 4.3.0, that behaves "bad" is already a problem. Richard. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 20:54 ` Richard Guenther @ 2008-03-06 20:56 ` H. Peter Anvin 2008-03-06 22:06 ` Andi Kleen 0 siblings, 1 reply; 98+ messages in thread From: H. Peter Anvin @ 2008-03-06 20:56 UTC (permalink / raw) To: Richard Guenther Cc: Joe Buck, Andi Kleen, Andrew Haley, Aurelien Jarno, Michael Matz, linux-kernel, gcc Richard Guenther wrote: > > A patched GCC IMHO makes only sense if it is always-on, yet another option > won't help in corner cases. And corner cases is exactly what people seem > to care about. For this reason that we have this single release, 4.3.0, that > behaves "bad" is already a problem. > The option will help embedded vendors who can guarantee that it's not a problem. -hpa ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 20:56 ` H. Peter Anvin @ 2008-03-06 22:06 ` Andi Kleen 2008-03-07 4:56 ` Chris Lattner 2008-03-07 14:09 ` Michael Matz 0 siblings, 2 replies; 98+ messages in thread From: Andi Kleen @ 2008-03-06 22:06 UTC (permalink / raw) To: H. Peter Anvin Cc: Richard Guenther, Joe Buck, Andi Kleen, Andrew Haley, Aurelien Jarno, Michael Matz, linux-kernel, gcc On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote: > Richard Guenther wrote: > > > >A patched GCC IMHO makes only sense if it is always-on, yet another option > >won't help in corner cases. And corner cases is exactly what people seem > >to care about. For this reason that we have this single release, 4.3.0, > >that > >behaves "bad" is already a problem. > > > > The option will help embedded vendors who can guarantee that it's not a > problem. For very very low values of "help". To be realistic it is very unlikely anybody will measure a difference from a few more or a few less clds in a program. It's not that they're expensive instructions and they normally don't happen in inner loops either. "If you enable this option you will get an optimization that you cannot measure" @) -Andi ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 22:06 ` Andi Kleen @ 2008-03-07 4:56 ` Chris Lattner 2008-03-07 14:09 ` Michael Matz 1 sibling, 0 replies; 98+ messages in thread From: Chris Lattner @ 2008-03-07 4:56 UTC (permalink / raw) To: Andi Kleen Cc: H. Peter Anvin, Richard Guenther, Joe Buck, Andrew Haley, Aurelien Jarno, Michael Matz, linux-kernel, gcc On Mar 6, 2008, at 2:06 PM, Andi Kleen wrote: > On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote: >> Richard Guenther wrote: >>> >>> A patched GCC IMHO makes only sense if it is always-on, yet >>> another option >>> won't help in corner cases. And corner cases is exactly what >>> people seem >>> to care about. For this reason that we have this single release, >>> 4.3.0, >>> that >>> behaves "bad" is already a problem. >>> >> >> The option will help embedded vendors who can guarantee that it's >> not a >> problem. > > For very very low values of "help". > > To be realistic it is very unlikely anybody will measure a difference > from a few more or a few less clds in a program. It's not that they're > expensive instructions They aren't? According to http://www.agner.org/optimize/instruction_tables.pdf , they have a latency of 52 cycles on at least one popular x86 chip. -Chris ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-06 22:06 ` Andi Kleen 2008-03-07 4:56 ` Chris Lattner @ 2008-03-07 14:09 ` Michael Matz 1 sibling, 0 replies; 98+ messages in thread From: Michael Matz @ 2008-03-07 14:09 UTC (permalink / raw) To: Andi Kleen Cc: H. Peter Anvin, Richard Guenther, Joe Buck, Andrew Haley, Aurelien Jarno, linux-kernel, gcc Hi, On Thu, 6 Mar 2008, Andi Kleen wrote: > To be realistic it is very unlikely anybody will measure a difference > from a few more or a few less clds in a program. Only an assumption, and in fact wrong. See upthread for a benchmark. IIRC Uros also made measurements to justify the removal of cld (on P4 I think), where it helps tremendously on small memcpy loops. Ciao, Michael. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 20:23 ` Aurelien Jarno 2008-03-05 20:38 ` Michael Matz @ 2008-03-06 9:45 ` Mikael Pettersson 1 sibling, 0 replies; 98+ messages in thread From: Mikael Pettersson @ 2008-03-06 9:45 UTC (permalink / raw) To: Aurelien Jarno; +Cc: Joe Buck, H. Peter Anvin, linux-kernel, gcc Aurelien Jarno writes: > On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote: > > > > Aurelien Jarno wrote: > > > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 > > > >ABI and the direction flag, that is it now assumes that the direction > > > >flag is cleared at the entry of a function and it doesn't clear once > > > >more if needed. > > > >... > > > >I guess this has to be fixed on the kernel side, but also gcc-4.3 could > > > >revert back to the old behaviour, that is clearing the direction flag > > > >when entering a routine that touches it until most people are running a > > > >fixed kernel. > > > > On Wed, Mar 05, 2008 at 08:00:42AM -0800, H. Peter Anvin wrote: > > > Linux should definitely follow the ABI. This is a bug, and a pretty > > > serious such. > > > > Unfortunately, there are a lot of kernels out there already with this > > problem, and the symptoms are likely to be subtle. So even if it is true > > that it is the kernel that is "in the wrong", I think we still are going > > to need to give users a workaround from the gcc side as well. > > > > 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. FWIW, Solaris 10 (both 32- and 64-bit) gets it right. ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag 2008-03-05 15:30 Linux doesn't follow x86/x86-64 ABI wrt direction flag Aurelien Jarno 2008-03-05 16:00 ` H. Peter Anvin @ 2008-03-05 16:56 ` H.J. Lu 2008-03-05 18:14 ` [PATCH] x86: Clear DF before calling signal handler Aurelien Jarno 2 siblings, 0 replies; 98+ messages in thread From: H.J. Lu @ 2008-03-05 16:56 UTC (permalink / raw) To: Aurelien Jarno, linux-kernel, gcc Hi, According to i386 psABI, --- The direction flag must be set "forward" direction before entry and upon exit from a function. --- So, asm statement should make sure that the direction flag is cleared before function returns and kernel should make sure that the direction flag is cleared when calling a signal handler. H.J. On Wed, Mar 5, 2008 at 7:30 AM, Aurelien Jarno <aurelien@aurel32.net> wrote: > Hi all, > > Since version 4.3, gcc changed its behaviour concerning the x86/x86-64 > ABI and the direction flag, that is it now assumes that the direction > flag is cleared at the entry of a function and it doesn't clear once > more if needed. > > This causes some problems with the Linux kernel which does not clear > the direction flag when entering a signal handler. The small code below > (for x86-64) demonstrates that. > > If the signal handler is using code that need the direction flag cleared > (for example bzero() or memset()), the code is incorrectly executed. > > I guess this has to be fixed on the kernel side, but also gcc-4.3 could > revert back to the old behaviour, that is clearing the direction flag > when entering a routine that touches it until most people are running a > fixed kernel. > > Kind regards, > Aurelien > > [1] http://gcc.gnu.org/gcc-4.3/changes.html > > > #include <stdint.h> > #include <stdlib.h> > #include <stdio.h> > #include <signal.h> > > void handler(int signal) { > uint64_t rflags; > > asm volatile("pushfq ; popq %0" : "=g" (rflags)); > > if (rflags & (1 << 10)) > printf("DF = 1\n"); > else > printf("DF = 0\n"); > } > > int main() { > signal(SIGUSR1, handler); > > while(1) > { > asm volatile("std\r\n"); > } > > return 0; > } > > -- > .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 > : :' : Debian developer | Electrical Engineer > `. `' aurel32@debian.org | aurelien@aurel32.net > `- people.debian.org/~aurel32 | www.aurel32.net > ^ permalink raw reply [flat|nested] 98+ messages in thread
* [PATCH] x86: Clear DF before calling signal handler 2008-03-05 15:30 Linux doesn't follow x86/x86-64 ABI wrt direction flag Aurelien Jarno 2008-03-05 16:00 ` H. Peter Anvin 2008-03-05 16:56 ` H.J. Lu @ 2008-03-05 18:14 ` Aurelien Jarno 2008-03-05 18:17 ` H. Peter Anvin 2008-03-06 9:21 ` Ingo Molnar 2 siblings, 2 replies; 98+ messages in thread From: Aurelien Jarno @ 2008-03-05 18:14 UTC (permalink / raw) To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin; +Cc: linux-kernel The Linux kernel currently does not clear the direction flag before calling a signal handler, whereas the x86/x86-64 ABI requires that. This become a real problem with gcc version 4.3, which assumes that the direction flag is correctly cleared at the entry of a function. This patches changes the setup_frame() functions to clear the direction before entering the signal handler. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> --- arch/x86/ia32/ia32_signal.c | 4 ++-- arch/x86/kernel/signal_32.c | 4 ++-- arch/x86/kernel/signal_64.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c index 1c0503b..5e7771a 100644 --- a/arch/x86/ia32/ia32_signal.c +++ b/arch/x86/ia32/ia32_signal.c @@ -500,7 +500,7 @@ int ia32_setup_frame(int sig, struct k_sigaction *ka, regs->ss = __USER32_DS; set_fs(USER_DS); - regs->flags &= ~X86_EFLAGS_TF; + regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF); if (test_thread_flag(TIF_SINGLESTEP)) ptrace_notify(SIGTRAP); @@ -600,7 +600,7 @@ int ia32_setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info, regs->ss = __USER32_DS; set_fs(USER_DS); - regs->flags &= ~X86_EFLAGS_TF; + regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF); if (test_thread_flag(TIF_SINGLESTEP)) ptrace_notify(SIGTRAP); diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c index caee1f0..0157a6f 100644 --- a/arch/x86/kernel/signal_32.c +++ b/arch/x86/kernel/signal_32.c @@ -407,7 +407,7 @@ static int setup_frame(int sig, struct k_sigaction *ka, * The tracer may want to single-step inside the * handler too. */ - regs->flags &= ~TF_MASK; + regs->flags &= ~(TF_MASK | X86_EFLAGS_DF); if (test_thread_flag(TIF_SINGLESTEP)) ptrace_notify(SIGTRAP); @@ -500,7 +500,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info, * The tracer may want to single-step inside the * handler too. */ - regs->flags &= ~TF_MASK; + regs->flags &= ~(TF_MASK | X86_EFLAGS_DF); if (test_thread_flag(TIF_SINGLESTEP)) ptrace_notify(SIGTRAP); diff --git a/arch/x86/kernel/signal_64.c b/arch/x86/kernel/signal_64.c index 7347bb1..56b72fb 100644 --- a/arch/x86/kernel/signal_64.c +++ b/arch/x86/kernel/signal_64.c @@ -295,7 +295,7 @@ static int setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info, see include/asm-x86_64/uaccess.h for details. */ set_fs(USER_DS); - regs->flags &= ~X86_EFLAGS_TF; + regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF); if (test_thread_flag(TIF_SINGLESTEP)) ptrace_notify(SIGTRAP); #ifdef DEBUG_SIG -- 1.5.4.3 -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net ^ permalink raw reply related [flat|nested] 98+ messages in thread
* Re: [PATCH] x86: Clear DF before calling signal handler 2008-03-05 18:14 ` [PATCH] x86: Clear DF before calling signal handler Aurelien Jarno @ 2008-03-05 18:17 ` H. Peter Anvin 2008-03-06 9:21 ` Ingo Molnar 1 sibling, 0 replies; 98+ messages in thread From: H. Peter Anvin @ 2008-03-05 18:17 UTC (permalink / raw) To: Aurelien Jarno, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-kernel Aurelien Jarno wrote: > The Linux kernel currently does not clear the direction flag before > calling a signal handler, whereas the x86/x86-64 ABI requires that. > This become a real problem with gcc version 4.3, which assumes that > the direction flag is correctly cleared at the entry of a function. > > This patches changes the setup_frame() functions to clear the > direction before entering the signal handler. > > Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Acked-by: H. Peter Anvin <hpa@zytor.com> ^ permalink raw reply [flat|nested] 98+ messages in thread
* Re: [PATCH] x86: Clear DF before calling signal handler 2008-03-05 18:14 ` [PATCH] x86: Clear DF before calling signal handler Aurelien Jarno 2008-03-05 18:17 ` H. Peter Anvin @ 2008-03-06 9:21 ` Ingo Molnar 1 sibling, 0 replies; 98+ messages in thread From: Ingo Molnar @ 2008-03-06 9:21 UTC (permalink / raw) To: Aurelien Jarno, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, linux-kernel * Aurelien Jarno <aurelien@aurel32.net> wrote: > The Linux kernel currently does not clear the direction flag before > calling a signal handler, whereas the x86/x86-64 ABI requires that. > This become a real problem with gcc version 4.3, which assumes that > the direction flag is correctly cleared at the entry of a function. > > This patches changes the setup_frame() functions to clear the > direction before entering the signal handler. thanks, applied. Ingo ^ permalink raw reply [flat|nested] 98+ messages in thread
end of thread, other threads:[~2008-03-08 19:12 UTC | newest] Thread overview: 98+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-03-05 15:30 Linux doesn't follow x86/x86-64 ABI wrt direction flag Aurelien Jarno 2008-03-05 16:00 ` H. Peter Anvin 2008-03-05 19:58 ` Joe Buck 2008-03-05 20:23 ` Aurelien Jarno 2008-03-05 20:38 ` Michael Matz 2008-03-05 20:42 ` Joe Buck 2008-03-05 20:49 ` Jan Hubicka 2008-03-05 21:02 ` Michael Matz 2008-03-05 21:20 ` RELEASE BLOCKER: " Joe Buck 2008-03-05 21:32 ` Richard Guenther 2008-03-05 21:34 ` H. Peter Anvin 2008-03-05 21:40 ` Richard Guenther 2008-03-05 22:16 ` David Miller 2008-03-05 22:37 ` Joe Buck 2008-03-05 22:51 ` Michael Matz 2008-03-05 22:58 ` H. Peter Anvin 2008-03-05 23:07 ` Michael Matz 2008-03-05 23:10 ` David Miller 2008-03-05 23:16 ` Joe Buck 2008-03-05 23:12 ` Olivier Galibert 2008-03-05 21:43 ` Joe Buck 2008-03-05 21:44 ` Richard Guenther [not found] ` <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com> 2008-03-05 21:59 ` Michael Matz 2008-03-05 22:13 ` Adrian Bunk 2008-03-05 22:21 ` David Miller 2008-03-05 23:13 ` Olivier Galibert 2008-03-06 0:36 ` Chris Lattner 2008-03-06 0:47 ` H. Peter Anvin [not found] ` <578FCA7D-D7A6-44F6-9310-4A97C13CDCBE@apple.com> 2008-03-06 1:12 ` H. Peter Anvin 2008-03-06 9:17 ` Jakub Jelinek 2008-03-06 13:51 ` Olivier Galibert 2008-03-06 14:03 ` Paolo Bonzini 2008-03-06 14:12 ` Olivier Galibert 2008-03-06 14:15 ` Andrew Haley 2008-03-06 17:58 ` Joe Buck 2008-03-06 18:10 ` Olivier Galibert 2008-03-06 18:13 ` Paolo Bonzini 2008-03-06 18:31 ` Jack Lloyd 2008-03-06 18:35 ` Andrew Pinski 2008-03-06 19:44 ` Paolo Bonzini 2008-03-06 19:43 ` Paolo Bonzini 2008-03-06 20:16 ` Jack Lloyd 2008-03-06 21:37 ` Artur Skawina 2008-03-06 15:09 ` Robert Dewar 2008-03-06 15:37 ` NightStrike 2008-03-06 15:43 ` H.J. Lu 2008-03-06 15:50 ` H. Peter Anvin 2008-03-06 16:23 ` Jakub Jelinek 2008-03-06 16:27 ` İsmail Dönmez 2008-03-06 16:58 ` H.J. Lu 2008-03-06 17:06 ` H. Peter Anvin 2008-03-06 17:14 ` H.J. Lu 2008-03-06 17:17 ` H. Peter Anvin 2008-03-06 17:34 ` H.J. Lu 2008-03-06 19:35 ` Robert Dewar 2008-03-06 17:18 ` Robert Dewar 2008-03-06 17:19 ` H. Peter Anvin 2008-03-06 19:25 ` Robert Dewar 2008-03-06 20:37 ` H. Peter Anvin 2008-03-07 8:28 ` Florian Weimer 2008-03-07 8:00 ` Andreas Jaeger 2008-03-06 15:57 ` Robert Dewar 2008-03-06 16:29 ` Paolo Bonzini 2008-03-06 17:18 ` H. Peter Anvin 2008-03-06 16:14 ` Artur Skawina 2008-03-06 0:49 ` Aurelien Jarno 2008-03-05 22:05 ` H. Peter Anvin 2008-03-06 2:11 ` Krzysztof Halasa 2008-03-06 8:44 ` Andi Kleen 2008-03-06 9:01 ` Jakub Jelinek 2008-03-06 15:20 ` H. Peter Anvin 2008-03-05 21:45 ` Aurelien Jarno 2008-03-05 21:43 ` Andrew Pinski 2008-03-05 21:43 ` Michael Matz 2008-03-05 22:12 ` Joe Buck 2008-03-05 22:17 ` David Miller 2008-03-05 23:17 ` Olivier Galibert 2008-03-05 23:21 ` David Daney 2008-03-06 14:06 ` Olivier Galibert 2008-03-08 19:10 ` Alexandre Oliva 2008-03-05 21:07 ` H. Peter Anvin 2008-03-05 20:44 ` H. Peter Anvin 2008-03-05 20:52 ` Aurelien Jarno 2008-03-05 21:23 ` David Miller 2008-03-06 9:53 ` Andrew Haley 2008-03-06 11:45 ` Andi Kleen 2008-03-06 12:06 ` Richard Guenther 2008-03-06 17:34 ` Joe Buck 2008-03-06 20:54 ` Richard Guenther 2008-03-06 20:56 ` H. Peter Anvin 2008-03-06 22:06 ` Andi Kleen 2008-03-07 4:56 ` Chris Lattner 2008-03-07 14:09 ` Michael Matz 2008-03-06 9:45 ` Mikael Pettersson 2008-03-05 16:56 ` H.J. Lu 2008-03-05 18:14 ` [PATCH] x86: Clear DF before calling signal handler Aurelien Jarno 2008-03-05 18:17 ` H. Peter Anvin 2008-03-06 9:21 ` Ingo Molnar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).