Hyper-Threading, Linus Torvalds vs. Colin Percival

OutsideIn writes "The recent Hyper-Threading vulnerability announcement has generated a fair amount of discussion since it was released. KernelTrap has an interesting article quoting Linux creator Linus Torvalds who recently compared the vulnerability to similar issues with early SMP and direct-mapped caches suggesting, "it doesn't seem all that worrying in real life." Colin Percival, who published a recent paper on the vulnerability, strongly disagreed with Linus' assessment saying, "it is at times like this that Linux really suffers from having a single dictator in charge; when Linus doesn't understand a problem, he won't fix it, even if all the cryptographers in the world are standing against him.""

Comments

He won't fix it?

[Morgahastu]

Then somebody else will.

Re:He won't fix it?

[CaymanIslandCarpedie]

Oh come on man, don't be that guy ;-)

So MS$ shouldn't fix problems in IE until an exploit has been shown for it?

It's better to wait and see before fixing something that may not matter later.

Its better to just fix it and be safe than wait and see if something happens later. It may not be top priority, but remember this "wait and see" approach to security is exactly what got MS$ into so much trouble with users. We don't need the same for Linux.

Re:He won't fix it?

[antifoidulus]

Heh, this is more than just your average buffer overflow exploit. This fix would have to modify how the OS handles the cache. It's going to probably take more than a quick fix to get rid of the exploit, and the patch could have far reaching reprecussions. All that to fix a security hole that may not even be exploitable in practice....

Re:He won't fix it?

[jrockway]

His comment isn't from a CS perspective, it's from a code monkey perspective. CS people use mathematics to prove their code correct, application programmers write stuff and are happy it works.

Re:He won't fix it?

[null etc.]

By timing multiple runs you can get a decent estimate of how long time the strcmp function took, which means you can guess which character was first differing character in the password.

Can I buy some pot from you?

Maybe that would work with a ONE MEGAHERTZ PROCESSOR. But do you have any idea how fast processors are these days? And how likely any deviance in the cache state, IO controller state, page faults, multi-user latency, or power management will throw your precious timings right out the window?!?!?!

I mean, c'mon, think about things before you say them. Even REAL TIME SYSTEMS AT NASA don't run with enough consistency to be able to tell WHICH CHARACTER IN A STRCMP OPERATIONS fails.

Dictator?

[BBrown]

A dictator who has made his domain open-source, thereby giving everybody free reign to change and make distinct copies of it?

Come on.

OK Colin, Well done

[Timesprout]

you found an obscure and difficult to exploit vulnerability. Now quit trying to make out the world is doomed and trolling on Linus to keep the spotlight on youself.

Re:OK Colin, Well done

[TuringTest]

If this was about Microsoft and Bill refused to fix the vulnerability, nobody else could write a patch for the sources to solve the problem. See the difference?

Fixing is easier said than done

[Xpilot]

The kernel developers don't seem to agree on the right way to fix this, whether at the kernel level or in userspace. However, it may affect the performance of the kernel if it's done in kernelspace, and it is impractical to have everyone rewrite their userland software, as someone else pointed out. The "patch" which is available for FreeBSD to fix this problem only disables hyperthreading and does not provide a real fix.

This sort of attitude is pretty common

[Raleel]

It's along the same lines of the "if all you got is a hammer" problem. If you've spent a lot of time working on something, it's obviously important to you. That doesn't mean that it's important to everyone else. This may well be a significant flaw from the crytographer's perspective, but then again, they study crypto a lot and have a vested interest in it.

As someone pointed out, yay for linux being free. As one or two above pointed out, someone who does care with the knowledge will write a patch. It'll get implemented as an option in the code, and if shown to be unobtrusive enough, may even get turned on by default.

Re:This sort of attitude is pretty common

[Otto]

Hence, this is an issue that effects me and my customers, and I seriously hope that a fix finds itself into either apache mod_ssl or the mainline Linux kernel PDQ.

That's really what's up for debate here. Whether the patch should be in the kernel-land or in the code user-space (mod_ssl, for your example).

The only realistic patch you could do in kernel-land is to simply disable HyperThreading. This works, but seems like a poor way to go. Any other form of patch in kernel-land just makes the attack harder and thus doesn't really work or it degrades performance way too much to be practical.

But fixing it in userspace is somewhat easier to do, albeit you'd have to fix *every* user-space program that's susceptible to this sort of thing.

Let's talk about the problem in general terms. When a program is doing some kind of computational stuff on something you want to remain secret, then it has to make some assumptions. Assumptions like the hardware is secure, or that it's not running on a virtual machine that's recording everything it does.. That sort of thing. You can come up with all kinds of ways to crack it like an egg if you work outside the box a bit and have total control of the machine it runs on.

This problem is attacking one of those assumptions, namely that another process can't time the secret computations accurately enough to perform a timing attack. With HT, you have two things running on the same core, and so it is somewhat easier to do this sort of attack.

So userspace programs that do secure computations have had one of their assumptions broken by HT. To remedy it, they need to rethink their assumptions. They need to or ensure that they perform equal timings regardless of the computations being done and so on. This is not particularly simple, but it's probably not particularly hard either.

Of course, the attack is still largely theoretical. All it's been shown is that it's "possible", not that it's "easy" or even that it is indeed "doable". For one thing, without having some kind of clue as to the algorithim involved or some idea of what to look for, all you get are a bunch of timings. You still need to do some things to trigger it at the right time and in the right way as to be able to derive information from this channel.

But crypto guys are paranoid like nobody else, and so they're naturally worried about this sort of thing. Mainly it's worrying to them because it's not a mathematical attack, which they're more used to. Modern crypto works based on theory and algorithims and such, and the idea that the algorithim being correct (for a given value of "correct") isn't enough to protect the security of the data is extremely worrying. A real world implementation of these algorithims now has to take some more real world facts into account, and this bothers them, of course.

Linus is basically right here. The kernel is simply the wrong place to fix this. It doesn't ensure that processes cannot spy on other processes via subchannels like this, nor should it. If you're paranoid enough to think this is a real thing to guard against, then your secure code should take it into account. Existing code doesn't do that, and would need to be changed *even* if the kernel was patched. Because how do you know that your kernel has been patched? How do you know that you're not running on an HT processor? You can't know for sure, so you simply assume you are and take steps to make timing attacks fail. Because if you don't, you can't reasonably say that you've attempted to secure the code in this way.

Another Fairy Tale...

[ausoleil]

In layman's terms, this debate is:

Scene: A wispy cloud scuds across the sunny blue sky. Not much happening, and the cloud is hardly even black.

Chicken Little: The sky is falling! The Sky is falling!

The Penguin DictatorNo, not really. It might fall, but it's very, very unlikely. So calm down!

Chicken Little: I strongly disagree. The sky is falling! And because you do not understand the problem we're all going to die!

The Penguin Dictator:Listen here. It's almost certainly not going to fall, and I need to worry about real problems!

Chicken Little: (Runs screaming to the nearest coffeehouse with free wireless, where he types incessently:) The sky is falling! The Sky is falling! Tell Slashdot! Tell Tom's Hardware! Tell Cnet! Tell Linux Business News!

The Penguin Dictator: Sigh. (And then he gets back to work. He looks up at the audience) They just do not get it, do they?

The Windows Dark Lord: (Rubs hands together) Excellent, MOST excellent. (Yelling) Bring me my marketing minion!

Marketing Minion: (being drug in by a bald guy yelling at him) Yes, O Master!?

The Windows Dark Lord:Tell all the peasants that the sky is raining huge chunks of fire and dung! Tell everyone, tell them now! And have our independent consultants work on this day and night, night and day! Make sure that they independently tell everyone that they can easily avoid falminf chunks of sky dung if they stand behind our Windows! And RAISE the price!

Some Guy At Some House In Some City Somewhere: "Wow, that was easy. Let me send this up to the Penguin Dictator. No sky ever fell, and that cloud is easily blown away. Nothing happening here, move along."

The Penguin Dictator "Well that was easy. Include this patch in the next day's weather update!" Marketing Minion: Press Release!!! Millions killed by falling flaming sky chunks of burning dung with brain eating worms who eat children!!! Run for your lives!!!!

Laura Didio, munching a do-nut"If you would hide behind Windows, the sky would stop falling! Your children would be safer and the world a better place." (looks at stoick ticker, says to self) 'Excellent. MOST excellent. Bring me a donut!'

The Penguin Dictator "Sigh. Why didn't I just keep Sky 0.7a for myself? Why the bother, wy the bother?"

EPILOGUE: No one was ever hurt by the piece of sky that never fell, and Chicken Little kept looking upward for another cloud to rant about.

The End.

Re:At least Linus....

[mattgreen]

Nice ad hominem attack. Attack the argument, not the person.

Re:bad tactics from Colin Percival

[jsonn]

Get the facts. Colin showed that you can retrieve ~30% of a RSA key by running a program in parallel. This can be improved most likely if you have the chance to do it more than once. It is also imported to keep in mind that you can't entirely avoid an unbalanced memory access pattern without also taking a huge performance penalty.

The point of this debatte is that the Intel implementation sucks, it allows you to spy a lot on processes running on the virtual CPU. Sure, there are better alternatives than disabling HTT like the suggestions of Colin to only schedule threads of the same program on the virtual CPU. Actually, that is something you want to do anyway or otherwise you can seriously loose speed and drop under the performance of a processor with HTT disabled.

Speaking of paranoia, it is often not a bad thing to have, many big security problems can be avoided. Oh, I forget to patch the Linux box next door.

If security matters, don't do crypto in Linux

[swillden]

... or in any other general-purpose operating system on a general-purpose computer. PCs are fundamentally insecure. There are a dozen ways to spy on cryptographic operations done in them, ranging from trojans, to hardware side-channel attacks, and dozens more to get copies of keys that they store. This is just one particular attack that may permit an attacker who can't get a trojan running with sufficient privileges to spy on operations directly to obtain some key bits. But if the attacker can't do that, there are lots of other ways to get the keys. General-purpose computers are simply not trustworthy.

If security is important, you do your crypto in a secure crypto module, like the FIPS 140-2 Level 4 IBM 4758 or the Level 3 Luna SA. Or, you use a general-purpose computer with special-purpose, very simple software and then provide strict physical access control to the machine and very limited network access -- often through a serial link using a custom protocol rather than via a real network. Or you could theoretically use a general-purpose machine with a TCPA chip with a regular, general-purpose operating system that has been modified to make use of the TCPA chip and with keys tightly bound to a well-defined system software configuration. But only if you have good physical security. In many situations it's still better to use a FIPS 140-2 Level 3 or Level 4 device.

IMO, the existence of weaknesses like this in Linux, and the fact that they're widely known, is a *good* thing, because it helps convince people not to trust that which is inherently untrustworthy. We need more publicity of similar problems in Windows (and there are lots of them).

Bzzt! Back the paradigm up here.

[Paradox]

From what I've learned in software writing, is that it's preferrable to wait and see how much and how bad your software runs or has problems before you start charging into the situation to fix it.

Wait. Wait wait wait. Who taught you this? This isn't XP. This isn't sound software practicies. Maybe you're thinking of the infamous quote by Car Hoare, "Premature optimization is the root of all evil," perhaps?

Potential performance problems are things you should defer on until proper profiling can be done (unless they're total show stoppers). Security and correctness are things you cannot ignore except in extreme cases. Security is particularly important to nail down, because it can result in your customers losing data (even data not pertaining to your app), which is the first no-no of software.

Application software has four priorities, in this order:

1. Safety (shouldn't destroy data)
2. Correctness (do what it says it does)
3. Security (don't do anything else)
4. Performance (do it fast)

YMMV, of course, sometimes correctness falls below security, and occasionally performance goes above correctness in some mathmatical functions (if doing it correctly would take a decade and doing a close approximation would take a day, obviously you want the approximation and then a heuristic).

Especially something as low level as this, which could have unseen side effects. Especially since this (to me, at least) seems to be more of a hardware problem than software, per se. (But, of course, I could be wrong.)

In this case, I'd say proper fix is to disable hyperthreading by default, and make sure the user is aware of the hardware bug/consequence of using HT when they decide to turn it on. You need to let the user decide if they're willing to accept the security risk or not.

The Linux Kernel Developers may decide otherwise, but that's how I'd call it if it was in my shop. It's a hardware problem and the software fix is not obvious.