31–40 of 158 posts
OpenBSD finds yet another way to shoot themselves in the foot.
By continuing a security-first mindset that they've been establishing for decades?
The only way to minimize attacks is to have less capable language classes exposed to the outside world. The last time I checked they still have an http stack which is usually either turing complete or context sensitive.
Earlier quoted context omitted.
I'd say it's probably closer to: > OpenBSD finds yet another way to harden their OS. This is a conscious choice to disable something that could potentially allow for an entire class of security vulnerabilities. I suppose a decent analogy could be they chose to amputate a damaged foot before it had time to turn gangrenous.
Yes, it's probably easier to exploit with hyperthreading, but does disabling hyperthreading stop the exploits? No, it's just an incomplete solution and a minor setback at an enormous cost. OpenBSD does these often, and it looks silly doing it.
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?
Earlier quoted context omitted.
>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 performance. Intuitively this may sound logical, however in practice it's often not the case. For many workloads putting two threads of the same program on a core ends up being worse than co…
> The reason is that two threads of the same program will often end up executing similar instruction streams Why is that bad?
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.g. a process to do encryption won't use the floating point units) and/or b) can't use them all because of how the program's written (for example, if I say 'load a random memory address, then add it to a register, then load another random memory address, then add it, etc' I'm going to be spending most of my time waiting for memory to be loaded.
SMT basically means that you run another program at the same time, so even if the encryption process can't use the floating point units, maybe there's another process that we can schedule that will.
However, imagine my encryption process can use 6 of the 8 arithmetic units. If I have 2 encryption processes scheduled on the same core, I have demand for 12 when there are only 8. So now I have contention for resources, and I won't see a speedup from using SMT.
Other comments mention registers and not execution units: I'm suspicious of this, since modern processors have many registers (for Skylake, 250+) which they remap between aggressively as part of pipelining. Maybe this is different for the SIMD units.
That said, I haven't looked at this stuff since university so could well be wrong on the execution unit vs register comparison.
The implication seems to be that other architectures are also soon to have SMT disabled by default. That would definitely hurt POWER, for example.
Earlier quoted context omitted.
Chrome does, Firefox does not (I've got 5 processes for a billion tabs.)
Firefox process per tab is behind a feature flag as it’s in testing still
OP (and environs) has names on it that I have seen before and respect as knowing what the hell they are on about.
Ouch. I will say though, Hyper-Threading is a lot less valuable these days than it was when it was first introduced (except for the few dual core CPUs still available). When you have four-six-eight or more cores, there's less value in doubling that number. The gain is lower.
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…
I'm not a OpenBSD user either, I use FreeBSD whenever possible. However from listening to OpenBSD devs, via blogs, conferences, HN, etc, it seems that OpenBSD is an operating system built mainly for OpenBSD developers, their goals support this[1]. OpenBSD being useful for non OpenBSD developers is more of a secondary goal compared to how FreeBSD or Linux or any other OS handles it. Also OpenBSD is much more of a research operating system then other large successful OS(Linux, Windows, MacOS, FreeBSD, etc). Meaning OpenBSD cares way more about developing features and novel security mitigations then trying to maintain backwards compatibility like other operating systems do.
> 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?
The OpenBSD devs strongly suspected another Intel hardware bug a week or two ago, implemented a mitigation and deployed it. Turns out they were right[2].
[1]: https://www.openbsd.org/goals.html
[2]: https://www.bleepingcomputer.com/news/security/new-lazy-fp-s...
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?
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.