Slashdot Mirror

← Back to Stories (view on slashdot.org)

GCC 4.3.0 Exposes a Kernel Bug

Posted by kdawson on from the my-flag-boy-told-your-flag-boy dept.

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.

18 of 256 comments (clear)

  1. so what by Brian+Gordon · · Score: 5, Insightful

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

    1. Re:so what by OverlordQ · · Score: 5, Insightful

      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.

      --
      Your hair look like poop, Bob! - Wanker.
    2. Re:so what by Creepy+Crawler · · Score: 4, Insightful

      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).

      --
    3. Re:so what by evanbd · · Score: 4, Insightful

      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.

    4. Re:so what by und0 · · Score: 5, Insightful

      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

    5. Re:so what by qbwiz · · Score: 2, Insightful

      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.

      --
      Ewige Blumenkraft.
    6. Re:so what by dargaud · · Score: 2, Insightful

      Maybe it needs an entry for us regular programmer...

      --
      Non-Linux Penguins ?
  2. Re:GCC is wrong by Anonymous Coward · · Score: 5, Insightful

    "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.

  3. Re:GCC is wrong by bkaul01 · · Score: 5, Insightful

    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?

  4. Re:GCC is wrong by BadAnalogyGuy · · Score: 2, Insightful

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

  5. What this really exposes... by suck_burners_rice · · Score: 2, Insightful

    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.

    --
    McCain/Palin '08. Now THAT's hope and change!
  6. [LWN subscriber-only content] by Chris+Pimlott · · Score: 4, Insightful

    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.

    1. Re:[LWN subscriber-only content] by totally+bogus+dude · · Score: 2, Insightful

      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?

  7. Re:EVERYBODY PANIC!!! by Neon+Spiral+Injector · · Score: 5, Insightful

    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.

  8. Re:GCC is wrong by SeaFox · · Score: 3, Insightful

    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.
  9. Re:GCC is wrong by Anonymous Coward · · Score: 1, Insightful

    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.

  10. That's no GNU'd! by lumbercartel.ca · · Score: 2, Insightful

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

    --
    The Lumber Cartel, local 42 (Canadian branch)
    British Columbia, Canada
  11. Career Aptitude Test by Software+Geek · · Score: 2, Insightful

    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.

    --
    http://xkcd.com/756//