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

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#31

Post by opencl » 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…

Car manufactures do exactly that all the time though. Things like auto emergency braking and side airbags are still options that you can pay extra for. Airbags, anti lock brakes, backup cameras, etc. were all available as optional upgrades for decades before they got mandated.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#32

Post by Roritharr » Thu, Aug 23, 2018, 7:48 PM UTC

geofft wrote: post #22

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…

The latter question is very important indeed. If you for instance render websites in your vm they, if i understand correctly, can potentially read secrets from other processes, like db credentials and other stuff...

If the only real solution is to turn off HT/SMT that, seen positively, should net us a lot faster VMs then...

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#33

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

> SMT is fundamentally broken because it shares resources between the two cpu instances and those shared resources lack security differentiators.

I thought the root of one of the Foreshadow problems was that caches are shared across cores, and therefore even with hyperthreading disabled, you still gain information about a process on another core. Am I misinterpreting it?

It does seem like the paranoid thing to do is that each socket gets to be used by only a single user. (I half-jokingly suggested at work that we replace our internal cloud with a Beowulf cluster of Raspberry Pis...)

It also seems like you could design OSes in a way which is more robust to this, e.g., certain cores are only for the kernel and processes running as root, and system calls are inter-processor interrupts, so privileged kernel (or userspace root) data doesn't go into untrusted caches at all.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#34

Post by kevin_thibedeau » Thu, Aug 23, 2018, 7:48 PM UTC

It's not clear that he's using "SMT" to refer to AMD specifically as he goes on to talk about "Intel CPUs" and disabling it in "Intel BIOS". Does the Zen architecture have the same issue?

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#35

Post by [deleted] » Thu, Aug 23, 2018, 7:49 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…

[deleted]

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#36

Post by wmf » Thu, Aug 23, 2018, 7:49 PM UTC

Roritharr wrote: post #9

Aardwolf wrote: post #7

Earlier quoted context omitted.

Is it a feasible solution to enable hyperthreading only for threads or forks of the same process? Then they can use this ability, but other processes cannot do timing attacks on this process in this core... I think

I'm guessing someone at Amazon is looking at this right now.

I think EC2 has isolated cores (except t1/t2/t3) all along.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#37

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

Roritharr wrote: post #32

geofft wrote: post #22

Earlier quoted context omitted.

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…

The latter question is very important indeed. If you for instance render websites in your vm they, if i understand correctly, can potentially read secrets from other processes, like db credentials and other stuff... If the only real solution is to turn off HT/SMT that, seen positively, should net us a lot faster VMs then...

If you render websites that run code in your VM (e.g., you're running a traditional shared hosting infrastructure where mutually-untrusted users can upload PHP scripts, or you're doing something serverless / FaaS / Cloudflare Workers / etc. where mutually-untrusted users can upload functions), then yes. If you're rendering websites in the sense of hosting WordPress for lots of people but not permitting custom plugins, then no.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#38

Post by fyfy18 » Thu, Aug 23, 2018, 7:51 PM UTC

Will be interesting to see what Apple does about this in their next software update. I can’t imagine many people will be happy if the next software update forcibly disables hyper threading.

(For those who aren’t familiar with Apple devices, Apple don’t expose settings like this to a user, which are usually available in the BIOS on a PC)

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#39

Post by gaius » Thu, Aug 23, 2018, 7:51 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…

My understanding (let me know if I'm wrong) is that Hyperthread aware OSes (which is like what, everything since WinXP/Linux kernel 2.4?) will schedule lower priority tasks to the logical cores and higher priority tasks to the real cores

That is not how I understand it. The OS sees two identical logical cores per physical core and the CPU manages which is which internally. Also it's not really high and low priority - it's two queues multiplexing between the available execution units. If one queue is using the FPU then the other is free to execute integer instructions, but a thousand cycles later they might have switched places. Or if one queue stalls while fetching from main memory, the other gets exclusive use of the execution units until it gets unstuck.

In my floating-point heavy tests on i7 however, there is still a small advantage in leaving HT on, the common wisdom is if you are doing FP, HT is pointless and may actually harm performance, but that doesn't match my observations if your working set doesn't fit into L2 cache. YMMV.

A semi-modern OS will try to keep a process on the same physical core if it can, so it may be flipflopping between two logicals, but should still see the same cache. Disabling HT means the OS still sees logical cores, but half as many of them, with a 1:1 correspondence between logicals and physicals.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#40

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

ofrzeta wrote: post #11

Roritharr wrote: post #6

Earlier quoted context omitted.

Thinking about this, they're probably gonna introduce "insecure but cheap" instances for customers that don't mind the chance of data leaks and takeovers...

That would be hard to market.

You could run the entire free tier there and disable it for paying customers - I'm sure there's a significant fraction of Amazon and Google's clouds, at least, that are on the free tier, and saving money on those would help everyone (they'd let people who aren't yet at a significant enough scale to care about security play around with things for free, and they'd let the cloud providers pack them very tightly).