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?

[untouchable]

Fix what?

If I remember correctly, there hasn't been a shown exploit for this yet. It's better to wait and see before fixing something that may not matter later.

Re:He won't fix it?

[Vo0k]

Actually, my bet is it will be fixed in the new CPU revision, by Intel. And eventually Kernel fix dug into the config somewhere next to other "bugfix/support" entries, with note like "Early multithreading Intel Pentium 4 CPUs have a vulnerablity that allows to override privledges of a process. This entry includes a patch for this bug at cost of increasing the kernel size by 32K and slightly slowing it down. If you have an early Pentium 4 processor and run a multi-user system, say Y. If you don't or aren't sure, say N."

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?

[Threni]

That reminds me of the joke about programmers being in a car, steaming downhill with failed brakes, narrowly avoiding death, then once the car has come to a standstill suggesting that instead of seeing what went wrong they just get back in the car and `see if it happens again`.

Re:He won't fix it?

[/ASCII]

I'm not to sure about that. Linus says this is a library issue and I agree. The kernel should not try to fix library bugs.

What this bug amounts to is this: When a program is performing calculations using secret data like an RSA key, it is important that the data access patterns do not depend on the secret data, since these patterns can be analyzed by an attacker.

An example of a classical vulnerability of this sort is using the c function strcmp to compare the real and the supplied password. 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.

The security flaw in HT is that a process running on a HT CPU can get quite a lot of information about the data access patterns of the process on the other virtual CPU on the same chip. In other words, the severity of any library bugs which cause different access patterns on different secret data has been severly increased.

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.

Re:Dictator?

[Tjebbe]

or, to put it in Pratchett's words:

He doesn't administer a reign of terror, just the occasional light shower.

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.

Re:Dictator?

[squiggleslash]

The guy was refering to the oft-quoted observation that Linus is a "benevolent dictator", or rather than Linux's development model is one of benevolent dictatorship. It wasn't an insult aimed at Torvalds. It's a comment about the development model used by many FOSS projects. See also Larry Wall and Perl, or Guido Van Rossem and Python. In all these cases contributors to the projects defer to a project figurehead who makes the final decisions as to what goes into the official version of the project, and where that project goes.

The most common alternative model is community development, where a - usually but not always elected - committee of developer 'elders' steer the project. Apache and Mozilla would be good examples of the latter.

I appreciate some people have heard about this comment first today, people are joining the Free Software and Open Source communities all the time, but it kind of surprises me that so many are criticising Colin for this without anyone explaining this.

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

Fix the applications

[Tom7]

Why should this be fixed in the Kernel?

This appears to be an application bug, not a kernel one. The kernel never claims to completely isolate processes from one another; though there are memory protections, there are loads of ways that processes can observer each other's actions. This is just a particularly high-resolution one.

The real "bug" here, IMO, is that openSSL believes that no other process can observe anything about its secret computations. Timing attacks against RSA have been known for some time, particularly with regard to modular exponentiation.

It wouldn't be too hard to make RSA encryption take the same amount of time no matter what code path is used, and to make its memory access patterns uncorrelated with the keys (perhaps by using randomization during allocation). They should do this--the fact that their application leaks information has nothing to do with the processor it's running on; it's just that HT makes it particularly easy to measure that information. This would have a performance penalty, and I think the OpenBSD folks are too obsessed with performance, and that's why they've not done this. The performance obsession is a serious problem in the Unix world, and software systems in general.

If implementing openSSL effectively means adding special kernel support for things like constant-length timeslices or cache invalidation between context switches, that's fine. But this is not a bug in the kenel unless the kernel purports to enforce total separation between processes, which it certainly does not.

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.