Live data from Hacker News

Disable SMT/Hyperthreading in all Intel BIOSes

marc.info

131–140 of 159 posts

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#132
post #87

Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors? Edit: https://www.amd.com/en/corporate/security-updates > 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also k…

With the newer AMD processors having as many real cores as they do, does the cost-benefit analysis of HT/SMT change? I read in a comment here a few weeks ago that turning it off on the newer AMD CPUs can yield better performance because of improved cache-coherency on some workloads (My memory of what I read might be totally wrong).

some of the heavily multithreaded applications I use at work see up to a ~27% loss in performance by disabling SMT, others don't see much of a loss at all (on AMD EPYC)

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#133

Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors? Edit: https://www.amd.com/en/corporate/security-updates > 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also k…

They've been unsusceptible to some of the more recent side-channel attacks, but others have affected everything from Intel to AMD to ARM. I haven't really ready anything on this most recent set of vulnerabilities and AMD.

There is a lot of false equivalence going on about the vulnerability of Intel vs everyone else.

Yes spectre type issues effect many ranges of processor (including AMD), however everything shown to date indicates that its very difficult to exploit.

There are a large number of Intel only issues like meltdown and the L1 cache attack that are much more severe, and much easier to exploit.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#134
post #62

Earlier quoted context omitted.

Intel cooperates with organizations that obey embargoes and don't badmouth their partners in public, like Red Hat, Canonical, and probably the Linux Foundation. Intel does not cooperate with OpenBSD.

OpenBSD has never disobeyed an embargo. Argued for them to be reduced, criticized them, but not disobeyed them.

i'm pretty sure this is not true: The most recent example i remember is: https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh...

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#135
post #88
post #62

Earlier quoted context omitted.

Intel cooperates with organizations that obey embargoes and don't badmouth their partners in public, like Red Hat, Canonical, and probably the Linux Foundation. Intel does not cooperate with OpenBSD.

I think what you're insinuating is a side effect of the OpenBSD group being open, honest, and congruent to their ethics.

What he's insinuating is that they agreed to embargos and then repeatedly broke them, claiming it was "better for users".

Regardless of whether it is, you should expect the result of that to be that nobody trusts them with embargoes.

Which is in fact, what has happened.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#136
post #122

We have disabled Hyper Threading(HT) on all public facing servers(running OpenBSD). However, our compute nodes running Linux kernel are benefiting about 80 to near 100% boost for specific scientific workloads. So, we run our INTERNAL NETWORK ONLY compute nodes with HT on. In places where security is not primary concern, why not make use of HT for extra efficiency? Think and plan before you blanket disable HT on all s…

Agree. A personal computer could probably even risk it as long as they don't run untrusted javascript (which they shouldn't do anyways, or only under sandboxed/careful conditions).

Very few people don't run untrusted Javascript these days.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#137

Earlier quoted context omitted.

I asked this a while ago: a cloud core is always just a hyperthread.

You mean it's random then, right? I mean let's talk about what a hyperthread really is: It's the left over functional units (or execution units). Say you have 100 adders, the processor tries to schedule as many instructions as it can on those 100 adders, but eventually it will run into data dependencies. The left over units can go to a hyperthread. My understanding (let me know if I'm wrong) is that Hyperthread aware…

No need to down vote him people. He is polite and on topic. Not completely correct, but none of us is all the time.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#138

Earlier quoted context omitted.

OpenBSD has never disobeyed an embargo. Argued for them to be reduced, criticized them, but not disobeyed them.

i'm pretty sure this is not true: The most recent example i remember is: https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh...

This is common misinformation. Even in this case, OpenBSD did not break the embargo. After protesting, they received the permission of the researcher to publish:

  Note that I wrote and included a suggested diff for OpenBSD already, and that
  at the time the tentative disclosure deadline was around the end of August. As
  a compromise, I allowed them to silently patch the vulnerability.
(https://www.krackattacks.com/#openbsd)

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#139

Earlier quoted context omitted.

Possibly, but it's not uncommon to refer to x86 and x64 machines as intel architecture machines or as intel machines.

Due to architectural differences, AMD CPUs are immune or nearly immune to some of the speculative execution attacks (though not all of them). For example, AMDs branch predictor uses the full address and so is not vulnerable to branch predictor poisoning in the same way as Intel. The major win (whether AMD intended it or not) is that AMD cpus don't speculate loads until page permissions have been verified. Intel fires…

Thanks for the clarification!
Post reply on HN