GCC 4.3.0 Exposes a Kernel Bug

ohxten sends news from earlier this month that GCC 4.3.0's new behavior of not clearing the direction flag before a string operation on x86 systems poses problems with kernels — such as Linux and BSD — that do not clear the direction flag before a signal handler is called, despite the ABI specification.

so what

[Brian Gordon]

OK so the kernel developers add a single line of code, the bugzilla ticket is closed, and we get on to real news?

Re:so what

[OverlordQ]

FTFA:

This problem has existed for 15 years; GCC has always emitted code that worked correctly on kernels that did not follow the ABI, until now.

Part of the problem is that there are an enormous number of installed kernels that are vulnerable to this problem, but only if GCC 4.3 is installed.

That's, quite literally a fuckton of systems. So simply patching new kernels isn't going to make the problem go away.

Re:GCC is wrong

[Anonymous Coward]

"Rule #1: Don't break existing stuff"

The ABI wasn't being followed correctly, hence GCC, Linux and the BSD kernels were already broken.

"GCC breaks this cardinal rule. It should be reverted."

It is not a wise idea to revert corrections to long standing issues.

Re:so what

[Creepy Crawler]

Over-reacting a bit, arent we?

This bugfix is easily regressed, and has already been done.

If somebody wants to stick with a buggy kernel, they can use an older version of GCC. It's not like older stable ones put out horrible binary or anything (we need to exempt RH using 2.96, cause that was ages ago).

Re:GCC is wrong

[bkaul01]

So, are we going to get on GCC's case for enforcing standards compliance and thus breaking backwards compatibility while insisting that Microsoft should take the opposite approach with IE8?

Re:GCC is wrong

[BadAnalogyGuy]

I suppose this might be a longstanding issue if Linux was Unix.

Re:so what

[evanbd]

Unless, of course, it turns out to be a security hole. The sysadmin installed GCC isn't the only way code gets on to systems. Besides, a lot of packages are shipped as binaries built with modern GCC, whatever that may be. This is going to be a pain to fix, even though the fix is simple.

What this really exposes...

[suck_burners_rice]

What this really exposes is not a bug in any kernel. Indeed, the story states that the "bug" exists in both the BSD and Linux kernels. It really exposes something fascinating about the development process: Code is written based on certain assumptions and a working theory of how the code will function once put into use, but the only way to really know how well it works is to hand it over to the ultimate judge of code correctness--the computer--by running the code. If it works, case closed. Now it's entirely possible that the kernel developers never heard of this obscure nuance of the Intel processor. Then one day, the compiler changed, and with it, the assumptions changed. Mature code that has been declared good years ago seemingly breaks. Now it's easy to blame the code, but really this is a deletion of a feature from the compiler. Nevertheless, it exposes the fact that ultimately, no matter what tools we use and no matter how well we think our code through, you can only consider the code good once it runs and appears to do what it's supposed to.

[LWN subscriber-only content]

[Chris Pimlott]

This article is not yet public for non-subscribers. The link given is supposed to be for a subscriber to forward to a friend; putting it up on Slashdot goes against the intended spirit and does not help support Linux Weekly News, which deserves the community's support.

Re:EVERYBODY PANIC!!!

[Neon Spiral Injector]

The rules of the road say that you should check that the car is in drive before setting out on your trip. The older version of GCC used to put the car into drive for you. But the new version lets you leave it in reverse if you don't check making you exit out the rear wall of your garage.

Re:[LWN subscriber-only content]

[totally bogus dude]

Alternatively it's a good way to get additional exposure for LWN, as clearly this article is of some value. Maybe 0.0001% of slashdot readers will subscribe because of this.

Besides, we're all friends here, aren't we?

Re:GCC is wrong

[SeaFox]

Rule #1: Don't break existing stuff
GCC breaks this cardinal rule. It should be reverted.

Using that logic Microsoft shouldn't try to improve security in Windows since it breaks many third party applications that depend on exploits and other silly behavior to function.

Re:so what

[und0]

Nope.

It's related on how the GCC assumes the kernel sets the state of a flag before calling a function (signal handler), and this happens for compiled applications in userland with newer GCC (4.3.0).

I don't recall the gory details, on Sid with the latest (of today) version of libc6, SBCL exposes the bug (crashes). There aren't big differences between libc 2.7-8 and 2.7-9, but the second was compiled with the newer GCC. Kudos to Aurelien Jarno, a Debian developer, who isolated the bug and pushed a patch upstream. http://lkml.org/lkml/2008/3/5/207 [lkml.org]

Re:GCC is wrong

[Anonymous Coward]

No, that's silly. GCC development has a track record of doing good things, so we can assume what they're doing is good. Microsoft has a record of doing bad things (to put it mildly), so we can assume that, whatever they decide to do, it's probably the wrong choice.

That's no GNU'd!

[lumbercartel.ca]

Most experienced assembler programmers know better than to assume the direction flag will be set or cleared unless this is specifically documented.

Re:so what

[qbwiz]

Of course, the security holes will only be in programs that were compiled with GCC 4.3.0. It's not as if some unprivileged user could cause problems merely by compiling something with a new version of GCC, but it will still be a problem if a trusted person uses GCC 4.3.0 to compile and run a program which would become exploitable.

Re:so what

[dargaud]

Maybe it needs an entry [wikipedia.org] for us regular programmer...

Career Aptitude Test

[Software Geek]

Please choose the statement that best describes you:
      A) I want to develop programs that are, theoretically, infinitesimally faster, even though they crash whenever I run them in practice.
      B) I want to force those annoying kernel developer fucktards to follow the damn specification.
      C) I want my software to work reliably, even though it means sacrificing performance and putting up with fucktards.

If you chose A, academia might be right for you.
If you chose B, consider the public sector.
If you chose C, you might be suitable for a career in software development.