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.

10 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

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

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

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