Please read the article [LWN.net]

Please read the article

Posted Mar 13, 2008 9:00 UTC (Thu) by roblucid (subscriber, #48964)
In reply to: Please read the article by tialaramex
Parent article: GCC 4.3.0 exposes a kernel bug

No I do get that when programs have been compiled with gcc < 4.3 they 
clear the bit.  It's just that applications suffering obscure memory 
corruption when memory operations go wrong, and a leaking of the bit 
between processes on signals, is not something anyone ought to want on a 
system.

My point was, that contrary to the comments made early on, reverting GCC 
behaviour is not a sane option.  Patching the kernel is.

(Log in to post comments)

Please read the article

Posted Mar 13, 2008 9:48 UTC (Thu) by khim (subscriber, #9252) [Link]

It's just that applications suffering obscure memory corruption when memory operations go wrong

Don't use gcc 4.3 to compile your programs then. Or patch your kernel. Your choice.

and a leaking of the bit between processes on signals, is not something anyone ought to want on a system.

You can only leak bit from program to the same program. And if your program does not trust itself - you are hosed anyway.

Once more from the top.
1. Linux, FreeBSD and other kernels provided kind of "changed ABI" - "DF is not guaranteed to be cleared or set when you enter function" was the change from official ABI.
2. GCC before 4.3 produced code which worked correctly with this "changed ABI".
3. GCC 4.3 started to rely on obscure part of ABI and this led to crashes (in some obscure programs but that's not the point).
4. Kernel 2.6.25 fixed problem and now it's safe to use GCC 4.3.
But it does not mean anything for GCC 4.2 and kernel 2.6.24! They have used incorrect ABI all along - but they used it correctly and consistently. Yes, from formal POV kernel is wrong and GCC is right, but in reality you can fix either GCC or kernel - it does not matter which: GCC 4.2 + kernel 2.6.24 is 100% secure and internally consistent combination, GCC 4.3 + kernel 2.6.25 is 100% secure and internally consistent combination (as far as this bug is concerned, of course). End of story.