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.

What exactly is the connection between hyperthreading and safety?

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.

Pretty much nobody in the HPC sphere really uses hyperthreading, it's disabled in the BIOS on pretty much every HPC cluster I've ever used.

I don’t know why this insane rule of thumb still exists in the HPC world. True that some compute bound jobs that are not designed to make use of HT will be hurt by running in an HT environment. But, not all of HPC work is such purely compute bound. For a scientific field, it is ironic that someone perpetrates this blind rule. Do an A/B test with and without HT for your workload in hand and decide based on results…..

As an example, in our test suite, we found that we get almost a 80% boost by turning on HT.

The right rule is “HT may help or hurt your performance depending on workload. Test and decide”.

Well, it's not such a bad idea for most cluster admins (me being one at a large UK University). Most of our compute time comes from a small number of very popular MPI parallelised applications, all of which suffer from worse (or at best equivalent) performance with hyperthreading.

Why is this a A/B test and not a regular test?

Point is you can use it without worrying about security.

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.

OpenBSD did, not FreeBSD

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

Doesn’t AMD also provide hyper-threading of sorts?

My Ryzen has 6 cores and 12 threads. Isn’t that pretty much the same?

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.

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#Simu...

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.

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.

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

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

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.

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.