Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GCC 4.3.0 Exposes a Kernel Bug

kdawson posted more than 6 years ago | from the my-flag-boy-told-your-flag-boy dept.

Bug 256

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.

cancel ×

256 comments

Sorry! There are no comments related to the filter you selected.

Yep, (5, Funny)

EkriirkE (1075937) | more than 6 years ago | (#22791944)

That's what happens when you don't clear that STD...

Re:Yep, (3, Funny)

Creepy Crawler (680178) | more than 6 years ago | (#22792002)

---That's what happens when you don't clear that STD...

And the answer is to.... use condoms?

And I thought we were here discussing bugs between GCC and LK.

Re:Yep, (2, Funny)

EkriirkE (1075937) | more than 6 years ago | (#22792026)

Some CLD will clear that STD, silly!

Re:Yep, (2, Funny)

cralewyth (934970) | more than 6 years ago | (#22793038)

All it really needs is some TLC.

Re:Yep, (1)

orkysoft (93727) | more than 6 years ago | (#22792048)

Woosh!

Re:Yep, (1)

creimer (824291) | more than 6 years ago | (#22792408)

No, no, no. Take a knife and cut the wing-ding off. Intel does it all the time.

so what (5, Insightful)

Brian Gordon (987471) | more than 6 years ago | (#22791956)

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 (5, Insightful)

OverlordQ (264228) | more than 6 years ago | (#22791992)

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:so what (4, Insightful)

Creepy Crawler (680178) | more than 6 years ago | (#22792024)

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:so what (4, Insightful)

evanbd (210358) | more than 6 years ago | (#22792058)

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.

Re:so what (1)

Brian Gordon (987471) | more than 6 years ago | (#22792106)

Oh I see the problem.. now that GCC isn't turning out broken binaries, old kernels will be unable to run them. Everyone will be forced to upgrade, or more likely everyone will still make broken binaries.

Re:so what (0)

jlarocco (851450) | more than 6 years ago | (#22792220)

If I've read correctly, the bug only occurs when old kernels (without this newest little patch) are compiled with the brand new GCC 4.3.

How likely is it that a person who compiles their own kernels with brand new versions of GCC won't be running the newest kernel that has this patch? How likely is it they won't be able to backport this patch if they're can't fully upgrade the kernel? How many people will say "Time to compile my old, stable, trusted kernel, with this brand spanking new, relatively untrusted compiler"?

I'm not saying those people don't exist, but they're a very tiny subset of an already very tiny set of Linux users.

Re:so what (5, Informative)

RML (135014) | more than 6 years ago | (#22792346)

You have read incorrectly. The bug occurs when applications compiled with the brand new GCC 4.3 are run on old kernels, regardless of what compiler was used to compile the kernel.

mod parent up (1)

sydneyfong (410107) | more than 6 years ago | (#22792404)

I also wrongly assumed GP's view until I actually RTFM-ed....

Re:so what (1)

nategoose (1004564) | more than 6 years ago | (#22792474)

I don't think that this problem is very likely since to my knowledge few applications ever flip the direction flag.

Re:so what (1)

chgros (690878) | more than 6 years ago | (#22792540)

I don't think that this problem is very likely since to my knowledge few applications ever flip the direction flag.
I believe the problem happens if the kernel flips the direction flag: it will stay flipped when calling back to your application.

Re:so what (1)

rsidd (6328) | more than 6 years ago | (#22792432)

If I've read correctly, the bug only occurs when old kernels (without this newest little patch) are compiled with the brand new GCC 4.3.

You read wrongly, or more likely did not read at all. And nor did the moderators. The bug exists no matter what compiler was used to compile the kernel.

Re:so what (2, Insightful)

qbwiz (87077) | more than 6 years ago | (#22793084)

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 (-1)

Psychotria (953670) | more than 6 years ago | (#22792350)

I am not pretending to understand this entire issue. However, I think the problem relates to the kernel being compiled with GCC 4.3.0. I think the article may be wrong in saying: 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.. Of course, I may be wildly off base, but this is the only way that my pseudo-thought makes sense.

Re:so what (5, Insightful)

und0 (928711) | more than 6 years ago | (#22792544)

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:so what (1)

Psychotria (953670) | more than 6 years ago | (#22792668)

Ok. So I was wrong. Interesting link -- thanks.

Re:so what (0)

Anonymous Coward | more than 6 years ago | (#22792360)

That's, quite literally a fuckton of systems. So simply patching new kernels isn't going to make the problem go away.
I just about shat my pants when I read this; that is quite possibly the most ingenious use of the word fuck I have ever seen. I wonder, though, what is the exact measurement of a "fuckton"? Is it a unit or is it a constant?

Oh, and were this 4chan, I would have lost the game.

Feel the power (of Google) (1)

Mathinker (909784) | more than 6 years ago | (#22792692)

http://www.urbandictionary.com/define.php?term=metric+fuckton [urbandictionary.com]

> ... 4chan ...

Now I know you're trolling --- who could be familiar with 4chan and not "fuckton"?

Re:Feel the power (of Google) (0)

Anonymous Coward | more than 6 years ago | (#22792888)

who could be familiar with 4chan and not "fuckton"?

Cancer etc.

Re:so what (2, Funny)

Profane MuthaFucka (574406) | more than 6 years ago | (#22792394)

I'm a consultant, and I'm wondering what the billing rate times a fuckton is going to total out to.

Re:so what (3, Funny)

serviscope_minor (664417) | more than 6 years ago | (#22792416)

Is a fuckton more or less than a metric assload?

Re:so what (0)

Duhavid (677874) | more than 6 years ago | (#22792466)

Yes. Next question, please.

Re:so what (5, Interesting)

Codifex Maximus (639) | more than 6 years ago | (#22792654)

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 (4, Interesting)

Vlad_the_Inhaler (32958) | more than 6 years ago | (#22793052)

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:so what (1)

HeroreV (869368) | more than 6 years ago | (#22792804)

That's, quite literally a fuckton of systems. So simply patching new kernels isn't going to make the problem go away.
Other compilers, like ICC from Intel, do not set the flag. That's, quite literally a fuckton of binaries already out in the wild. So simply patching GCC isn't going to make the problem go away either.

The problem is in the kernel, and GCC cannot solve that. This problem will exist whether GCC adds an ugly hack or not. Even if GCC had never changed their behavior, this would still be a problem for other compilers.

Re:so what (2, Interesting)

torstenvl (769732) | more than 6 years ago | (#22792954)

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:so what (0)

Anonymous Coward | more than 6 years ago | (#22792014)

Then any binaries compiled with GCC 4.3 will not work correctly on any version of Linux prior to 2.6.25 (assuming the fix is present in the next version). That's hardly acceptable, is it? Nor is the potential security risk involved in using GCC 4.3 itself, or any software compiled with it, on any machine with any currently existing kernel.

Re:so what (2, Interesting)

William Robinson (875390) | more than 6 years ago | (#22792060)

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:so what (0)

Anonymous Coward | more than 6 years ago | (#22792074)

arch/x86/ia32/ia32_signal.c | 4 ++--
  arch/x86/kernel/signal_32.c | 4 ++--
  arch/x86/kernel/signal_64.c | 2 +-
  3 files changed, 5 insertions(+), 5 deletions(-)
From the kernel patch [lwn.net] .

Oh OK then, it really is one line. Very exciting indeed.

Re:so what (-1)

Anonymous Coward | more than 6 years ago | (#22792272)

Ok, so you can't deal with your beloved OS having a bug for the last 15 years, so you are dismissing it. Shall I get you a glass of water?

GCC is wrong (0, Troll)

BadAnalogyGuy (945258) | more than 6 years ago | (#22791976)

Rule #1: Don't break existing stuff

GCC breaks this cardinal rule. It should be reverted.

Re:GCC is wrong (5, Insightful)

Anonymous Coward | more than 6 years ago | (#22792012)

"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:GCC is wrong (2, Insightful)

BadAnalogyGuy (945258) | more than 6 years ago | (#22792042)

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

Telling your age (1, Funny)

symbolset (646467) | more than 6 years ago | (#22792116)

1991 was a long time ago. Linux is old.

Re:Telling your age (0)

Anonymous Coward | more than 6 years ago | (#22792332)

If you think 1991 was a long time ago, what does that say about your age? :)

Re:GCC is wrong (0)

Score Whore (32328) | more than 6 years ago | (#22792078)

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


I'm curious, why would you think that the BSD kernels were/are broken? Why would they be following the Sys V ABI? You do know that there are two general flavors of unix right? Sys V and BSD. Guess which one the BSDs are?

Re:GCC is wrong (5, Informative)

Anonymous Coward | more than 6 years ago | (#22792122)

Check the BSD mailing lists for yourself, they are affected. I'll give you one example below:

http://leaf.dragonflybsd.org/mailarchive/commits/2008-03/msg00072.html [dragonflybsd.org]

Before flaming people next time, at least try and learn about what you're talking about.

Re:GCC is wrong (3, Interesting)

evanbd (210358) | more than 6 years ago | (#22793044)

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:GCC is wrong (0)

Anonymous Coward | more than 6 years ago | (#22792128)

"I'm curious, why would you think that the BSD kernels were/are broken? Why would they be following the Sys V ABI? You do know that there are two general flavors of unix right? Sys V and BSD. Guess which one the BSDs are?"

You do know that the SysV ABI goes along with ELF, and that the BSDs have adopted it along with the file format?

Re:GCC is wrong (1)

MostAwesomeDude (980382) | more than 6 years ago | (#22792184)

It's the x86 ABI, so it has nothing to do with the lineage of the code and everything to do with the architecture. (Unless you're going to tell me that BSD has its own double secret x86 ABI!)

Re:GCC is wrong (1)

burgundysizzle (1192593) | more than 6 years ago | (#22792324)

Of course it does. Try copying /dev/zero into a file to have a read of their double secret ABI! Once you're done you can save a copy by copying it back to /dev/null then removing the original file.

Re:GCC is wrong (0)

Anonymous Coward | more than 6 years ago | (#22792262)

The name "SysV ABI" is misleading. All the BSDs have adopted it along with ELF, also originally a SysV standard. It's just historical. It's now pretty much the "everybody running on x86 Unix" ABI.

Re:GCC is wrong (5, Insightful)

bkaul01 (619795) | more than 6 years ago | (#22792028)

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 (0)

Anonymous Coward | more than 6 years ago | (#22792592)

No.

Re:GCC is wrong (1)

pembo13 (770295) | more than 6 years ago | (#22792622)

We darn well aren't. This is a fair bug, which was found out, and deserves to be fixed by someone who understands it. There should be no nitpicking, except to come to conclusion on how much of current systems are affected.

Re:GCC is wrong (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22792686)

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.

Re:GCC is wrong (1)

ukyoCE (106879) | more than 6 years ago | (#22792818)

I think you have it backwards. Shouldn't you be saying:

"So, we ARE going to get on GCC's case, right? For breaking compatibility with millions of systems, just like Microsoft intentionally broke Firefox, Opera, and Safari?"

Standards compliance is generally a good drum to bang, but whats REALLY important is what you're breaking. It seems to me GCC has a fix in search of a problem. If they really want to meet the standard here, I think it would be reasonable to request the fix from the broken kernels and wait a reasonable amount of time for proliferation before releasing the fix.

I don't care much either way, mainly wanted to point out that the problem with IE has been the fact that it BREAKS other web browsers. The standards are just an easy place to point to determine which browser is the problem. And of course blatant abuse of a monopoly to squash competitors gets some of us a little peeved too.

Re:GCC is wrong (1)

n3tcat (664243) | more than 6 years ago | (#22793012)

SHHH!!! This is slashdot! An evangelist might hear you!

Re:GCC is wrong (5, Informative)

Anonymous Coward | more than 6 years ago | (#22792034)

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

GCC is in the business of creating new and better optimizations. It is pretty much impossible to make optimizations without assuming things in the ABI. As more and more stuff from the ABI is assumed in the optimizations, people get away with less violations of the ABI, but without assuming more stuff, faster optimizations wouldn't happen.

Because the newest versions of GCC are necessary to improve the state of the art in C compiler optimizations in the open source world, the appropriate reaction to this is to have the compiler people follow the spec, and assume the spec, and if assuming the spec breaks something, the people affected by the breakage don't upgrade their compilers.

This is why there are still people using GCC versions from the stone age.

Re:GCC is wrong (1)

mrmeval (662166) | more than 6 years ago | (#22792530)

Linus is a cave man?

Re:GCC is wrong (3, Insightful)

SeaFox (739806) | more than 6 years ago | (#22792454)

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:GCC is wrong (1)

Orion (3967) | more than 6 years ago | (#22792490)

It's not just GCC. The bug is actually in the kernel... you can propose that GCC be extra careful not to trigger this bug, but if someone wants to make a binary that triggers it, they don't need GCC to do that.

It's a potential security hole, and an almost certain memory corruption-waiting-to-happen, and needs to get fixed in the kernel. GCC reverting to the old behaviour will, at best, prevent people from accidentally finding this.

Re:GCC is wrong (2, Interesting)

Vlad_the_Inhaler (32958) | more than 6 years ago | (#22793068)

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.

Kernel bug (4, Funny)

Harmonious Botch (921977) | more than 6 years ago | (#22791988)

Better than a general fault.

Re:Kernel bug (3, Informative)

clickety6 (141178) | more than 6 years ago | (#22792946)


nut not as good as a major screw-up or even a private error

WOW!! (0, Flamebait)

EEPROMS (889169) | more than 6 years ago | (#22791990)

A error was found and patched, now remind me why this is news ?

I have a solution (1)

sakura the mc (795726) | more than 6 years ago | (#22792038)

dont upgrade?

Linux is full of critical bugs (-1, Troll)

The_Abortionist (930834) | more than 6 years ago | (#22792044)

Linux is full of bugs, and it's about time that people on here start realizing it. Any application that performs a simple strcpy brings linux down.

Microkernel? I think so..

Re:Linux is full of critical bugs (1)

Psychotria (953670) | more than 6 years ago | (#22792274)

With all due respect, an application that uses strcpy will not necessarily bring a system down (nor introduce buffer overflows, or whatever). strcpy used properly is quite safe. Sure, if you strcpy to some unknown memory address of some unknown size then this will cause problems. That is not a strcpy fault, but a programmer fault. strncpy is not inherently "better". To say that "Any application that performs a simple strcpy brings linux down" is FUD.

Re:Linux is full of critical bugs (1)

chromatic (9471) | more than 6 years ago | (#22792340)

Microkernel? I think so...

Microkernels have to follow processor ABIs too.

Linux Replies (0)

Anonymous Coward | more than 6 years ago | (#22792064)

"A bug? In the Kernel? BWAHAHA, a trivial matter" [Snaps random developer in half, ingests]

EVERYBODY PANIC!!! (5, Funny)

Anonymous Coward | more than 6 years ago | (#22792076)

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.

Oh my GOD! If this is true, that means- that means-- it... the-

Uh, what does it mean exactly?

Re:EVERYBODY PANIC!!! (5, Informative)

EkriirkE (1075937) | more than 6 years ago | (#22792138)

When scanning strings for, say, a null terminator the direction flag determines if the current memory register gets incremented or decremented after each byte check. It could mean strlen returns 0 if your strings are grouped together in a segment of memory, or it just plain return the wrong result. Also memory copy routines could copy the wrong part of memory to the wrong place and overwrite executable code (or just cause a page/segment fault).

Re:EVERYBODY PANIC!!! (5, Funny)

Anonymous Coward | more than 6 years ago | (#22792188)

I'm sorry, I'll need a car analogy on that one.

Re:EVERYBODY PANIC!!! (5, Informative)

EkriirkE (1075937) | more than 6 years ago | (#22792290)

In x86 (assumed from here on) assembly, there are some 'quick' operations to read, write, and test memory (LODS*, STOS*, SCAS* respectively - there are probably more). The CPU has registers, or variables that are counters, or hold the memory addresses in question - in these cases a source memory position and a destination memory position. When you performs these commands the memory registers either increment or decrement value (position) depending on how the direction flag is set. GCC is assuming the flag is clear and the pointers will increment - go forward after each call. If the direction flag is set incorrectly upon calling these string or memory functions, the pointers could go backwards and thus copy (or scan) the wrong chunk of memory to the wrong destination.

Say our source memory contains:

Address: 0123456789ABCDEFGHIJKLMNOPQRSTUV
Contents: XXXXXXXXA car is heavy.-XXXXXXXX


Let's pretend the hyphen is a null (the string terminator or "stop" in most languages and OS) If I want to perform a strlen on that string at position '8', it should return 15 characters because it found the null at 'N' If the direction flag is wrong, it will not scan 8, 9, A, ... but 8, 7, 6, ... until it finally finds that null or crashes with an access violation.

And with memory, I want to copy 5 bytes from '8' to position 'P' If that works correctly, we get this in memory:

Address: 0123456789ABCDEFGHIJKLMNOPQRSTUV
Contents: XXX-!@#$A car is heavy.-XA carXX


However, if the direction is wrong, we will get:

Address: 0123456789ABCDEFGHIJKLMNOPQRSTUV
Contents: XXX-!@#$A car is heav!@#$AXXXXXX


See how '8' copied to 'P' as expected, but decrementing we then get '7' to 'O', etc

We now have corrupt memory. If we so a strlen, strcat or other null-expecting function on that string located at '8' we will see garbage where the memory copy wrote the wrong data to the wrong position. For the nitpicks, this example used per-byte, there are 16, 32, 64 bit variants of the functions that would cause similar problems bit in 2, 4, 8 byte chunks.

Re:EVERYBODY PANIC!!! (2, Informative)

EkriirkE (1075937) | more than 6 years ago | (#22792306)

Oops, source memory was supposed to be (better aligned, too):

Address: 0123456789ABCDEFGHIJKLMNOPQRSTUV
Content: XXX-!@#$A car is heavy.-XXXXXXXX

Re:EVERYBODY PANIC!!! (0)

Anonymous Coward | more than 6 years ago | (#22792526)

That was excellent. Thank you!

Re:EVERYBODY PANIC!!! (1)

dido (9125) | more than 6 years ago | (#22793006)

I wonder if anyone still actually uses the old LODS/STOS/MOVS/CMPS instructions, and these are the only instructions affected by the direction flag. As far as I can tell, on modern x86 systems they are significantly slower than the equivalent multi-instruction versions that read/write/compare via register indirection, i.e. RISC-style code, and they are even slower yet than using MMX or SSE instructions to copy data, if they are available. I don't think that compilers are smart enough to use, say, a MOVSD instruction when they see a *p++ = *q++ in someone's code, as that would require setting up the direction flag, setting the ESI and EDI registers correctly, and possibly ECX as well, to do a REP MOVSD properly. CISC-style instructions often have strange requirements like this. The only way that these instructions that do care about the direction flag could plausibly appear in actual code is if someone wrote them in assembly explicitly, and it may be that the glibc code for something like memcpy uses it, but then on a Pentium or more recent processor the four-instruction equivalent to movsd: mov eax,[esi] add esi,4 mov [edi],eax add edi,4 (for some suitable ordering of the add instructions) would be faster than a movsd because of instruction pipelining. Correct me if I'm wrong but these instructions haven't been worth using on x86 since at least the Pentium, where instruction-level parallelism can blow the performance of these older instructions out of the water.

Re:EVERYBODY PANIC!!! (1)

faragon (789704) | more than 6 years ago | (#22793048)

These "quick operations" are not quick anymore; on modern -out of order- x86 procesors (P4, PentiumM/Core, K7, K8), explicit string search (still without using SIMD tricks) is from 2x to 3x -using SSE2 prefetch- faster than the microprogrammed code, as you can unroll loops without conditional jump penalty.

Re:EVERYBODY PANIC!!! (1)

EkriirkE (1075937) | more than 6 years ago | (#22793092)

MS Windows uses REP MOVSD and a topoff with REP MOVSB in its internal string memory copy (RtlCopyMemory/RtlMoveMemory), as does the MSVCRT... And I do as well :)
When Windows has to backwards copy on overlap it does STD then immediately CLD after the REP operation, and also ensures the CLD on a forward copy. MSVCRT does not ensure it on the forward copy.

Re:EVERYBODY PANIC!!! (5, Insightful)

Neon Spiral Injector (21234) | more than 6 years ago | (#22792364)

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:EVERYBODY PANIC!!! (1)

teh loon (974951) | more than 6 years ago | (#22792798)

Ahh yes.. another brilliant car analogy on slashdot. :)

Re:EVERYBODY PANIC!!! (Car Version) (1, Funny)

Anonymous Coward | more than 6 years ago | (#22792384)

It's like you got a bunch of cars at a stoplight and you want to walk by each to panhandle for money but instead of starting at the first car in line and the walking down to the back, you start at the first then head out into cross traffic and get run over and something crashes.

Re:EVERYBODY PANIC!!! (1)

SL Baur (19540) | more than 6 years ago | (#22792848)

I'm sorry, I'll need a car analogy on that one.
It means that you are never sure if your car is in gear or in reverse. So you don't know which direction you will go when step on the gas.

What this really exposes... (2, Insightful)

suck_burners_rice (1258684) | more than 6 years ago | (#22792102)

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.

Re:What this really exposes... (1)

noidentity (188756) | more than 6 years ago | (#22792634)

In summary, it's a bug in the ABI documentation; apparently the direction flag must be considered undefined in this case. Fixing the documentation won't break any current code.

Re:What this really exposes... (2, Funny)

HonIsCool (720634) | more than 6 years ago | (#22792808)

Hehe, I'm going to try that approach the next time I'm assigned a bug: "No, it's not the code that's wrong, it's the specification."

Re:What this really exposes... (5, Informative)

Alex Belits (437) | more than 6 years ago | (#22792826)

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.
Please don't ever again offer your great insight into software development process. If everything was stuffed into the kernel (or other software projects) once it compiles and runs, we would drown in unstable, crashing, insecure, impossible to debug code. Without any doubt, there are plenty of geniuses (some of them in Northwestern US) who develop in this manner, but I can assure you, neither Linux kernel, nor GCC, glibc or other major open source projects use this procedure. If you want to discuss this method further I recommend you to send your opinion to a friendly individual at djb@cr.yp.to .

Before anything is released, people have to LOOK AT THE CODE and make sure that the source gives them a reason to think, it will run correctly when used with interfaces that it is supposed to utilize or provide. There are plenty of things in the kernel that would require massive amount of testing to be verified with any certainty, so people write usable code not because they are testing it until their hardware breaks but because they know what they are doing.

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.
What the hell are you talking about?

Code generated by a C compiler remains consistent regardless of the version, unless you mix binaries built with different versions of GCC. When code that kernel uses to pass control to applications' signal handlers does not keep the direction flag as it is supposed to according to ABI, then userspace code -- ANY CODE THAT CONTAINS SIGNAL HANDLERS -- compiled by a new compiler will not work correctly. In other words, kernel provides an interface that is incompatible with binaries made by a new GCC, and since the standard is on the side of the new GCC behavior, it's kernel that has to be changed. That's all. Nothing else is involved -- some code compiled with a new compiler will not work on an old kernel. Code compiled with an old compiler remains usable with a new kernel, no sources except for five lines in the kernel [lwn.net] have to be changed. It's not even something that a C programmer has any control over unless he writes pieces of his program in assembly -- and then he should know. I don't even believe, any for a C programmer who knows how to write a signal handler it's possible that he "never heard of this obscure nuance of the Intel processor" -- both are very rarely used directly -- however this is completely irrelevant, the only sources that have to be changed are five lines in the kernel, not in signal handlers.

The only real problem this "exposes" is that for some reason everyone who used x86 SysV ABI for anything that matters (Linux and BSD), decided to change the interface to exclude the requirement to clear the direction flag, even though that "official" standard said otherwise -- however it was known from the very beginning, and this is why older C compiler taken it into account in the first place. It's not a bug or someone's lack of knowledge, it's a violation of a standard, and GCC developers decided to get things back to the letter of a standard because the compiler's optimization benefits from it.

Re:What this really exposes... (1)

mav[LAG] (31387) | more than 6 years ago | (#22792890)

Now it's entirely possible that the kernel developers never heard of this obscure nuance of the Intel processor.

Far from being an obscure nuance, CLD and STD are just ordinary instructions which tell the processor which direction the next SCAS, LODS or STOS intruction must go. They are explained very early on in most assembly tutorials that I've come across.

A kernel developer who's never heard of the processor's direction flag has no business writing kernel code.

[LWN subscriber-only content] (4, Insightful)

Chris Pimlott (16212) | more than 6 years ago | (#22792264)

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:[LWN subscriber-only content] (1, Interesting)

Anonymous Coward | more than 6 years ago | (#22792368)

Whatever happened to "information wants to be free"?

Re:[LWN subscriber-only content] (5, Funny)

gambolt (1146363) | more than 6 years ago | (#22792974)

Information wants to be free. Bandwidth wants to cost money.

Re:[LWN subscriber-only content] (2, Insightful)

totally bogus dude (1040246) | more than 6 years ago | (#22792410)

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:[LWN subscriber-only content] (0, Flamebait)

rsidd (6328) | more than 6 years ago | (#22792446)

Indeed, Slashdot is becoming a disgrace. They could have waited another day: the article becomes freely available on March 20.

Translation? (0, Redundant)

Raul654 (453029) | more than 6 years ago | (#22792434)

Can someone please explain that in terms that non-LKML subscribers can understand?

Re:Translation? (1)

rdebath (884132) | more than 6 years ago | (#22792644)

Probable local root exploit (Normal local user gets root access) with ability to install rootkit.
Likely to also give 'real root' access on 'vserver' machines that have fake root accounts.
Unlikely to directly give a remote exploit, but would likely mean that any remote exploit becomes a remote root exploit.

However, as at present no exploit is known and it's 'only' a local exploit the Microsoft evaluation of this would be patch in the next service pack.

Gnearly Perfect (1)

rhinokitty (962485) | more than 6 years ago | (#22792536)

See, I told you we shoulda' used the Hurd!

History repeating (2, Informative)

Brett Johnson (649584) | more than 6 years ago | (#22792658)

I seem to recall the MS-DOS 2.x suffered this same problem with either the Int 21 or Int 13 interfaces. (Hey it was 20 years ago, I don't remember the details.) If you made certain BDOS calls with the direction flag set, the message "A evird rorre etirw daeR" ("Read write error drive A" backwards) would be displayed on the console. It wasn't fixed for years. I remember we rigorously enforced the "Clear the direction flag before calling into MS-DOS" rule.

Eh? (1)

rice_burners_suck (243660) | more than 6 years ago | (#22792706)

I would think the correct behavior IS to clear the flag before performing one of those operations. Assuming that it is set will cause all kinds of havoc. What's better? Making sure the setup for string routines is correct in ONE place (the compiler) or in a zillion places (every single program that uses string operations)? I don't understand why the earlier behavior was considered a compiler problem.

One more thing. (1)

EkriirkE (1075937) | more than 6 years ago | (#22792738)

This is assuming the flag is unmodified from the kernel call, saying the string function is called or entered from the kernel. But if the string functions get called mid-code and the flag is changed be some other function, say a memmove that has an overlapping source and destination, the direction flag is set (STD) and the memory copied backwards end-to-start to prevent the beginning being copied over and over by the overlap.
Does GCC's memmove clear the flag (CLD)?
What if someone writes some custom inline assembly with a STD and no CLD (yes, this does violate asm practice - flipping a flag and not resetting it when done) then a string function sometime after that during the same procedure? GCC will fail.
GCC should not rely on the kernel to have the flags in a particular state upon entry, as the functions will not always be called immediately.

most appropriate (0)

Anonymous Coward | more than 6 years ago | (#22792786)

Maybe it's time to break that. -- Larry Wall in 199710311718.JAA19082@wall.org

An appropriate quote for the bottom of the page ;)

What about other compilers? (1)

oglueck (235089) | more than 6 years ago | (#22792872)

That means that all other compilers behave like the old GCCs in this case. Otherwise they would have exposed this bug already. So GCCs new behaviour could be seen as either non-standard or "innovative".

Yes. And? (1)

jimicus (737525) | more than 6 years ago | (#22792952)

Debian, RedHat et al aren't going to release new packages compiled with GCC 4.3.0 for every damn binary. Instead, they'll hold back on providing an update to GCC and they won't compile any updated packages with the updated GCC until the next major release.

Of course, that's not very helpful if you depend on closed-source software and the vendor won't tell you what compiler they use. Neither is it particularly helpful if you run Gentoo (which sooner or later will expect you to upgrade compiler) or if you're in the habit of compiling packages from scratch using a compiler other than the one that shipped with your distro. But for most of us in the real world, that's not really a huge deal.

That's no GNU'd! (2, Insightful)

lumbercartel.ca (944801) | more than 6 years ago | (#22793036)

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

.0 versions suck, anyway (0)

Anonymous Coward | more than 6 years ago | (#22793074)

I still use GCC 2.95.3 to compile my kernel, but the developers don't allow it to build 2.6 versions. They're too dumb to fix it and I have to use 2.4.

Anyway, why would you use a .0 version? It's like running Windows Vista RC0.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>