Hacker News Reader

Comment by tlb | Hacker News Reader

If you assume the CPU is compromised, then mixing in RdRand among other entropy sources is still not safe. For instance, the RdRand instruction could set a flag that, with some small probability, zeros out anything XORed with it so you occasionally get zeros in the entropy pool. Or some other known-to-the-bad-guys value.

View on HN

If the CPU is compromised then you've already lost.

Sure, but the CPU has to perform correctly on general-purpose computations so it's not too likely that, for example, the multiplication instructions occasionally give wrong results. Detecting cryptographic code executing in the CPU and subverting it is hard in general, but quite easy if you have a special instruction used only for the purpose.

You've overshot, though. The solution to what you're describing isn't to remove RdRand from the Linux kernel, it's to entirely give up. This is not a defense of the change.org request.

There are multiple special-purpose security instructions; AESENC, for instance, or even PCLMULQDQ, which was added to speed up GCM. Which ones should we keep and which ones should we jettison?

Since AESENC and PCLMULQDQ are meant to be deterministic - including their timing - it's rather harder for Intel to subvert them in a way that's not detectable than something like RDRAND.

If the CPU is compromised then we should try to find out about it.

We might not all be cryptography experts like Linus is implying he is, but he saying there's no way the CPU could be compromised and use the backdoor against Linux? If not, then he should invite more scrutiny, not less.

From what I understand it would be very hard to even know if the CPU is compromised, so why is he so absolutist about it then, if it's impossible for him to prove with absolute 100 percent certainty that it's false?

As the post at the top says: trust no one.

> If the CPU is compromised then we should try to find out about it.

This is a copy-paste of my comment from an older thread [0]:

http://www.xakep.ru/post/58104/ (use Google Translate)

TL;DR

The author has found an undeclared software module (backdoor?) working as a hyper-visor in the System Management Block chip on the South Bridge working with Intel CPU with VT virtualization technology.

[0] - https://news.ycombinator.com/item?id=4462782

Buy CPUs from two (or n) different vendors and run a user space lockstep execution virtual machine between them. Unless all vendors are compromised in exactly the same way, the output will fail to verify.

Of course, this would prevent you from using RdRand as your VM implementation will only be able to call on deterministic instructions...

"with some small probability, zeros out anything XORed with it"

You really don't know what you're talking about. Really

Write the code for this then, go ahead, and show how it would work (hint: it doesn't)

And as others said, if your CPU is compromised you already lost.

Your dismissive tone is rude and uncalled for. There's nothing fundamentally impossible about the method tlb is suggesting. It would actually be quite a clever hack.

It can't be done. Between the RdRand instruction and the next XOR nothing guarantees that:

1 - The task won't be preempted

2 - That XOR will be used for entropy calculation

And even if n. 1 doesn't happen, n. 2 is very hard to guarantee (and easy to avoid)

Of course I'm dismissive because it's obvious to me it can't work like that. But please let's continue discussing impossible theories and barking at wrong trees.

There are easier and more effective attacks than that.

It doesn't have to work every time, just occasionally (1 in 1,000,000) is enough to introduce an exploitable weakness. So task preemption isn't a problem.

XOR is used for entropy calculation in the Linux kernel, as Dale Emmons points out in the article.

> So task preemption isn't a problem

Yeah, you're just crashing a different task

> XOR is used for entropy calculation in the Linux kernel

You sound like you don't know C, less alone have any knowledge of assembly language. That phrase is correct but absolutely useless.

Do you know how that code snipped is translated to assembly? On x86? On x64? With optimisations? Without? How different OSs would use RdRand?

More to the point, a change like this is very likely to be _noticed_. Both in terms of the complexity that would be required to make such a change in the microcode, and if the logic screws up and tampers with the wrong XOR, it will cause a bug that people will search for and eventually discover that the CPU was screwing up XOR under some circumstances. Remember the firestorm over the FDIV bug?

That's not something that you can address with software, by definition.

Maybe there are less obvious things they can do (I'm not an expert), but isn't this what testing software like dieharder is designed to detect? I assume people are testing /dev/(u)random often.

I believe you are extrapolating the threat model past anything reasonable.

The original concern around RdRand is that the tiny on-chip random number generator might be compromised.

You are arguing that there might be implementation that uses code analysis to detect data flow from RdRand and mess with it. It sounds very far fetched.

Reply on news.ycombinator.com