3 ms·

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

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.

raverbashing 13y ago
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.
- tlb 13y ago
  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.
  - raverbashing 13y ago
    > 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?
- tytso 13y ago
  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?

3 ms·

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

by reitzensteinm 13y ago

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.

raverbashing 13y ago
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.
- tlb 13y ago
  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.
  - raverbashing 13y ago
    > 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?
- tytso 13y ago
  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?