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.

Re:so what

[William Robinson]

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

p>

Yes, Probably, a single line of code might fix it. (And I won't even call it a bug.)

But before getting over this, I want to say kudos to gcc developers who have taken care to warn about this.

Re:[LWN subscriber-only content]

[Anonymous Coward]

Whatever happened to "information wants to be free"?

Re:so what

[Codifex Maximus]

Ok, I read the article and alot of the comments.

Seems to me the easy and correct thing to do would be to use deprecation. i.e. keep the old functionality for a bit longer and also patch or make the new kernels properly set the flag right now. This way, we move in the right direction and when it's no longer an issue then we drop the functionality in the compiler and rely on the kernel setting the flag like it's supposed to do.

Now, I see why the kernels have not been setting the flag. Why should they when the compiler was doing it? Time to set things right though... in the interests of portability with other environments and compilers. Having the kernels setting the flag starting now would satisfy ABI compatibility with the other compilers AND having gcc continue to cover the flag, by default for a time, would prevent breakage of alot of existing code.

Seems like a no brainer to me. After all, isn't that what deprecation is for?

That's my take on it...

Re:so what

[torstenvl]

Actually - and I attribute this to good ol' BK - GCC *could* make the problem go away, by recognizing when it is compiling the kernel, and inserting the code itself.

Just sayin'.

Read this -- http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]

Re:GCC is wrong

[evanbd]

Silly question time...

If this managed to affect both Linux and BSD despite no relevant common code, is Windows affected? I'm guessing OSX is, thanks to its BSD heritage. Has anyone tested either of them, though? How about other OSes?

Re:so what

[Vlad_the_Inhaler]

From what I saw of TFA, this is being done. An updated GCC is being pushed and I suppose that this reversion to the previous behaviour will be backed out again at some point.

Interesting was:

• GCC was the exception in this case - other C compilers always did it this way
• While it affects some programs running under Linux or BSD, this GCC update appears to nuke Hurd completely.

Re:GCC is wrong

[Vlad_the_Inhaler]

It is not quite as bad as that. It causes problems between two threads, but both threads have to be from the same program. If someone has such a specially crafted program running on their system, they have been breached already.

No privilege escalation, only DOS.

I fixed this bug in 1989 too

[flyingfsck]

I fixed this bug in 1989 in an Intel C compiler. That was some years before the GCC project was started. Some people never learn...

Assembler code

[hemanhedman]

Does this mean that you could hand-craft some assembler code that exploits virtually all Linux and BSD-kernels out there?

Re:GCC is wrong

[WK2]

1) Nobody is getting on gcc's case. As I understand it, they are doing the right thing, and reverting to the older, safer, although slightly slower, behavior.

2) Perhaps you haven't gotten the news, but IE8 is doing the right thing too, by using their "less broken" mode by default. This is a switch from what they announced earlier, where you would have to opt-in to better standards compliance.

3) The difference between IE, and gcc is IE is broken, and gcc is not. Clearing the DF does not break standards in any way. In fact, according to the ABI, it needed to be done anyway (although the kernel is supposed to do it). Guess what happens when you clear the DF twice?

Re:GCC is wrong

[Lonewolf666]

Enforcing standards compliance will be a pain in the short run, but pay off in the long run. Because you can get away with accommodating old bugs (or bad designs, but that gets offtopic) for a while, but eventually the difficulty in maintaining all the quirks grows to a point where it is no longer doable.

I think Windows Vista is a good example of what happens when you try to maintain backwards compatibility to the assorted bugs and mis-designs of decades. See the various Vista articles on /. on how that worked out ;-)

If Microsoft takes the opposite approach with IE8, I consider that a good move and a sign that they are capable of learning.

Re:Let us blame the correct entity here...

[LanceUppercut]

You don't get it either. In a signal-enabled environment there can't be any policy that would ensure the deterministic state of the flag, even if you set it explicitly before each flag-dependent operation. The only way to fix the problem is to make sure that the signal-routing environment meticulously stores and restores the value when handling interruptions. This was not done. This is the the problem in question. It was there all along and it is not related to any compilers. The current version of GCC was simply more likely to reveal it (and it did reveal it), but the problem itself was there since the beginning of time and can lead to problems with any version of GCC, or any other compiler.

Re:GCC is wrong

[ultranova]

It is not quite as bad as that. It causes problems between two threads, but both threads have to be from the same program.

Actually, no. Two threads will work just fine, because the state of the CPU in its entirety (all flags) is saved and restored at when switching between them - indeed, if it wasn't, simply clearing the flag before using it wouldn't help any, because a task switch can occur between any two instructions, including the one clearing the flag and the one immediately following, which makes use of the now-cleared flag.

No, the problem is in signal handlers, which are the software-level equivalent of interrupts. When a thread receives an signal, and a handler has been registered, it immediately interrupts what it was doing and executes the handler function - or, more precisely, the kernel switches the point of execution to the start of that function. Now, the problem is that the spec says that a certain flag should be cleared whenever a function starts, and he kernel doesn't make sure it is. It didn't matter previously, because the GCC generated code to clear it anyway; however, this is redundant according to the spec, so it was dropped.

So, to sum it up: this has nothing to do with threading and can affect single-threaded programs just fine.

No privilege escalation, only DOS.

This bug could conceivably cause parts of a program's memory be overwritten by the contents of a string. It isn't unthinkable that this might cause foreign code execution attack in the program.

Altought it does seem pretty unlikely that anyone would do string copying in a signal handler...