Slashdot Mirror
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.
That's what happens when you don't clear that STD...
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
OK so the kernel developers add a single line of code, the bugzilla ticket is closed, and we get on to real news?
Better than a general fault.
"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.
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?
"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.
I suppose this might be a longstanding issue if Linux was Unix.
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?
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!
1991 was a long time ago. Linux is old.
Help stamp out iliturcy.
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
Before flaming people next time, at least try and learn about what you're talking about.
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!)
~ C.
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.
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.
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.
Microkernels have to follow processor ABIs too.
how to invest, a novice's guide
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.
I also wrongly assumed GP's view until I actually RTFM-ed....
Don't quote me on this.
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.
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.
Linus is a cave man?
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
See, I told you we shoulda' used the Hurd!
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.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
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.
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.
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.
http://www.urbandictionary.com/define.php?term=metric+fuckton
... 4chan ...
>
Now I know you're trolling --- who could be familiar with 4chan and not "fuckton"?
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.
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
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.
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".
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.
SHHH!!! This is slashdot! An evangelist might hear you!
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
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?
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.
Mielipiteet omiani - Opinions personal, facts suspect.
OK, I challenge you to find a user-space program that brings linux down using strcpy (as opposed to just crashing that particular program). If you are talking about kernel modules then the same is true of any OS.
They don't need to. All they need to do is release an updated kernel.
Mielipiteet omiani - Opinions personal, facts suspect.
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...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
On the other hand: the instructions affected by this aren't used very much, so if you want optimizations, a good candidate would be to not clear the flag unless it is needed. If the ABI were simply changed to allow this, no existing code would break (obviously), and future code could both conform to the new ABI *and* avoid the overhead of unnecessary instructions to clear the flag when it is not being used.
I suppose the only barrier to this optimization would be the political effort needed to get everyone to agreee to change the ABI.
Or let them add an opt-in compatibility flag which will tell GCC to clear that flag manually and be done with it.
Yup, and another problem is that there are instructions that leave the direction flag undefined, a random value of either 0 or 1. Therefore one has to always explicitly set the direction flag before using it.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Does this mean that you could hand-craft some assembler code that exploits virtually all Linux and BSD-kernels out there?
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?
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
True. Major distros will hold back on upgrading to gcc 4.3.0. Unless they already upgraded. For the most part, this bug will only cause headaches (and possibly suicides) to people trying to diagnose issues in their code, either because they didn't get the memo, and are using gcc 4.3.0, or because they are helping someone with run-time issues, who are using gcc 4.3.0. If I remember correctly, we had similar problems with gcc 4.0.x. I don't recall any reported deaths.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
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.
/. on how that worked out ;-)
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
If Microsoft takes the opposite approach with IE8, I consider that a good move and a sign that they are capable of learning.
C - the footgun of programming languages
as the year of the linux desktop becomes a reality, we've already seen malicious and trojaned programs make their way into repositories. Not to mention distros that contain root exploits with a default installation.
Do you even lift?
These aren't the 'roids you're looking for.
Why would GCC make an assumption about a register, shouldn't it (GCC) set the register to a known value if it needs it ?
OMG OMG OMG! My kernel is vulnerable!!
- regs->flags &= ~(X86_EFLAGS_TF);
+ regs->flags &= ~(X86_EFLAGS_TF | X86_EFLAGS_DF);
make
done.
- these are not the droids you are looking for -
The document referred to is (old) SCO's ABI for System V. If Linux and BSD have not been following this ABI in some respects, perhaps the solution is to have a Linux or BSD ABI that reflects real practice, rather than having a gcc that causes problems because it adheres to a System V ABI that is not being followed.
The funny part.
Last I knew you could download ANT older version of GCC you wanted. Who cares if GCC breaks compiling Linux Kernel, BSD and Hurd. it's not like there is a law that states "thou must use the latest GCC or you will be killed and eaten by the grue!"
use the older compiler until you fix your broken code THEN upgrade to the latest. It blows my mind how many geeks think the MUST HAVE the latest revision.
The GCC guys should NOT release a new revision that puts this back in. It's a fix, everyone else needs to catch up with the fix or use a older compiler.
Do not look at laser with remaining good eye.
Well debian already packaged the latest glibc in sid using gcc-4.3. That is how this issue was discovered in the first place.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Windows doesn't have signals as such, so I'm going to say not really. It might affect the POSIX subsystem and perhaps even Cygwin, but not almost certainly not "native" Windows apps.
Windows uses a different ABI, the windows ABI, so the definition of how the DF should be set is based on a different standard. Furthermore, in the windows world it is a fairly strong argument that the actual behavior of windows+MSVC is the most authoritative guide, rather than what any document may or may not say about what should happen. Finally, windows doesn't have unix signal handlers, so the particular point in question is moot, though there may be alternate ways where the same issue would show up in windows.
You really have absolutely no idea how Gentoo works, do you?
/etc/portage/package.use and package.keywords, editing USE flags, finally emerging the updated package, the fact that you can't easily avoid this unless you're prepared to forsake security updates) really didn't gel with my idea of running a solid system.
Yes, actually. I've run a whole bunch of servers running it.
I found the amount of handholding required in order to turn it into a serious system for server use relative to Debian (such as setting up your own private portage repository, custom holding back of packages, updates which are known in forums to break functionality but don't have the good grace to warn you in the ebuild first, updates which completely restructure a package into different component parts, updates which haven't been tested for backward compatability and so break things subtly, meaning that what should be a simple emerge -U <package name> winds up becoming a complex mix of emerge --sync, editing
Granted, a major update to GCC will almost certainly wind up in a slot of its own. But sooner or later the version that you're using now will be obsoleted and removed from portage altogether, at which point you either have to put the ebuild in your own private portage repository lest future emerge --update's break things or recompile anything which is at risk.
Now, most of these issues can be minimised by following practices that any good sysadmin should be anyway - for instance, setting up a test environment and making changes there first before putting them live. All this does, however, is move the risk from the live system to the test environment. It doesn't eliminate any of the work.
Maybe, but sid's the unstable repository and is intended for exactly this kind of thing. Even the Debian maintainers strongly recommend against using Sid on a production system because things are far more likely to break and they may stay broken for some time.
Windows does not have signal handlers natively. (or actually, only a few now that I google it:SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV, SIGTERM) There is the whole SEH C-language exceptions which take over some of the uses, but no other signals natively. So you won't write a signal handler that gets called on a timer.
Full signals for GCC-compiled programs would be implemented by Cygwin which should give you timer signals and so on. Since the standard way to upgrade GCC under cygwin is to use the cygwin upgrade/package manager, they can just make the new GCC package depend on an updated cygwin DLL which could set the correct flag for you in a thunk before passing on the signal.
Don't bother trying to compile GCC yourself under cygwin, it's quite painful. Or at least time-consuming, the slower process spawning makes configure take an hour or more last time I tried it a few years ago. And then you have to wait for make bootstrap to finish.
Then again, MS isn't notorious for following standards. If this does show up under windows (say when starting an SEH handler) they'll just say that that's the windows ABI and ignore it.
Hell, it might even be different under win98/XP/Vista, as they are different kernel.
There's an easy solution: A grace period. Let the kernel developers know (done), let the kernel developers fix their kernels (done), and give time for such fixed kernels to spread. Change the compiler so that it won't generate the "unnecessary" code, but DISABLE that by default for a while. After a long time (two years? More?), switch to enable-by-default. This change has no useful upside for users, and lots of downsides (in terms of broken programs), so there's no reason to hurry it. It's fine to do it, but just do it slowly.
Vista complaints have nothing to do with "too much backwards compatibility"; one of the key Vista problems is a LACK of adequate backwards compatibility: http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_List#Heavy_Problems.2C_Currently_Incompatible http://www.pcmag.com/article2/0,1759,2104022,00.asp
The only reason to run Windows (any version) is to be able to use the hardware and software that is only compatible with Windows. I know of no one who claims that Windows is the "best operating system on Earth", by any measure; people choose Windows for application compatibility, not for its "innovation". A "grossly incompatible Windows" is completely worthless.
Similarly, even if it's in the spec, it's absurd to change a system and make it so user programs just break. Think of the users. Instead, figure out how to make the change WITHOUT harming the users. That user might be you.
- David A. Wheeler (see my Secure Programming HOWTO)
Apparently you still don't get it. It is not a problem with GCC. It is a bug in the kernel. GCC just helped to detect it. Now, as its' been detected, it is no longer connected to GCC in any way.
They are used in memmove(), which you can hardly argue is not "used very much".
That is not an argument that should ever be made. This kind of messy, unpredictable problem involving the kernel is exactly the kind of thing that may suddenly turn out to be exploitable after everyone's assumed it's not, when somebody clever enough sets their mind to it. It's happened many times before.
You really want to err on the side of caution in these cases.
You lose one CPU cycle ?
Religion is what happens when nature strikes and groupthink goes wrong.
Intel is to blame. The original 8086/8088 instruction set was just dumb in this respect. Having a global value (the direction bit) that can determine the behaviour of a class of powerful instructions is a great way to generate all sorts of subtle intermittent bugs. I have been personally burned by this (badly) as have many others.
There is a policy you can enforce to try to improve things. You can try to make everyone leave the direction bit in the most common state after they are done with their less common use of the string instructions. This can work if the policy is enforced by something like a compiler. It won't work if the program is for instance called by another entity outside the control of the compiler. ...such as, for
instance, a kernel calling a signal handler... You end up with a state
of affairs where you have to depend on having some other programmer
remember to set the bit to the right state to have your string
instructions work right. You can't test for this as the bit might be
right almost all the time. This is simply a poor approach.
The only fix that can work reliably for your code is to have the compiler insure that the state of the direction bit is known before any string instructions are executed. If I am for instance using a C compiler I should not have to hear about the 8086/8088 string direction bit. ...ever...
The kernel people should fix their failure to respect the ABI policy. The GCC people should revert to the old more deterministic handling of string instructions. The almost negligible optimization here is simply not worth generating a lot of intermittent, hard to find problems (there are likely more out there). If other compilers do not make their string functions entirely deterministic in the face of all external influences then those other compilers are doing it wrong. We can't fix the hardware architecture so this is a case where defensive programming is the best that can be done.
Bruce
Fixing asap (in the kernel) is a necessity, but 'all' it really does is to cause affected programs to hang or abort.
What did Douglas Adams say? DON'T PANIC.
Mielipiteet omiani - Opinions personal, facts suspect.
I just heard that this has seriously set back the release date of Duke Nukem Forever!
All that we know it does. That was the point. We can not tell that that is all it can be used to do with any high degree of certainty.
I used to do assembler, and I can't think of any one time I actually used STD. I often issued CLD when writing interrupt handlers, because that was the safe practice, but is it really that useful to reverse string scans at the opcode level ? I can't think of that many places where it would be useful, easily replaced with a manually decremented loop that's not much slower. It always seemed like a risky thing to do in the first place, and I was never fond of issuing CLD all the time "just in case".
:/
My rant doesn't solve the kernel issue, we'll have to deal with legacy code forever
-Billco, Fnarg.com
If it was "exposed" by changing the compiler, the bug is in the compiler.
The kernels compiled with earlier GCC versions don't have the bug,right?
If someone changes the rules, and expects everyone to know it beforehand, it would be a fault in that guy, not the people abiding by the old rules.
On the other hand: the instructions affected by this aren't used very much, so if you want optimizations, a good candidate would be to not clear the flag unless it is needed.
That's how the old code worked - it cleared the flag before using instructions impacted by it. However, you can't say the affected instructions aren't used much.
All the string & bulk data instructions care about the direction flag. Unless your compiler generates really bad code, I'd expect memcpy, memmove, memcmp, strcpy, strlen, strcat, etc all to be impacted. realloc most likely would either call memmove or would use similar code as well if it has to move your memory to enlarge the allocation.
Also, things like assigning one struct to another is essentially an inline memcpy, hence that could be affected as well.
With the compiler no longer clearing the direction flag, any of those functions would misbehave if called with the direction flag set.
and future code could both conform to the new ABI *and* avoid the overhead of unnecessary instructions to clear the flag when it is not being used.
The flag only ever gets set when it's needed. Needing the flag set is rather rare, whereas most code needs it clear. Hence why the idea is that the code that sets the flag should be responsible for clearing it, rather than having to constantly clear the flag every time it comes into play.
I'd say it's very safe to assume Windows is compiled with Visual Studio and thus has nothing to do with any of this.
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.
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...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
yeah, on the other hand it is only because some people do use sid that bugs get spotted before they get a chance to make it into testing.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Using that logic Microsoft shouldn't try to improve security in Windows ...
Isn't that already their business plan?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Did some poking around and it looks like FreeBSD have fixed it for the -CURRENT builds : http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread/3df4366ff396a60b/bfc90b9b0a478628/
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//
Not acceptable!
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
Somewhere around 1 / (thickness of a human hair).
Program Intellivision!
I have been writing assembler code for x86 since the beginning. It has always been the coder's responsibility to assure the direction flag is set appropriately before using a repeating instruction. My favorite was "rene scasb". In the old days, we would, pushf ! cli ........ popf to assure the direction flag and place it back where it was before. This used to work in the 8086 time. When reviewing
assembler code, I often ask, where is the direction flag set, when I see a repeating instruction. Not setting it explicitly is risky coding.
Having separate privileges assigned to user accounts rather than a global root is one of the ways that windows is better than traditional unix/linux. W