i didnt see this posed in the comments, but it was certainly tops on my mind. is this the same issue for linux kernel?
OpenBSD disables Intel's hyperthreading due to security concerns
91–100 of 158 posts
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#92Earlier quoted context omitted.
In practice it sometimes is the case, though. SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other. If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource. On balance, on typical workloads…
Typical workloads? What's that? People run hugely diverse workloads on cpus, and they change over time.
I don't know whether it's still true, but a couple of years ago a majority of the world's CPU cycles were spent sorting things.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#93Earlier quoted context omitted.
In practice it sometimes is the case, though. SMT/hyperthreading is complicated. If you have a workload dominated by non-local DRAM fetches, it's a huge win because when the CPU pipeline is stalled on one thread it can still issue instructions from the other. If you have a workload dominated by L1 cache bandwidth, the opposite is true because the threads compete for the same resource. On balance, on typical workloads…
> workload dominated by non-local DRAM fetches, How often is that a polite way of saying "software that is inefficient"?
There are plenty of problems with poor mechanical sympathy.
To take an extreme example, traversing graphs is notorious. Cray and Sun iirc have some fascinating processors with many many hyperthreads because all the programs do is wait on dram but luckily there are lots of searches that can be done in parallel.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#94Re: OpenBSD disables Intel's hyperthreading due to security concerns
#95I'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.
You could just buy i5 based machines instead which don't have hyperthreading.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#96Earlier 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…
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?
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#97What scares me is that they do OS wide change based of wording "This can make", "And since we suspect" and "In all likelyhood" instead of doing actual tests. I know that open systems doesn't have required workforce, but doing changes based on subjective reasoning is slippery slope.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#98Earlier 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…
> I've never experienced that with Chrome Right, but I doubt that it's for exactly the reason you think it is: Chrome doesn't blindly do "one process per tab" anymore, and hasn't for a bit.
You can enable it (as I have) on chrome://flags/#enable-site-per-process
Strict site isolation Security mode that enables site isolation for all sites. When enabled, each renderer process will contain pages from at most one site, using out-of-process iframes when needed. When enabled, this flag forces the strictest site isolation mode (SitePerProcess). When disabled, the site isolation mode will be determined by enterprise policy or field trial. – Mac, Windows, Linux, Chrome OS, Android
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#99So... 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…
I would expect them to choose security over performance, that is how they operate. Microsoft would sweep this under the carpet, that’s what they do.
Re: OpenBSD disables Intel's hyperthreading due to security concerns
#100I'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.
You could just buy i5 based machines instead which don't have hyperthreading.
[deleted]