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

121–130 of 158 posts

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

#121

Post by Dylan16807 »

amelius wrote: post #96
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…

So on a RISC architecture, this would happen even for non-similar programs, because the number of instructions is smaller? Or would they just duplicate the processing units?

The units aren't dedicated to esoteric instructions, you have functions like "small alu", "big alu", "fp adder", "address generator and memory load".

RISC will perform about the same and you can hyperthread one fine.

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

#122

Post by Dylan16807 »

Amezarak wrote: post #73
mtgx wrote: post #54

Earlier quoted context omitted.

And it's a mistake. Just recently I noticed that when Firefox loads multiple tabs of the same wordpress site, it starts hanging not unlike Firefox always used to hang. That's likely because it groups all of those same site pages under one process. I've never experienced that with Chrome. This is why I hope Firefox eventually (ASAP) switches to one process per tab, too. I can handle the browser using an extra GB of RA…

Chrome does not use one process per tab. In fact, it does something very similar to what you say Firefox does. http://dev.chromium.org/developers/design-documents/process-... FWIW I do not have the problem you describe and I don't want Firefox wasting any more of my scarce memory, or for that matter, CPU.

> very similar

Not really. Chrome uses a lot of processes for isolation. Firefox uses about four so it can take advantage of multiple cores.

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

#123

Post by Uberphallus »

AHTERIX5000 wrote: post #114
Forbo wrote: post #14

Earlier quoted context omitted.

From the commit message, it sounds like that might not necessarily be the case: "Note that SMT doesn't necessarily have a posive effect on performance; it highly depends on the workload. In all likelyhood it will actually slow down most workloads if you have a CPU with more than two cores."

Wonder why, because of poor SMP scalability and coarse locking? I've encountered some cases where SMT made performance worse such as with very optimized HPC libs but in general SMT can really help. Compiling projects got a nice boost when enabling HT on Intel's recent arch for example (all of this on Linux though, last time I checked OpenBSD its SMP perf was abysmal)

For I/O and memory bound processes, it makes it worse, saturating further buses that are already saturated. For regular. For CPU bound, it may help or not, depending on many factors, like cache/memory contention, nature of the operations...

Compilation can get boosts because while some threads are waiting for I/O others are crunching source files. Also the variety of computation is high enough so multiple threads don't overlap too much on functional unit usage. If you try to build from a filesystem in memory, you'll find way a less impressive speedup (if any).

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

#124

Post by paulirwin »

yk wrote: post #78
adrianratnapala wrote: post #67

Earlier quoted context omitted.

> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?

With most software, well most software is pretty inefficent and profits from HT. However there are a lot of reasons for that, writing in something interpreted because it is faster to develop and the software does not need to be very efficient in the first place would be one application. (Not to say that all Python/JS/etc is inefficient, just that software that needs to be efficient is precisely the kind were one woul…

FWIW, you mention databases, but even some database workloads can have better performance with HT turned off. I first learned this from a DBA at a former job when I was curious as to why they turned HT off. A member of the SQL Server team back in 2005 ran some experiments and found that you can get a 10% performance improvement in some workloads with HT off [1]. I don't know how much of that is still true today, however, as nearly all of my recent experience is PaaS in the cloud.

[1]: https://blogs.msdn.microsoft.com/slavao/2005/11/12/be-aware-...

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

#125

Post by AHTERIX5000 »

Uberphallus wrote: post #123
AHTERIX5000 wrote: post #114

Earlier quoted context omitted.

Wonder why, because of poor SMP scalability and coarse locking? I've encountered some cases where SMT made performance worse such as with very optimized HPC libs but in general SMT can really help. Compiling projects got a nice boost when enabling HT on Intel's recent arch for example (all of this on Linux though, last time I checked OpenBSD its SMP perf was abysmal)

For I/O and memory bound processes, it makes it worse, saturating further buses that are already saturated. For regular. For CPU bound, it may help or not, depending on many factors, like cache/memory contention, nature of the operations... Compilation can get boosts because while some threads are waiting for I/O others are crunching source files. Also the variety of computation is high enough so multiple threads don…

Yeah I've spent my time looking at perf counters and I'm aware how cache access patterns affect. But the statement was drastic enough to make me suspect there is something more OpenBSD specific going on.

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

#127

Post by aade »

petee wrote: post #116
epynonymous wrote: post #91

i didnt see this posed in the comments, but it was certainly tops on my mind. is this the same issue for linux kernel?

If they are using Hyper Threading, then yes, unless they already have a different architecture: "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."

The (recent) SPARC Hypervisor does a fair job at this. Fujitsu has an interesting implementation. But it would be conceivably difficult to do this with time sharing on Intel chips without exposing side channels. That kind of control should be supervisory and in control of the chip. I haven’t yet seen that on Intel, but I’ve heard there are some hardware manufacturers that are looking to do something like that.

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

#128

Post by temprature »

keldaris wrote: post #117
flurrything wrote: post #103

Earlier quoted context omitted.

> is this really how they operate, OpenBSD is a research operating system and security is a core component of their research. Pro-actively mitigating security risks before exploits appear is one way to improve security that has worked in the past: vulnerabilities having been fixed before they appeared. Because they give reasonable deadlines for companies to fix security bugs (~90 days), they are kept out of the loop…

> if an OS is as security conscious as OpenBSD, there isn't really a different way to operate That's really what I was getting at with my question. There's no such thing as absolute security, it is a set of tradeoffs between usability, performance and specific security guarantees. Is there a point where the OpenBSD developers would say "okay, this is a (potential or confirmed) security bug, but the mitigation is just…

It's a sysctl that can be toggled. If you want hyperthreading and don't care about the security concerns, you can turn it back on. The commit message specifically mentions that this was implemented because many modern machines don't allow hyperthreading to be disabled in the BIOS.

You'll find out in a couple of months why they did this. I hope you'll remember the comments you've written when that happens, because you might learn something about what OpenBSD means when they say they "strongly suspect" something.

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

#129

Post by temprature »

orf wrote: post #108
flurrything wrote: post #103

Earlier quoted context omitted.

> is this really how they operate, OpenBSD is a research operating system and security is a core component of their research. Pro-actively mitigating security risks before exploits appear is one way to improve security that has worked in the past: vulnerabilities having been fixed before they appeared. Because they give reasonable deadlines for companies to fix security bugs (~90 days), they are kept out of the loop…

> Because they give reasonable deadlines for companies to fix security bugs (~90 days), they are kept out of the loop by hardware vendors like Intel who requested 1 year to fix meltdown. Is 90 days really a reasonable timeframe to fix something like meltdown? I agree with your whole comment in general, but hardware/microcode issues at Intel's scale are a different beast than some buffer overflow.

OpenBSD and DragonFly had their meltdown mitigations done in a couple of weeks from when it was publicly disclosed. If it's good enough for projects developed by handfuls of volunteers, it's good enough for the multi-hundred billion dollar megacorps.

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

#130

Post by temprature »

mrpippy wrote: post #35
classichasclass wrote: post #3

The implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.

I think the only other OpenBSD architecture that supports any SMT chips is sparc64 (like the US T1/T2). Unless an actual vulnerability is found, I don't see other OSes following this lead

An "actual vulnerability" has been found. It's amazing that even after the lazy FPU fiasco, people think OpenBSD did this on a complete whim.
Post reply on HN