Disable SMT/Hyperthreading in all Intel BIOSes • Hacker News Board

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#21

Post by djsumdog » Thu, Aug 23, 2018, 7:41 PM UTC

walterbell wrote: post #14

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.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#22

Post by geofft » Thu, Aug 23, 2018, 7:42 PM UTC

Roritharr wrote: post #2

Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.

You can give both hyperthreads in a physical core to the same tenant, no?

Scheduling different VMs to run on the same hyperthreaded core at once seems like it can't be good for either VM's performance, even if there were no security concerns. Hyperthreading is much more useful for running multiple threads of the same app, accessing similar instruction caches etc.

(There's also a question of safety within the VM, but a huge number of cloud users are running effectively one user within their VM.)

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#23

Post by gameswithgo » Thu, Aug 23, 2018, 7:42 PM UTC

walterbell wrote: post #14

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…

maybe. no guarantee AMD won't have the same issue.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#24

Post by crunchlibrarian » Thu, Aug 23, 2018, 7:42 PM UTC

Roritharr wrote: post #2

Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.

Hyperthreading is fine on its own, but yes in combination with other CPU features it is effectively impossible to secure.

Turn it off or sell your Intel chips.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#25

Post by seiferteric » Thu, Aug 23, 2018, 7:42 PM UTC

Maybe this is what finally gets me to upgrade from my ~2012 i7-3770. Not because of performance improvements, but to avoid performance degradation from all these security patches...

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#26

Post by lomnakkus » Thu, Aug 23, 2018, 7:44 PM UTC

Roritharr wrote: post #20

morsma wrote: post #15

Earlier quoted context omitted.

Yes!

Where did you get that impression?

I believe it may be because the email only mentioned Intel explicitly and had a "I won't be buying Intel in future" (paraphrased) comment. However, I personally wouldn't assume that AMDs HT implementation doesn't have similar issues.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#27

Post by rosser » Thu, Aug 23, 2018, 7:45 PM UTC

djsumdog wrote: post #18

Roritharr wrote: post #8

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…

From my understanding, you can't (necessarily) even rely on your guest's CPUs mapping to the host's actual CPUs, which makes spending time twiddling NUMA actively useless. Assuming that's actually the case, I very much doubt the guest's scheduler has the ability to schedule tasks between logical and physical cores, based on priority.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#28

Post by jakeinspace » Thu, Aug 23, 2018, 7:46 PM UTC

stcredzero wrote: post #12

I've long felt that there's something less than half-baked about the multi CPU architecture we're currently using. The hacky contortions HFT coders have come up with to avoid things like False Sharing strike me as a big red flag. https://mechanical-sympathy.blogspot.com/2011/07/false-shari... How about an architecture more like Erlang's, where you have independent processes with their own CPU core, where each has the…

No networking can touch silicon-level interconnect between cores or within cores on a single chip, at least for latency. Erlang's model of computation doesn't have much to say about physical implementation, and multi-socket/distributed systems are not perfomant for latency-critical user applications. For servers and high performance computing sure, I guess in theory we could use tons of simple single-core chips, but fabrication costs and energy efficiency would be significantly worsened.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#29

Post by ISL » Thu, Aug 23, 2018, 7:47 PM UTC

fermienrico wrote: post #17

ofrzeta wrote: post #11

Earlier quoted context omitted.

That would be hard to market.

Indeed, the idea of "Security" is not negotiable when marketing. Imagine buying a car that says, "Save $5000 for a less safe version without airbags." Yes, I know Airbags are DOT requirement, just trying to make a point. Edit: I think people are missing my point. I am not saying they don't sell cheaper models that are less safe. My point is that they don't ACTIVELY market them as such. Point me to an advertisement th…

There are absolutely situations in which a substantially cheaper but less-secure/safe solution to a problem can make economic sense.

Suppose you have $5k, you need a car in order to feed your family, and that only the following two options are available: You can buy the safe car for $10k or a less safe car for $5k.

In that situation, less safety can be a reasonable choice.

Indeed, there was a long period of time in which Volvos were demonstrably more safe than other lower-cost vehicles, yet people bought the lower-cost vehicles.

In the cloud-offering world, instead of marketing servers as "less-secure", they can simply offer "more-secure" options that run on non-HT hardware. HIPAA-compliant cloud-buyers will have to upgrade, and then the cloud vendors can slowly lower the prices on both, making the less-secure option lower cost than the present day.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#30

Post by dumbfounder » Thu, Aug 23, 2018, 7:47 PM UTC

fermienrico wrote: post #17

ofrzeta wrote: post #11

Earlier quoted context omitted.

That would be hard to market.

Indeed, the idea of "Security" is not negotiable when marketing. Imagine buying a car that says, "Save $5000 for a less safe version without airbags." Yes, I know Airbags are DOT requirement, just trying to make a point. Edit: I think people are missing my point. I am not saying they don't sell cheaper models that are less safe. My point is that they don't ACTIVELY market them as such. Point me to an advertisement th…

Yeah but they just wouldn't market it that way. It's easy enough to spin. You have the regular version, then you have the "enhanced security" version.