Please read the article [LWN.net]

Please read the article

Posted Mar 11, 2008 13:44 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: This is joke, right? Or do you really misunderstood the simple issue? by roblucid
Parent article: GCC 4.3.0 exposes a kernel bug

You've got all sorts of misapprehensions about this.

Firstly what you seem to be proposing is that somehow this ABI bug would corrupt the OS
kernel. I can assure you that this cannot happen. Linux* couldn't care two hoots about the DF
bit in the flag register of a userspace process which is all that's being tweaked. However the
process itself might care, and is entitled to ABI correct behaviour - and so Linux needed to
be patched to reset this flag bit when calling the signal handler in the userspace process.

Flipping the DF bit is not a privileged operation, it's a normal function of the x86 processor
family. You can add code to your programs to arbitrarily flip DF if you like, and at most
you'll just manage to make it hang or crash.

To have a security problem, what would be needed is to run privileged code which relies on
this ABI feature, and then send it signals until it malfunctions. In most cases on Linux your
privileged code was compiled with GCC < 4.3 and thus does not rely on this ABI feature. Code
from vendors compiled with a patched GCC 4.3.x will also not be affected. Daemons and other
privileged processes very rarely provide a mechanism to receive signals from unprivileged
users. Most of them do very little in their signal handlers and thus won't be relying on this
ABI feature even with GCC 4.3.0. So you need a very extraordinary set of circumstances to
achieve anything more than crashing your own programs.

The code in which this bug was originally noticed deliberately causes large numbers of
SIGSEGVs during normal operation and handles them by AFAICT calling memmove() from an assembly
language routine. Does that sound like any of the programs running with privileges on your
servers? No, didn't think so.

If you're in the habit of running code created by untrusted users then you don't need this ABI
bug to have problems, indeed it makes no difference at all - you've got a gaping hole in your
security strategy from the start.

* Read NetBSD, FreeBSD, OpenBSD etc. for Linux as you prefer. They all seem to have an
identical bug here, shielded by GCC

(Log in to post comments)

Please read the article

Posted Mar 13, 2008 9:00 UTC (Thu) by roblucid (subscriber, #48964) [Link]

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.

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.