4 ms·

And, in my opinion, its only going to get worse if Intel doesnt sober up and address the elephant in the room: Hyperthreading. Without serious reform to the d

And, in my opinion, its only going to get worse if Intel doesnt sober up and address the elephant in the room: Hyperthreading. Without serious reform to the design of the Intel X86 chip to eliminate and refactor what basically amounts to a performance-before-safety feature, Intel is going to see the lions share of performance hits. Eventually people will tire of writing backflip code to sidestep pitfalls in the Intel HT design and simply return the responsibility to Intel, where its existed since day one. It could be argued Intels mouthpiece has already lost its ability to convince major datacenter and cloud customers that HT is even remotely safe as a continued investment. Intel needs a new X86.

josteink 5y ago
Doesn’t AMD also provide hyper-threading of sorts? My Ryzen has 6 cores and 12 threads. Isn’t that pretty much the same?
- altusbrown 5y ago
  Something about the AMD implementation is notably harder to exploit, though last I looked it wasn't clear what that was. It's held up much better, and a lot of people have looked at it. Still exploits, but almost impossible to do in the field last I checked, where Intel has been demonstrated on live systems handling production load.
  - to11mtm 5y ago
    It's difficult to say why AMD's implementation has held up better. One interesting thing I noted looking at wikichip's info [0] was that Zen calls out that Cache is tagged by thread. I wonder whether Intel's HT did/does the same or not. [0] https://en.wikichip.org/wiki/amd/microarchitectures/zen#Simultaneous_MultiThreading_.28SMT.29 https://en.wikichip.org/wiki/amd/microarchitectures/zen#Simu...
- rwaksmunski 5y ago
  I heard somewhere that AMD speculated a bit less and cleaned up a little after a miss, which made exploitation a lot more difficult. I'm sorry I don't recall the source, might have been an interview with one of AMD's engineers.
  - schlupa 5y ago
    The fundamental difference is that AMD respects exclusion domains even when speculating a thing intel is notorious for not doing. It's a fundamental difference. Intel: speculate without checking rights and crush afterward if a violation happened. Gains some points in benchmarks but makes side channel exploits very interesting. AMD: speculate only on allow if allowed. No need to crush afterward, no speculation violate security. Costs some points in benchmarks but make side channel exploits not very interesting.
- sundvor 5y ago
  It's simply SMT or Simultaneous multithreading on AMD. Hyperthreading was Intel's branding of SMT, if I understand this correctly. Mine has 12 and 24. :)
- sundvor 5y ago
  It's simply SMT or Simultaneous multithreading on AMD. Hyper-Threading was Intel's branding of SMT, if I understand this correctly. My Ryzen has 12 and 24. Simply amazing what they did. :)
  - sundvor 5y ago
    Apologies for the dupe; this was the most recent version, I thought I hit edit to correct the capitalisation of HT, but I obviously didn't.
tomerv 5y ago
What exactly is the connection between hyperthreading and safety?
- bayindirh 5y ago
  HT enables some side-channel attacks due to its architecture of "let's allow two threads to share the same pipeline and use the unused parts to allow more work to go through". In practice this allows some attacks to attach themselves to the same pipeline with the target process and nibble required information slowly, but surely. IIRC FreeBSD disabled HT out of the box at the kernel level for this reason. I'm tired and it's late here. I may worded some stuff wrong or plainly misremembered it. Please feel free to correct.
  - IntelMiner 5y ago
    OpenBSD did, not FreeBSD
  - vermaden 5y ago
    FreeBSD did not disabled it by default but you can disable it with this: % sysctl -d machdep.hyperthreading_allowed machdep.hyperthreading_allowed: Use Intel HTT logical CPUs
- mhh__ 5y ago
  Modern CPUs have a very large bag of tricks to make the code they execute run fast. These tricks are usually designed for some optimal workload, and (especially x86) the real deal can't actually keep the backend busy. Solution: Duplicate some of the CPU to feed the backend with more stuff to do. This can get you a performance win without the cost of a whole core. All good so far, for (say) HPC where you have people with guns guarding the machines you can turn on all the performance. The issue is that as CPUs have got more complicated, it's increasingly easy to attack the internal state of the processor. This is already possible in a single thread (i.e. the prototypical spectre and meltdown implementations), however imagine what you can do next door to a completely different "core". The processor maintains separation of structure but not of state, so you can use (say) timing side channels to extract information about what your neighbour is up to. FWIW these issues are more of a problem for Cloud vendors than you or I as they usually require pretty specific knowledge of the hardware being attacked and even then are not easy to pull off.
tpxl 5y ago
I disagree. If you the whole machine to yourself (colo/bare metal hosting) the vast majority of workloads you run wont run any untrusted code.
schlupa 5y ago
Epyc also has hyperthreading. Intel's security woes have more to do with a deep corporate philosophy than anything else. Meltdown happened because Intel works with the premise: you can cheat (not respect protection domains) if nobody sees it, AMD respected the protection domains in its implementation even if not visible. I know that my assessment is a bit inflammatory but that is what it is.

josteink 5y ago

Doesn’t AMD also provide hyper-threading of sorts? My Ryzen has 6 cores and 12 threads. Isn’t that pretty much the same?

altusbrown 5y ago
Something about the AMD implementation is notably harder to exploit, though last I looked it wasn't clear what that was. It's held up much better, and a lot of people have looked at it. Still exploits, but almost impossible to do in the field last I checked, where Intel has been demonstrated on live systems handling production load.
- to11mtm 5y ago
  It's difficult to say why AMD's implementation has held up better. One interesting thing I noted looking at wikichip's info [0] was that Zen calls out that Cache is tagged by thread. I wonder whether Intel's HT did/does the same or not. [0] https://en.wikichip.org/wiki/amd/microarchitectures/zen#Simultaneous_MultiThreading_.28SMT.29 https://en.wikichip.org/wiki/amd/microarchitectures/zen#Simu...
rwaksmunski 5y ago
I heard somewhere that AMD speculated a bit less and cleaned up a little after a miss, which made exploitation a lot more difficult. I'm sorry I don't recall the source, might have been an interview with one of AMD's engineers.
- schlupa 5y ago
  The fundamental difference is that AMD respects exclusion domains even when speculating a thing intel is notorious for not doing. It's a fundamental difference. Intel: speculate without checking rights and crush afterward if a violation happened. Gains some points in benchmarks but makes side channel exploits very interesting. AMD: speculate only on allow if allowed. No need to crush afterward, no speculation violate security. Costs some points in benchmarks but make side channel exploits not very interesting.
sundvor 5y ago
It's simply SMT or Simultaneous multithreading on AMD. Hyperthreading was Intel's branding of SMT, if I understand this correctly. Mine has 12 and 24. :)
sundvor 5y ago
It's simply SMT or Simultaneous multithreading on AMD. Hyper-Threading was Intel's branding of SMT, if I understand this correctly. My Ryzen has 12 and 24. Simply amazing what they did. :)
- sundvor 5y ago
  Apologies for the dupe; this was the most recent version, I thought I hit edit to correct the capitalisation of HT, but I obviously didn't.

tomerv 5y ago

What exactly is the connection between hyperthreading and safety?

bayindirh 5y ago
HT enables some side-channel attacks due to its architecture of "let's allow two threads to share the same pipeline and use the unused parts to allow more work to go through". In practice this allows some attacks to attach themselves to the same pipeline with the target process and nibble required information slowly, but surely. IIRC FreeBSD disabled HT out of the box at the kernel level for this reason. I'm tired and it's late here. I may worded some stuff wrong or plainly misremembered it. Please feel free to correct.
- IntelMiner 5y ago
  OpenBSD did, not FreeBSD
- vermaden 5y ago
  FreeBSD did not disabled it by default but you can disable it with this: % sysctl -d machdep.hyperthreading_allowed machdep.hyperthreading_allowed: Use Intel HTT logical CPUs
mhh__ 5y ago
Modern CPUs have a very large bag of tricks to make the code they execute run fast. These tricks are usually designed for some optimal workload, and (especially x86) the real deal can't actually keep the backend busy. Solution: Duplicate some of the CPU to feed the backend with more stuff to do. This can get you a performance win without the cost of a whole core. All good so far, for (say) HPC where you have people with guns guarding the machines you can turn on all the performance. The issue is that as CPUs have got more complicated, it's increasingly easy to attack the internal state of the processor. This is already possible in a single thread (i.e. the prototypical spectre and meltdown implementations), however imagine what you can do next door to a completely different "core". The processor maintains separation of structure but not of state, so you can use (say) timing side channels to extract information about what your neighbour is up to. FWIW these issues are more of a problem for Cloud vendors than you or I as they usually require pretty specific knowledge of the hardware being attacked and even then are not easy to pull off.

tpxl 5y ago

I disagree. If you the whole machine to yourself (colo/bare metal hosting) the vast majority of workloads you run wont run any untrusted code.

schlupa 5y ago

Epyc also has hyperthreading. Intel's security woes have more to do with a deep corporate philosophy than anything else. Meltdown happened because Intel works with the premise: you can cheat (not respect protection domains) if nobody sees it, AMD respected the protection domains in its implementation even if not visible. I know that my assessment is a bit inflammatory but that is what it is.