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

OpenBSD disables Intel's hyperthreading due to security concerns

mail-archive.com

Post reply on HN
Print view View original

41–50 of 158 posts

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#41

Post by __jal »

keldaris wrote: post #19

So... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations and improving their scheduler is hard, so they'll pre-emptively disable HT outright on Intel CPUs now and others in the near future? I'm not an OpenBSD user (and glad for it, if this is anything to go by), but I'm curious - is this really how they operate, or does this decision stand…

You may well not be in the target market (if your comment is anything to go by) but yes, their entire appeal rests on being very conservative with security decisions.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#42

Post by stormbrew »

classichasclass wrote: post #6
jimrandomh wrote: post #4

> We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial. This suggests a long-term compromise solution where threads within a process can use hyperthreading to share a core, but threads in different processes can't. Given that hyperthreads share L1 cache, this might also be better for perf…

I'm not sure that would necessarily fix the problem definitively. Say you had a browser running web-exposed JavaScript on a thread. You could still finagle a Spectre-type information leak that way by having the JavaScript thread snoop other browser threads, assuming no other mitigations.

In theory marking threads even within the same process as part of a different 'security domain' shouldn't be impossible, though obviously it'd involve proprietary interfaces to the kernel at first.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#44

Post by notaplumber »

mehrdadn wrote: post #40
notaplumber wrote: post #33

Earlier quoted context omitted.

Operating systems can't disable HT/SMT in the same way as the BIOS/firmware can, but presumably it will be fine if the kernel only schedules the idle process on HT "cores", it will spend much of, or all its time in a lower power state (MWAIT? C-states?), presumably the CPU is smart enough to handle that.

I guess figuring out whether it's only "presumably" or actually "actually" was why I asked the question in the first place.

Hmm. This thread on the OpenBSD lists suggests it may be adequate, of course disabling in the BIOS is certainly a better option, if you can.

https://marc.info/?t=152938773300027&r=1&w=2

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#45

Post by blattimwind »

CHY872 wrote: post #34
amelius wrote: post #24

Earlier quoted context omitted.

> The reason is that two threads of the same program will often end up executing similar instruction streams Why is that bad?

Your processor has a certain number of execution units which can actually execute individual instructions, maybe like 4 floating point units, maybe 8 arithmetic ones, and maybe 1 that can do vector processing (these numbers are not real, but are like, good enough for sake of message). So the idea with SMT is that most of the time, lots of the execution units are unused because the thread a) isn't using them at all (e…

The contention would actually not be on a per-EU level, but one level higher up. The reservation station has a bunch (~5-8) of ports and typically multiple EUs are connected to one port. Can't use one port for two different things at the same time.

Here's a simplified block diagram of a Skylake core: https://en.wikichip.org/wiki/intel/microarchitectures/skylak...

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#46

Post by Scramblejams »

I've never trusted hyperthreading for workloads I haven't tested. Sometimes it's faster, often it's slower. Beyond that, I've been suspicious of its security implications from day one. My first trip through the BIOS on a personal machine always includes turning it off.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#47

Post by blattimwind »

mehrdadn wrote: post #21

Do you get the exact same performance characteristics by ignoring the extra virtual cores as you would have gotten if you could actually disable hyperthreading in the CPU via the firmware setup? Or does it result in some CPU resources becoming unusable that would otherwise be usable if HT were truly disabled?

At least in previous generations some resources where statically shared, but most were dynamically shared.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#48

Post by ams6110 »

timvisee wrote: post #36
valarauca1 wrote: post #9

Earlier quoted context omitted.

Firefox process per tab is behind a feature flag as it’s in testing still

I don't think the plan is to ever enable this in the comming few years. The current approach with a few tabs is much more memory efficient, which is why they've chosen it.

Indeed. I cannot open Google Drive in chrome on my OpenBSD box without crashing the tab from exhausting memory, but Firefox handles it no problem.

Re: OpenBSD disables Intel's hyperthreading due to security concerns

#49

Post by CHY872 »

blattimwind wrote: post #45
CHY872 wrote: post #34

Earlier quoted context omitted.

Your processor has a certain number of execution units which can actually execute individual instructions, maybe like 4 floating point units, maybe 8 arithmetic ones, and maybe 1 that can do vector processing (these numbers are not real, but are like, good enough for sake of message). So the idea with SMT is that most of the time, lots of the execution units are unused because the thread a) isn't using them at all (e…

The contention would actually not be on a per-EU level, but one level higher up. The reservation station has a bunch (~5-8) of ports and typically multiple EUs are connected to one port. Can't use one port for two different things at the same time. Here's a simplified block diagram of a Skylake core: https://en.wikichip.org/wiki/intel/microarchitectures/skylak...

Thanks! Yeah figured I'd be wrong somewhere in there!
Post reply on HN