| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Why is this a problem?
Why is this a problem?
Posted Mar 7, 2008 22:46 UTC (Fri) by mgb (subscriber, #3226)Parent article: GCC 4.3.0 exposes a kernel bug
The last para of Jake's article implies that upgrading GCC or installing GCC 4.3.0 compiled binaries can cause problems. If true that would be nasty. ONE: The zero-cost patch needs to be applied to the kernel source before compiling the kernel with GCC 4.3.0. TWO: Don't load 4.3.0-compiled out of tree kernel modules into unpatched kernels. Color my stupid but I just don't see how upgrading GCC or installing binaries can trigger this problem. Am I missing something?
(Log in to post comments)
Why is this a problem?
Posted Mar 7, 2008 22:59 UTC (Fri) by jake (editor, #205) [Link]
> Am I missing something? This problem has nothing to do with building the kernel. It is in building user space applications. So, installing GCC 4.3.0 or a binary built with it on any Linux (or evidently BSD) kernel released could trigger the problem. If it does memory/string operations in signal handlers anyway. jake
Why is this a problem?
Posted Mar 7, 2008 23:20 UTC (Fri) by mgb (subscriber, #3226) [Link]
Thanks Jake. My bad. I read "signal handler" and thought "interrupt handler".
Why is this a problem?
Posted Mar 7, 2008 23:58 UTC (Fri) by vonbrand (subscriber, #4458) [Link]
No, it has nothing to do with calling mem<foo> in a signal handler. The point is that said functions may set the DF flag, and before it is reset a signal may come in. The signal handler then could run with the flag set, expecting it to be unset. A few instructions inspect this flag.
Why is this a problem?
Posted Mar 8, 2008 0:27 UTC (Sat) by jake (editor, #205) [Link]
> No, it has nothing to do with calling mem<foo> in a signal handler. What I was trying to say is that it would be a memmove() or something like it in the signal handler that would be tripped up by DF being set unexpectedly. jake
Why is this a problem?
Posted Mar 19, 2008 22:33 UTC (Wed) by klossner (guest, #30046) [Link]
> No, it has nothing to do with calling mem<foo> in a signal handler. Sure it does. If the signal handler call was compiled with the new GCC, then it will expect the flag to be clear on entry. If the flag happens to be set and the signal handler calls mem<foo>, the copy will go backward. This can be exploited.