Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disable SMT/Hyperthreading in all Intel BIOSes

marc.info

Post reply on HN
Print view View original

51–60 of 159 posts

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#51

Post by wmf »

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…

That's like the Cell processor. For every year that you program for Cell you need at least two years of therapy.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#52

Post by xyzzyz »

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.

You understand it wrong, even though you’re somewhat correct as to what scheduler actually does. In a single physical core, both logical processors are equivalent, and neither one has higher internal priority over the other. The hyper threading aware scheduler will take extra care in scheduling in this scenario, but not in a sense you describe — if you have 2 physical cores, and thus 4 logical processors, and 2 CPU intensive tasks, the scheduler might attempt to schedule them on different physical cores, instead of stuffing them on the two logical processors of a single physical core. It’s not because one logical core is better than the other, but rather it’s because the two tasks would simply compete with each other in a way they wouldn’t if they were on physically separate cores.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#53

Post by gruez »

Aardwolf wrote: post #7
Roritharr wrote: post #2

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

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

>Is it a feasible solution to enable hyperthreading only for threads or forks of the same process?

how does that work on unix systems when processes are all forked from 1 process? even if you get past that issue, how do you prevent less privileged processes that use other security mechanisms (cgroups, pledge, selinux, croot, sandboxing)?

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#54

Post by Roritharr »

gruez wrote: post #49
Roritharr wrote: post #32

Earlier quoted context omitted.

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 the only real solution is to turn off HT/SMT that, seen positively, should net us a lot faster VMs then... you also doubled the cost of each VM (in terms of cpu), but you didn't double the performance of each VM, so it's a net negative.

It might be Intel in the end having to pay that cost...

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#55

Post by wmf »

geofft wrote: post #33

> 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…

Foreshadow is caused by the L1 cache which is not shared across cores. It may be only a matter of time before L3 attacks are discovered but I don't know of any today.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#56

Post by wiz21c »

FTA

>>> We are having to do research by reading other operating systems.

Si Intel cooperates with business partners like apple/windows and not with open source. Does it mean that Apple and Windows can claim to be more secure because they have access to the information needed to fix Intel's issues ?

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#58

Post by 2trill2spill »

wiz21c wrote: post #56

FTA >>> We are having to do research by reading other operating systems. Si Intel cooperates with business partners like apple/windows and not with open source. Does it mean that Apple and Windows can claim to be more secure because they have access to the information needed to fix Intel's issues ?

> Does it mean that Apple and Windows can claim to be more secure because they have access to the information needed to fix Intel's issues ?

They can claim it, but I would trust a Linux or FreeBSD box over MacOS or Windows anytime even if they get some security info before the open source operating systems.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#59

Post by derefr »

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…

Other things require sandboxed multitenancy than just full-on VMs. Database queries against a "scale-free" database like BigQuery/Dynamo, for example, where two queries from different tenants might actually be touching the same data, with much the same operations, and therefore you'd (naively) want to schedule them onto the same CPU for cache-locality benefits.

Re: Disable SMT/Hyperthreading in all Intel BIOSes

#60

Post by swixmix »

[ marc.info not responding for me, found post linked elsewhere. Edited due to markdown.

URL: http://openbsd-archive.7691.n7.nabble.com/Disable-SMT-Hypert...

Here it is: ]

---

Title: Disable SMT/Hyperthreading in all Intel BIOSes

Posted by Theo de Raadt-2 on Aug 23, 2018; 11:35am

Two recently disclosed hardware bugs affected Intel cpus:

- TLBleed

- T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this bug, more aspects are surely on the way)

Solving these bugs requires new cpu microcode, a coding workaround, AND the disabling of SMT / Hyperthreading.

SMT is fundamentally broken because it shares resources between the two cpu instances and those shared resources lack security differentiators. Some of these side channel attacks aren't trivial, but we can expect most of them to eventually work and leak kernel or cross-VM memory in common usage circumstances, even such as javascript directly in a browser.

There will be more hardware bugs and artifacts disclosed. Due to the way SMT interacts with speculative execution on Intel cpus, I expect SMT to exacerbate most of the future problems.

A few months back, I urged people to disable hyperthreading on all Intel cpus. I need to repeat that:

DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS.

Also, update your BIOS firmware, if you can.

OpenBSD -current (and therefore 6.4) will not use hyperthreading if it is enabled, and will update the cpu microcode if possible.

But what about 6.2 and 6.3?

The situation is very complex, continually evolving, and is taking too much manpower away from other tasks. Furthermore, Intel isn't telling us what is coming next, and are doing a terrible job by not publically documenting what operating systems must do to resolve the problems. We are having to do research by reading other operating systems. There is no time left to backport the changes -- we will not be issuing a complete set of errata and syspatches against 6.2 and 6.3 because it is turning into a distraction.

Rather than working on every required patch for 6.2/6.3, we will re-focus manpower and make sure 6.4 contains the best solutions possible.

So please try take responsibility for your own machines: Disable SMT in the BIOS menu, and upgrade your BIOS if you can.

I'm going to spend my money at a more trustworthy vendor in the future.

Post reply on HN