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?

[lintux]

And how is that somebody else going to make Linus accept the patch?

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?

[Niekie]

And it might be best to start researching it as soon as possible before it will be massively exploited by someone who just found out how it works..

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?

[ssj_195]

If others were to "fix" it, they would be working on a copy, and they would be starting an entirely new fork altogether. I, for one, certainly don't want that to happen.

I think pretty much every distro in existence maintains its own patchset for the vanilla kernel (effectively maintain their own "fork", I guess), and it is not causing any problems. In brief, if Linus does not accept a useful patch (or essential!), the distros will, and so this "forking", if you can really call it that, will have no negative effect on the end-user.

Re:He won't fix it?

[Jugalator]

Why wouldn't he?

He doesn't say "I don't want a fix for this anywhere in the kernel" anywhere. Just that he doesn't think it's a very critical issue.

If someone else does the patch for him, why wouldn't he accept it?

Re:He won't fix it?

[A beautiful mind]

There is nothing to fix there, most of the coders agreed!

Some people are just keep pushing their flawed agendas.

Disclaimer: i did read the whole thread.

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?

[ysachlandil]

And how will they fix this?

The only fix that kinda works is disabling hyperthreading. But on a dual core processor the problem is there as well (if there is a shared cache somewhere). And switching of the second core because of that would be stupid.

The problem Colin points out (getting an RSA key) is a userland problem anyway, so there is nothing to fix for Linus... fixing cache eviction covert channels in the kernel is possible, but not without losing a lot of performance.

--Blerik

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?

[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?

[julesh]

It isn't something Intel can fix, except by removing hyperthreading. The fact of the matter is that if you have two processes running simultaneously on the same processor, one of them can determine things about what the other is doing based on how many execution units of what type it seems to have access to, how long data remains in the cache, things like that. It's a fundamental problem that can only be fixed by the OS kernel denying use of hyperthreading to processes that need to be kept separate from one another.

Re:He won't fix it?

[Vellmont]

That sounds like it has some non-trivial costs associated with it. That would mean losing performance in many instances where two high-cpu processes want to be exectured on a single physical processor at the same time.

The best solution is to just fix the crypto libraries as a short term solution, and for Intel to fix the chip in future iterations as a long term solution. Mucking about in the kernel and having other unknown effects seems like a bad approach when the problem can be fixed elsewhere.

Re:He won't fix it?

[julesh]

The best solution is to just fix the crypto libraries as a short term solution, and for Intel to fix the chip in future iterations as a long term solution.

Fixing the crypto libraries is actually a non-trivial task. There are many of them and ensuring there is no information leakage is very difficult to achieve.

Fixing the chip may well be impossible -- it sounds to me like the only way to prevent this kind of thing from being a problem is to give each thread its own instruction fetch pipeline, dedicated execution units and dedicated cache lines. Which is, in effect, dropping HT altogether and switching to dual cores instead.

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.

Re:He won't fix it?

[robertjw]

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

Programmers hell, most mechanics I know have this attitude. 'Well, it stopped, didn't it. We'll fix it later'

I wouldn't blame software developers for this attitude, it seems to be common for humans (or at least Americans) as a whole.

Re:He won't fix it?

[hey!]

I dunno if I agree, for two reasons. First, you'd be surprised what a sophisticated, determined and deep pocketed adversary can do (e.g., the smart card vulnerabilities that were uncovered a few years ago by analyzing the power consumption).

Secondly, just because the clock is ticking fast doesn't mean you can't count them as they go by. The same process run at 1Mhz and 1Ghz is going to look substantially the same, because you're monitoring them faster too. If anything, you're less likely to get interrupted by I/O during the process.

Re:He won't fix it?

[SQL Error]

"Beware of bugs in the above code. I have only proven it correct, not tested it" -- Knuth

Re:He won't fix it?

[Austerity Empowers]

Faster processors also means that you don't need to be as precise. You can search more possibilities faster, but every byte you can chip away helps narrow down the search range.

It's true that there are various "noisy" and uncontrollable aspects of modern CPUs, but if you take enough measurements and can establish a control, you can get valid information. It will not give you "the answer", it may help you to eliminate a set of data that is "not the answer". That is extremely valuable.

Some people actually monitor chip power supply variations to try to get this information. I won't pretend to understand how they get meaningful data from this, but it involves knowing the system under attack very well, and wanting the data really, really badly. Hence very high security systems shield their processors magnetically and inject "noisy" (bogus, unrelated) operations to cover this. It sounds like a pipe dream, but I've visited places where these systems are built (think Blue), and read some of the papers describing these exploits.

His point is valid, ANY information an attacker can get significantly reduces the integrity of the encryption. I just suspect Linus' point is that most (I said most, don't flame me) linux server deployments are geared towards not letting people on the server in the first place. This vulnerability seems to be valuable mostly to people who already have access to the system.

Re:He won't fix it?

[donleyp]

If you had read the original paper, you would know that they created a proof of concept that actually works. They were actually able to grab RSA keys from the other process! So, how is it impossible? It's been done.

Re:He won't fix it?

[IIH]

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.

Maybe the original poster was referring to the DEC-10 page fault password insecutity that was based on strcmp returing as soon as it encountered once wrong character, based roughly on the following idea:

1) Place Password with 1st/2nd character on a page boundry.
2) Clear cache
3) Call Password check.
4) If no page fault occurred, then the 1st char must be wrong, change it and goto 3
5) if page fault occurred, 1st character is correct (as 2nd char was checked), move password so 2/3 char is on page boundry and repeat.

In this way, you can reduce the attack by a huge amount, for a n length password the brute force attack needed goes down from 256^n to 256*n.

So, yes, attacks based on which character in strcmp fails have worked in the past, so it is valid to try and not make the same type of mistake again!

Re:He won't fix it?

[Dog135]

like the old maxim goes, there's no security if the attacker has physical access

Yup, if the security is based on a simple string compare, and you have physical access to the machine, all you need to do is modify the assembly. I use to do this to all my old computer games that required me to enter information out of the manual. Just invert the condition of the branch, then jump over the dialog call.

The way I compare encryption passwords in my programs, is to compare a hash of the end result with a stored one. ("end result" being the string of data that you xor against)

Re:He won't fix it?

[wirelessbuzzers]

Yep, and like the old maxim goes, there's no security if the attacker has physical access. Alot of this collegiate discussion of measuring voltages and doing fine-grained timing would require having physical access.

No. It requires having shell access. This is not the same as physical access, and a system should be secure against an attacker with shell access. Not that most are in fact secure, but they should be.

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.

Single Dictator?

[Anonymous Coward]

If Linus decides that he does not want to bump its priority up, someone else can fix it. Thats what fellow kernel developers do.

If Microtoft decides not to fix it, then no one else can.

so which one is a single dicatorship?

Re:Single Dictator?

[bloodbob]

Linux developers can fix it but the fixes won't go in linus says what goes in and what doesn't.

Re:Single Dictator?

[MoonFog]

Most distros have tweaked the kernels to suit their needs anyway, nothing stops them from implementing this in their own kernel version.

Re:Single Dictator?

[js3]

when I first read your reply I thought it said
Most dictators have tweaked the kernels to suit their needs anyway, nothing stops them from implementing this in their own kernel version.

bad tactics from Colin Percival

[Anonymous Coward]

The answer to Linus' assertion that "I'd be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it" is not to say "Well we all think its bad", but to produce a proof-of-concept exploit.

If he and "all the world's cryptographers" can't do that, then Linus' pragmatism beats the cryptographers paranoia (their defining quality, in my experience) into a cocked hat.

If an exploit can't actually be exploited, it's not and exploit.

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.

Re:bad tactics from Colin Percival

[Gopal.V]

"I'd be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it"

Being able to read arbitrary memory from another process is a big security flaw, as illustrated by the Minesweeper Hacking sample. But for a kernel programmer it's a minor deal for server security as it needs a local/remote exploit to run code on your box. Even then it is a readonly exploit, which decreases exploitability unless we're talking about stuff like SSL certs or GPG keys - which are pretty hard to find in 1 Gb of data :)

So to really exploit this, your thread should be running the CPU practically or 100% CPU. That should be an easy enough warning sign :)

Re:bad tactics from Colin Percival

[DrPizza]

The vulnerability is not Intel-specific. This kind of timing information can be leaked on any system that has data caches that are either too small to hold the entire lookup table an algorithm uses, or on an OS which multitasks, or use a lookup table with certain characteristics, or....

The problem is not with hyperthreading. It's not with Linux. It's with the implementation of the encryption algorithms. They need to stop assuming that table lookups are constant-time. Because they're not. As good as constant-time for most purposes, yes. But for cryptography they're not good enough.

Re:bad tactics from Colin Percival

[stratjakt]

I agree, why not have your crypto loops piss away a few extra cycles, randomly.

for (i=0; isome_random_number; i++) { do_some_stuff_that_looks_like_crypto }

This seems like another pointless nerd debate. It sounds like that "hack a key by examining the frequencies the CPU emits" type stuff.

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

[MoonFog]

I wonder what people would say if this was about Microsoft and not Linux? You think Slashdot would talk about it in the same way?

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?

Re:OK Colin, Well done

[maxwell demon]

Of course. Except that the roles would be taken by other people: The Linux zealots would play the "it's a major security problem" role, while the MS zealots would play the "there's no real exploit here" role.

Except that for MS problems you'd probably not actually hear about it unless an exploit has been found (MS would of course keep quiet about it, and others would probably not find out other than by creating an exploit).

However, IANASE

Re:Dictator?

[Tjebbe]

or, to put it in Pratchett's words:

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

Linus the great Dictator

[tronicum]

Just because Linus does not share the same opinion on the importance of this issue this does not mean that he is an dictator.

Colin needs to cool down a bit. At least the Linux distros (SuSE, Red Hat, etc are the ones which will get a problem from affected systems) are going to get patches for it. From Linus or any other Kernel developer.

Open Source, YOU win!

[xiando]

Linux is Open Source. So it does not matter what the dictator thinks. Because even if he is, like Colin childishly claims, a dictator, he does not have any real power over Linux users. There are, in fact, dozens of flavors of Linux kernels available on the market. And almost none of the major distributions today use the stock vanilla kernel, most of them ship with kernels who include numerous patches who are not part of the vanilla kernel. If Linus does not make a patch, someone else will. And chances are high the patches will be taken into the vanilla kernel. But even if such patches are not accepted into the vanilla kernel tree, they can still be applied to it. This is why Open Source wins. We have the source, the source is with us - And we are free to do what ever we like with it. I can apply a secure patch if one comes available regardless of what the dictator thinks of that, and that is obviously why it is totally wrong to call a person who is kind enough to use hours and hours of his time to develop something that greatly benefits mankind a dictator.

Linus and RMS

[uchi]

If Linus is the dictator, does that make RMS the court jester? On second thought, do dictators even have jesters? This does not look good for RMS.

Re:Linus and RMS

[daigu]

RMS is more like the tribal elder reminding you of your ideals - especially during those times when you consider putting them aside because they seem impossible to live up to.

Re:Linus and RMS

[AHumbleOpinion]

RMS is more like the tribal elder reminding you of your ideals - especially during those times when you consider putting them aside because they seem impossible to live up to.

No, not at all, the tribal elders would be the BSD folks. RMS is the witch doctor blowing smoke into your face telling you that it will cure all your problems. ;-)

but... but... but...

[databyss]

The all powerful Dvorak said linux had no leaders...

Re:but... but... but...

[saintp]

There's only one way to find the truth: cage match between Dvorak and Percival. Whoever comes out alive wins.

Re:but... but... but...

[Couldn'tCareLess]

You have a keyboard man? Where do you keep him? What does he eat?

I want a keyboard man!

Re:Dictator?

[Megor1]

Now that I think of it I've never seen Castro and Linus in the same room....and Linus always seems to be smoking fine cigars...and open source software is practically communism anyway...it all makes sense now!

Micro-Managing Minutiae Mayhem

[mathmatt]

when Linus doesn't understand a problem, he won't fix it

This is interesting logic: The idea that the creator of an organization must understand minutiae and micro-manage everything that the organization does.

Interesting indeed...too bad it's fallacious. (Although it might explain what is taking Longhorn so long to come out - I can see Bill Gates searching Google for whitepapers on file systems, search algorithms, GUI's, etc.)

Re:Micro-Managing Minutiae Mayhem

[mwvdlee]

No, that still wouldn't explain it. Bill gates searching MSN for the info would!

At least Linus....

[MarkEst1973]

...has a job. Naturally this guy would disagree with Linus. He's got nothing else to do. I, too, would strongly disagree if someone casually dismissed the past three months of my life.

From the original article

• Where do you work? I'm unemployed. For the past three months, I've spent almost all of my time working on this security flaw -- investigating how serious it was, contacting all of the affected vendors, explaining how this should be fixed, et cetera. I simply haven't had time to go out and get a job -- and I decided that making sure that this issue was properly reported and fixed was far more important than earning some money.

Re:At least Linus....

[mattgreen]

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

Re:At least Linus....

[squiggleslash]

There is no such exploitable vulnerability, most of the people on LKML can tell you that, and they certainly wouldn't fix it inside kernelspace would there be one. The fact that the guy STILL holds on to the issue was explained by the top poster.

Absolute rubbish, from start to finish. Even Linus Torvalds claims no such thing.

"As to the HT 'vulnerability', it really seems to be not a whole lot different than what people saw with early SMP and (small) direct-mapped caches. Thank God those days are gone.

"I'd be really surprised if somebody is actually able to get a real-world attack on a real-world pgp key usage or similar out of it (and as to the covert channel, nobody cares). It's a fairly interesting approach, but it's certainly neither new nor HT-specific, [nor does it] necessarily seem all that worrying in real life.

Torvalds is arguing it's unlikely to ever be exploited, not that it's unexploitable or that it's not a vulnerability. The position of those, excluding yourself, who dismiss this is that it's unlikely to be usefully exploited, not that it doesn't exist. We can see it exists!

As to your last sentence, no the top poster doesn't explain it. The top poster simply describes the guy as an obsessive because he's put a lot of time into it, far more than a reasonable person might reasonably be considered to do. That's different from saying he's wrong.

In your last paragraph you clearly demonstrated what is an ad hominem attack, and what is the difference between the top post and your post

My last paragraph was a comment about irony. It had nothing whatsoever to do with attacking your argument on the basis of who you are rather than your argument. It did, however, attack your argument. Your argument was that nothing this guy says should be taken seriously because of an accusation of being mentally off-the-wall. Nash is a perfectly good counter-example. The irony is that you unwittingly brought him up. There's no ad-hominem in there, I wasn't attacking you or your credibility, I was attacking your argument.

I don't care if the guy's obsessive. I care if there's an exploitable vulnerability. Until someone writes code either way, the issue is unproven, but it's clear there's a potential, if unlikely (not impossible, just unlikely) to be useful, vulnerability there. Your comments and those of the thread originator are not convincing because they attack the proponent than explain why the argument itself is false.

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.

Re:Fixing is easier said than done

[criscooil]

The "patch" [...] only disables hyperthreading and does not provide a real fix.

Unless I missed something, disabling HT _is_ a real fix.

Re:Fixing is easier said than done

[Urkki]

• Unless I missed something, disabling HT _is_ a real fix.

Sounds like it doesn't fix the problem, it replaces it with another (reduced performance). That's not a *real* fix to any problem.

Compare: doing suicide to "fix" personal problems.

Paper author just wants attention.

[tezza]

"even if all the cryptographers in the world are standing against him.""

All said cyrptographers should buy a non hyperthreaded cpu, or turn it off.

I mean if you use GPG on most machines, it will issue you a warning about Insecure Memory. That is someone could potentially harvest data from disused pages in memory.
These cryptographers would use a secure memory system. I'm happy hoping that MI6 isn't running a remote memory exploit on my box.

Re:Paper author just wants attention.

[Anonymous Coward]

The insecure memory warning is because GPG doesn't have enough privileges to allocate memory securely. It needs to be suid to work properly. It has nothing to do with a special type of memory for your computer.

Re:Paper author just wants attention.

[bogado]

As far as know, insecure memory is worst than that. insecure memory can be paged to the disk, and stay there for a very long time.

So even if you did not have any spyware running when you encrypted your secret files on where is the key to satellite that could melt the poles and flood all coastal cities, you would still be in trouble when 007 gets your laptop and searches throught your swap partition and find a suitable random looking bytes that luckily can decrypt everything, once more the free world is saved by Bond, James Bond....

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

[julesh]

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.

Well, no, however it is important to many people.

I, like many others here, run an e-commerce web site on Linux servers. In my case, my servers are virtual servers shared with other users who I do not have any knowledge of at all.

If the server used HT, it would be possible for one of those other users to run an exploit on the server to crack my e-commerce site's private key. Fortunately it doesn't, but my ISP could upgrade at any time...

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.

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:This sort of attitude is pretty common

[poot_rootbeer]

If the server used HT, it would be possible for one of those other users to run an exploit on the server to crack my e-commerce site's private key.

It may be possible, yes. But plausible?

this is an issue that effects me and my customers

It MAY affect you and your customers at some later time, but right now it doesn't.

If you're THAT concerned about this issue, I assume you're going to call up your ISP and transition your site onto dedicated machines? Isn't it worth the extra cost to be assured that some other customer of the shared server environment can't compromise your crypto key?

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.

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:Another Fairy Tale...

[Drakonian]

There are serious problems with your endearing allegory.

1. Microsoft is just as potentially vulnerable as Linux. Their dirty laundry just doesn't get aired in public.

2. The fix is non-trivial and non-obvious. It's not a simple buffer overflow. Any patches are likely to have serious repercussions on kernel performance. e.g. disabled HT, ensure only two threads of the same U.I.D. are scheduled on the same processor, flush cache at every context switch, etc. It looks that Linus is unwilling to accept them unless this vulnerability moves more from the theoretical to proven.

Great

[Mensa Babe]

"it doesn't seem all that worrying in real life."

Yeah, just like a mouse driver having full access to kernel security structures and raw disk partitions, it doesn't seem all that worrying at all (except when your entire system crashes thanks to a buggy sound driver, or you get rooted, or...).

Not fixing this design mistake while laughing at respected experts in the field reminds me something. I was hoping that we as a community might have became a little bit more mature during the last decade, but I seem to have been naïve again.

Re:Great

[Slashcrap]

Not fixing this design mistake while laughing at respected experts in the field reminds me something. I was hoping that we as a community might have became a little bit more mature during the last decade, but I seem to have been naïve again.

I don't think Linus was "laughing at respected security experts" at all. For one thing this guy isn't a respected security expert - in my experience they usually have jobs. Secondly he wasn't laughing - his point was that the best way to fix the issue was to patch the userland crypto programs to be more immune to timing attacks e.g by making them read a set amount of cache lines each time. Anything that makes the crypto software more immune to these things seems good to me.

Also, how do you patch the kernel to stop this attack? The FreeBSD patch just disables hyperthreading.

I assume you can answer this since you sound like an expert. I also assume that you bothered to read the actual e-mails and not just the retarded Slashdot blurb.

But now I'm being naive aren't I?

Re:Great

[Anonymous Coward]

He ran the bloddy "exploit" well over 1000 time to retrieve 30% of an RSA key.

Stop a mo and take a deep breath.

Take a look at your (heavily patched I'm sure) machine. If you had an unsupervised 24 hours with that box and an unprivileged account how many other actually useful exploits could you run for key retrieval.

I can think of about 5 methods right now that are much more likely to yield results within Linux. Even on a very up-to-date system with a decent admin.

Pfft.

- Storm in a teacup

Re:Great

[cperciva]

He ran the bloddy "exploit" well over 1000 time to retrieve 30% of an RSA key.

Did you read a paper other than the one I read? I ran the exploit once, taking under one second, and I retrieved enough information to factor the RSA modulus N.

wow, a paper, no kidding

[l3v1]

Colin Percival, who published a recent paper on the vulnerability,

Well, it's obvious that he has to be right then, since he has published a paper on the topic, right ? Right ? Nobody else can "understand a problem", only him, since he's got a paper on it. A real paper.

All the cryptographers in the world...

[bmf033069]

"even if all the cryptographers in the world are standing against him"

Who would understand what they are saying anyway?

The man

[Rinisari]

Linus seems to be intelligent enough to understand when to undertake certain tasks. Up to now, no one knew about the vulnerability. There hasn't been solid proof of exploit released in virus form yet. All this is, as of yet, is FUD. Linus doesn't want to reshape his priorities because of newfound FUD, and he's very smart in doing this.

I'm sure that if an exploit is found, someone will have a patch ready for the next kernel revision - that's the beauty and advantage of Linux.

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

Re:If security matters, don't do crypto in Linux

[julesh]

That's good advice, but many people cannot afford to follow it. Specialist crypto hardware is too expensive for most users, and keeping a PC in a physically secure environment can be difficult and contradictory with other important considerations. There are many thousands of small internet-based businesses who simply cannot afford this level of protection, and must rely on "secure" servers rented from virtual server farms. Fixing problems like this quickly after they are discovered is important to help protect these people.

Re:If security matters, don't do crypto in Linux

[swillden]

Specialist crypto hardware is too expensive for most users

If your secrets are worth enough that an attacker would go to the effort required to use this exploit... no, it is not too expensive. An IBM 4758 costs just over $1000 and provides an extremely high level of security.

If you want to go really cheap, and don't need high performance, you can also use a $10 smart card with a $10 smart card reader. The result is less secure than with a 4758, or a Luna SA, or any of the other products on the market, in several ways, but it's much, much better than doing the crypto in main memory on a GP CPU.

and keeping a PC in a physically secure environment can be difficult and contradictory with other important considerations.

Again, if you need security you have to do what it takes to get security. If security requirements contradict other requirements, you have a problem to solve.

At bottom, the point is that this is a sophisticated attack. There are much easier ways to dig keys out of a GP computer. If you need to defend against this attack, then you also need to defend against all of those, and defending against all of those requires physical security and use of secure crypto hardware. By the time you've closed all the other avenues of attack, you've closed this one, too.

This problem is real, and it's a good idea to fix it, on principle. But it's not uncommon that real security holes are simply irrelevant because of other considerations.

This is analogous to someone pointing out that my house is insecure because the attic vents are made of lightweight sheet metal. An attacker can use a ladder to climb up, use a crowbar to rip the vent off, climb into my attic, find the access panel and drop down into my house. That's all very true. However, compared to all of the *other* ways there are to break into my house, it's simply irrelevant. My house is simply not an appropriate place to store the Hope diamond, and replacing the attic vents with heavy steel ones, or otherwise securing access to the attic, isn't going to change that.

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.

Re:Fix the applications

[Tom7]

Allegedly the OpenSSL code has over 1000 data-dependent if-statements

I don't doubt it, and it would likely take a rewrite of the RSA code. But RSA is a very simple algorithm, so I believe it can be done without much trouble if one doesn't obsess over efficiency.

Practically speaking, just fixing modular exponentiation (which is the core of encoding and decoding) to call exactly the same bn_ functions whether the key bit is 0 or 1 would seem to fix this particular problem.

Re:strcmp vulnerability.

[Carewolf]

No just compare every character in the input everytime, rather than short-cut when you know it wont match.

Re:strcmp vulnerability.

[NighthawkFoo]

Hashing the passwords would probably help in this case, since then a single character change would completely alter the entire hash.

Re:strcmp vulnerability.

[/ASCII]

Easy to miss, huh? Adding a random delay only means that the precision of the meassurments decrese, so you have to do more repeats to get an accurate result. The real solution is to make sure that the data access pattern is always identical.

The normal solution is to store both the the real password and the password supplied by the user in a memory area that is as large as the maximum password length and zero padded and do something like this:

int verify( const char *s )
{
int i, ok=1;
for( i=0; i<MAX_PASSWORD_LENGTH; i++ )
ok &= real_password[i]==s[i];
return ok;
}

Note that it is also vital thet the password supplied by the user is zero padded and the calculation time can not depend on how long that password is. If it did, it opens up to man in the middle attacks. Evil, huh?

Other examples

[John Harrison]

One need only to look at the smart card world to see all sorts of side-channel attacks that are harder to execute than this. First there was power analysis, then when countermeasures were implemented there was differential power analysis, then more countermeasures, now the use RF leakage, so there are countermeasures against that.

If a process is leaking information somewhere, then there will be people clever enough to pull that information out.

That said, it seems that this is more of a library problem than a Linux problem.

If you need any real security you should be doing your private-key operations in an HSM anyhow, not on your CPU.

Re:strcmp vulnerability.

[/ASCII]

Not enough. You still have to make sure the hash functions runtime doesn't depend on the length of the password, or you will still be vulnerable to man-in-the-middle attacks.

Algorithms like SHA work on blocks of data, so what you need to do is make sure the code for padding the password to full block length doesn't change the runtime.

Not a kernel problem

[ajs318]

This isn't a kernel problem.

It's either an application problem or a hardware problem. Basically, used memory is not being zeroed out, so one programme can look at what another programme left behind.

In the case of a software frame buffer {like the 1980s home computers with bit-mapped graphics: Spectrum, BBC et al} failure to zero out memory causes spurious artifacts on the display. You can see this if you switch between graphics modes by writing to the hardware registers directly rather than using the "proper" system calls which clear the screen. {On the Beeb, you could actually grow a stack through the display memory. Pretty, but you'd better hope not to scroll the screen or print over that area.} The solution was implemented in software: create system calls that zero-out the display memory when switching graphics modes. {As a bonus, your users need only send one number to the routine, which can poke the right values into all the relevant registers on their behalf. They just don't get to invent their own graphics modes, but if you ever update the display ULA in future then at least you won't kill half the games software in existence.}

What we're talking about here is cache memory not being zeroed out between uses by successive processes. That looks to me very much like a hardware problem. It's not even an easy problem. My guess is that the implementors looked at it, decided "It's potentially insecure in theory but bloody difficult to make use of in practice", and left it that way on purpose. Like there's no point fitting an expensive lock on a wooden door with a person-sized glass panel in the middle of it -- especially if that door is only accessible through an overgrown garden with an underfed Alsatian in it.

BTW, crypto software running in userland could never, ever be made immune to snooping from kernel space -- at least, not on a system with any kind of debugging. The solution is to read and understand every bit of the kernel source -- including all drivers -- or get some independent expert to do so for you, so as to be sure the kernel contains nothing that could be used for malicious purposes. Hardware crypto devices would be more immune to tampering -- but less susceptible to independent verification.

Imagine this: <CHEESY MEXICAN ACCENT>Hey, extranjero! You want to send secret message? I chave code so secret, nobody onderstand eet 'cep' for me an' my brother. Djou dictates to me, one word a time, I write eet down in secret code. Then I send eet to my brother and che go to your amigo, and read heem the secret code. Nobody in world onderstand 'cep' my brother.</CHEESY MEXICAN ACCENT>

Vendor kernels contain patches

[Jeppe Salvesen]

If Red Hat or SuSE or anyone else disagree with Linux, they can simply produce and apply a patch to their own kernels while releasing the patch itself to the public.

This is one of the good aspects of open-source software: If you disagree, you can fork or simply distribute a patched product.

A possible solution

[jesup]

This issue exists with AES implementations as well (search for AES SBOX cache timing on google). The AES vulnerability is, if anything, more worrying in a way. It can be made to be constant-time, but at a serious cost in performance.

Here's another option: since this vulnerability depends on using the L1/L2 cache states to ferret out information, remove that from consideration. When processing an RSA (etc) key, have the code temporarily lock out context switches, AND have it take a fixed period of time to compute the result (or portion of the result), followed by flushing the cache. No data is left in the cache to analyze. The execution time of the code is fixed, so no dat leaks there. You don't have to make the algorithm a constant-time calculation if you can pad it at the end to the maximum (or close enough to the theoretical maximum that there's no true information leakage in practice). This helps avoid the potentially very slow algorithms that are truely constant-time. And flushing the cache at the end of each (portion of the) calculation removes that as a leak. (You need to flush it before waiting for the allocated time to elapse, note, and include max flush time in your calculation, and if possible factor into your calculation possible interrupt effects.)

A pain? yes. Requires extensive mods to crypto algorithm implementation? Yes (though perhaps not to the core calculation.) Requires OS support? Almost certainly. Requires HW support? Would be helpful but probably not required. Loss of performance? Yes, though far lower than disabling HT I imagine in normal cases (when not decrypting/encrypting).

Also, some of the restrictions above can probably be eased if the crypto algorithm is carefully designed and matched to the hardware.

Disclaimer: I am NOT a crypto geek! I have worked in processor and cache design, though.

Re:strcmp vulnerability.

[iamacat]

I didn't know it was possible to time anything as (ostensibly) quick as strcmp.

strcmp may be fast, virtual memory is not. You just make sure that your password ends up split between two pages in the comparing program - for example by padding the previous thing you send over network with spaces. Then generate some activity to make sure most of the things are paged out. Now if the part of the password on the first page is correct, the program will take longer to return failure and an extra page should be visible through vmstat. By repeating this with different alignment, someone can guess your password character-by-character.

I am afraid multi-user systems are there to keep students from stealing each other's homework, not for protecting military secrets. Over the Internet, such small variations in timing should be impossible to measure. You can insert a random delay every time your program processes an incorrect password for good measure.

Fixing is easier done than said: WBINVD

[redelm]

Look: if anybody is seriously concerned about cache snooping, just patch in a WBINVD instruction as part of return-from-interrupt. That will flush the dirty cache lines back to RAM and invalidate the rest. Yes, there's a horrible cost. Perhaps higher than doing without HT. But you will be secure against the boogyman! FWIW, I agree with Linus -- this is a theoretical, negligible threat, vulnerability. It doesn't yield data, and most crypto has fixed (rather than revealing) access patterns.

Re:probably easy to fix

[cperciva]

I wonder why Colin didnt' spend his 3 months of unemployment making a user space fix for this issue...

Two reasons: First, I was busy informing vendors -- Intel, Microsoft, the *BSDs, and Linux vendors -- about the problem and explaining the possible solutions. Second, because fixing every application in the world (this doesn't only affect cryptography) would take far more than 3 months.

Colin Percival only cryptographer in whole world

[iabervon]

Linus probably would do something about this if all the cryptographers in the whole world said it mattered. But, so far, Percival is the only person who seems to think it's actually a problem. Nothing on the subject from Bruce Schneier. And, while he says Linus should talk to the SELinux people, he probably doesn't realize that they have almost certainly heard about this and didn't comment in the thread.

It wouldn't be hard to have an option to prevent processes with different owners from running on the same physical CPU at the same time. It wouldn't even affect the case that Linus mentioned. But cryptographers don't seem to think it's a plausible attack anyway, aside from carefully arranged conditions. The discussion was entirely over whether it would be less foolish to prevent it in the kernel or in userspace, and nobody seems to have argued that anything should be done at all.

How to fix this

[Animats]

OK, we have a covert channel and a way to exploit it. How can that be fixed?

First, remember that public key exchange is usually a very small component of a cryptographic session. Usually, you do all the public key work at startup, exchange private keys for the session, and then just use the private keys. So an inefficient solution that protects the public key computations is acceptable.

In the paper, Percival writes "Further, OpenSSL utilizes a "sliding window" method of modular exponentiation, decomposing x := (a^d) mod p into a series of squarings x := x^2 mod p and multiplications x := x ^ (a*2*k+1) mod p." When there's a zero bit in d, the squaring and multiplication are unnecessary, and the SSL implementation apparently skips them. That creates the covert channel. It should be sufficient to revise the code so that it always does the squaring and the multiplication, and then uses the zero bit in D to decide whether or not to use the result. Because some superscalar CPUs might manage to look ahead and avoid the squaring and computation, a nice solution would be to compute both x := (a^d) mod p and x := (a^(d XOR K) mod p, where K is all binary ones out to the maximum length of d. This makes the computation symmetrical, independent of the value of d. This should roughly double the cost of the public key computation, which is probably tolerable.

It's now important to also examine private key mechanisms for similar vulnerabilities. In particular, DES implementations should be checked. Because those execute millions of times during a long data transfer, even if there's a low-bandwidth leak, an exploit may be possible. Some lookup-table based implementations of DES might have exploitable cache semantics, and that needs to be explored.

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.

Re:Bzzt! Back the paradigm up here.

[Paradox]

Yes, you are correct, if you are still writing the software, and you notice the security and correctness are being compromised.

In my experience, correctness is caught here, but security tends to slip through the cracks. It can be very hard to unit test for security (although, a well tested system tends to have fewer buffer overflows and whatnot).

If you're doing final testing (say, 3 weeks before gold cd goes out), or if you've already sent the software out, you can't just rush out a fix, especially without seriously sitting down and thinking things through.

Two problems. First, when you find the bug is irrelevant. It's the bug's value that matters. If your secure server is shipping tomorrow and you find a show-stopper buffer-overflow, you fix it. If that delays your ship date for a day or two, such is the price of developing software. Use a process that helps minimize the cost of change (I know I have a favorite). If you don't, you're asking for trouble.

Part of these kinds of priorities is that you need to weigh the cost benefit of each change. You are suggesting that the size of the change has some kind of weight in this equation. My claim is that it does not. The customer doesn't care about how many lines you have to change, they care about if your software is safe, correct, secure and fast.

Using pithy excuses like, "I know it doesn't do what we said it would, but we only caught the bug 3 weeks before shipping," is an excellent way to show your customer how incompetant you are at software engineering and project management.

Far better to take the honest route, give them what they paid for, and not ship a bogus version. Unless, of course, your customer decides otherwise.

That's pretty much what I've been saying. Linus is doing the correct thing and Colin Percival is being too hasty with things.

That's not what you said, and it's not what Linus is saying. Linus is saying, "It's not a problem. The bug is too hard to exploit, and I like hyperthreading." Maybe you've confused him with Alan Cox, who is saying that you can't ignore security bugs of this class, even if they're in hardware, and so he suggests that hyperthreading be turned off.

Hmmm. To the darkside?

[korekrash]

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.

So, the troops begin to turn.....Soon it will be:

Emporer Gates
Darth Linus
Steve Jabba

Who will we have to ridicule for being successful when we can no longer rally around Linus as our champion against the Empire?

Re:probably easy to fix

[iggymanz]

Hello Colin! How many of the world's servers really have local users that aren't already trusted with potential to access the business data? And for that matter, what percentage already have *physical* access to the machine? How many easier and more convenient ways do they have to snoop/steal/alter information than the hyperthread exploit? Heck, I'm an honest person and I can think of dozens of ways, I wonder what a creative sysadmin or dba turned evil person could conceive? As a general principle, potentially hostile users should NEVER be given local access to a server with information needing security, it's that simple. And failing to keep external users from getting local privileges will open the door to all manner of data snooping/destruction/theft whether or not a hyperthreaded processor is involved.