4 ms·

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 sche

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 out?

zokier 8y ago
Yeah, they are fairly risk-averse and not really performance oriented, so this decision feels pretty much in line with their practice.
2trill2spill 8y ago
> 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 out? 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 https://www.openbsd.org/goals.html [2]: https://www.bleepingcomputer.com/news/security/new-lazy-fp-state-restore-vulnerability-affects-all-intel-core-cpus/ https://www.bleepingcomputer.com/news/security/new-lazy-fp-s...
- da_chicken 8y ago
  > it seems that OpenBSD is an operating system built mainly for OpenBSD developers Honestly, I would say that this is true of many open source projects. It's one of the reasons that open source development tools are so good on Linux, but end user applications fall so far behind. It's also why documentation and usability tend to be much worse. When your system is based on volunteering, the work that gets done tends to be the stuff that interests the workers.
- forapurpose 8y ago
  > 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[ In fairness, my impression from the video of Theo's presentation was that they were tipped off by someone under embargo.
- dvfjsdhgfv 8y ago
  > it seems that OpenBSD is an operating system built mainly for OpenBSD developers I don't see it that way at all. Whenever I have to work on a project where security is top concern, I always look at OpenBSD as an option. In the Linux world, the equivalent would be the Openwall GNU/*/Linux project. Not something for an average user, but to say it's used by its devs mainly is off by an order of magnitude.
- bigato 8y ago
  > 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. This is not the feeling I get from OpenBSD at all. They don't act like research. They aren't keen on implementing new features just for the sake of it, or just to try it out. A better description would be that they put correctness, security and maintainability first, and simplicity often comes as a nice side effect. Deprecating old, unused features is just a consequence of striving to decrease complexity by trimming your code base. OpenBSD is one of the few OS where the number of lines of code is not skyrocketing to unmanageable numbers.
__jal 8y ago
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.
flukus 8y ago
Maybe they've got a heads up that there are more spectre like bugs incoming but not enough information to actually mitigate them. CPU bugs seem to be a rich vein to mine at the moment.
cat199 8y ago
> I'm not an OpenBSD user (and glad for it, if this is anything to go by), .. yet most likely if interacting with unix systems rely on OpenSSH. why would relying on a feature from a vendor with known processor security issues, including undisclosed hidden application processors, for a feature which has marginal performance improvement and in some cases degredation be a preferable stance? at best ambivalence towards this decision would be the position to take, esp. given the very recent 'oh hey fpu registers are also a problem' "discovery" which they were entirely correct about..
forapurpose 8y ago
> they "strongly suspect" (but don't know and haven't shown) Some security professionals seem to insist on having a proven exploit before they act. Doesn't that seem like poor decision-making? Their job is to provide security, not to secure proven exploits - the latter is a means to an end. If there are threats from unknown exploits, and there certainly are, then it seems that they need techniques to address unknown exploits. One of those techniques is expert analysis of potential threats.
tinus_hn 8y ago
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.
flurrything 8y ago
> 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 by hardware vendors like Intel who requested 1 year to fix meltdown. Being in the dark, if you see some suspicious behavior, either you protect yourself from it, or you might wake up the next day and Intel will have released a new "We are sorry" post and your users would be screwed. So this is pretty much how they operate, and if an OS is as security conscious as OpenBSD, there isn't really a different way to operate. Note that disabling hyper threading to mitigate CPU flaws isn't anything new either: this had to be done for AMD's Ryzen because of hardware bugs last year anyways - https://www.extremetech.com/computing/254750-amd-replaces-ryzen-cpus-users-affected-rare-linux-bug https://www.extremetech.com/computing/254750-amd-replaces-ry...
- orf 8y ago
  > 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.
  - gargravarr 8y ago
    Not to forget, Intel have said this collection of exploits cannot be fixed in microcode, only mitigated - it's so fundamental to the CPU hardware that it requires redesigning the chip to fix properly. The mitigation has led to serious performance hits and further problems down the line. And the permanent fix requires eventually replacing the CPU. As has been previously noted, Meltdown, Spectre and related exploits came about because nobody ever thought it would be possible to access the cache from other processes. 1 year is probably quite reasonable for Intel to redesign the architecture (in fact, is probably going to stretch to 2 years or more), but people need security fixes now. In this case, it looks like OpenBSD are taking the right approach.
YouAreGreat 8y ago
> disable HT outright That would describe it if they...disabled it outright. But they made HT user configurable, just like any other performance tuning knob.
_chris_ 8y ago
> So... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations Spectre is about a) leaving side-effects of misspeculation in shared resources, and b) bandwidth contention (between a misspeculated instruction stream and an attacker) to shared resources. It is trivially obvious that HT exacerbates Spectre-class bugs, as the entire raison d'être to HT is to share pipeline resources. How quickly information can be leaked can be up for debate, but it's definitely non-zero.
- ben_bai 8y ago
  How about 17 seconds? https://www.blackhat.com/us-18/briefings/schedule/#tlbleed-when-protecting-your-cpu-caches-is-not-enough-10149 https://www.blackhat.com/us-18/briefings/schedule/#tlbleed-w...
  - _chris_ 8y ago
    Thanks for the link! I should've been more precise: the question in my mind is how many kbits/second of arbitrary target memory can be leaked. That's what made Meltdown/Spectre so scary was that the entire kernel memory could be dumped on the order of hours.

zokier 8y ago

Yeah, they are fairly risk-averse and not really performance oriented, so this decision feels pretty much in line with their practice.

2trill2spill 8y ago

> 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 out? 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 https://www.openbsd.org/goals.html [2]: https://www.bleepingcomputer.com/news/security/new-lazy-fp-state-restore-vulnerability-affects-all-intel-core-cpus/ https://www.bleepingcomputer.com/news/security/new-lazy-fp-s...

da_chicken 8y ago
> it seems that OpenBSD is an operating system built mainly for OpenBSD developers Honestly, I would say that this is true of many open source projects. It's one of the reasons that open source development tools are so good on Linux, but end user applications fall so far behind. It's also why documentation and usability tend to be much worse. When your system is based on volunteering, the work that gets done tends to be the stuff that interests the workers.
forapurpose 8y ago
> 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[ In fairness, my impression from the video of Theo's presentation was that they were tipped off by someone under embargo.
dvfjsdhgfv 8y ago
> it seems that OpenBSD is an operating system built mainly for OpenBSD developers I don't see it that way at all. Whenever I have to work on a project where security is top concern, I always look at OpenBSD as an option. In the Linux world, the equivalent would be the Openwall GNU/*/Linux project. Not something for an average user, but to say it's used by its devs mainly is off by an order of magnitude.
bigato 8y ago
> 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. This is not the feeling I get from OpenBSD at all. They don't act like research. They aren't keen on implementing new features just for the sake of it, or just to try it out. A better description would be that they put correctness, security and maintainability first, and simplicity often comes as a nice side effect. Deprecating old, unused features is just a consequence of striving to decrease complexity by trimming your code base. OpenBSD is one of the few OS where the number of lines of code is not skyrocketing to unmanageable numbers.

__jal 8y ago

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.

flukus 8y ago

Maybe they've got a heads up that there are more spectre like bugs incoming but not enough information to actually mitigate them. CPU bugs seem to be a rich vein to mine at the moment.

cat199 8y ago

> I'm not an OpenBSD user (and glad for it, if this is anything to go by), .. yet most likely if interacting with unix systems rely on OpenSSH. why would relying on a feature from a vendor with known processor security issues, including undisclosed hidden application processors, for a feature which has marginal performance improvement and in some cases degredation be a preferable stance? at best ambivalence towards this decision would be the position to take, esp. given the very recent 'oh hey fpu registers are also a problem' "discovery" which they were entirely correct about..

forapurpose 8y ago

> they "strongly suspect" (but don't know and haven't shown) Some security professionals seem to insist on having a proven exploit before they act. Doesn't that seem like poor decision-making? Their job is to provide security, not to secure proven exploits - the latter is a means to an end. If there are threats from unknown exploits, and there certainly are, then it seems that they need techniques to address unknown exploits. One of those techniques is expert analysis of potential threats.

tinus_hn 8y ago

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.

flurrything 8y ago

> 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 by hardware vendors like Intel who requested 1 year to fix meltdown. Being in the dark, if you see some suspicious behavior, either you protect yourself from it, or you might wake up the next day and Intel will have released a new "We are sorry" post and your users would be screwed. So this is pretty much how they operate, and if an OS is as security conscious as OpenBSD, there isn't really a different way to operate. Note that disabling hyper threading to mitigate CPU flaws isn't anything new either: this had to be done for AMD's Ryzen because of hardware bugs last year anyways - https://www.extremetech.com/computing/254750-amd-replaces-ryzen-cpus-users-affected-rare-linux-bug https://www.extremetech.com/computing/254750-amd-replaces-ry...

orf 8y ago
> 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.
- gargravarr 8y ago
  Not to forget, Intel have said this collection of exploits cannot be fixed in microcode, only mitigated - it's so fundamental to the CPU hardware that it requires redesigning the chip to fix properly. The mitigation has led to serious performance hits and further problems down the line. And the permanent fix requires eventually replacing the CPU. As has been previously noted, Meltdown, Spectre and related exploits came about because nobody ever thought it would be possible to access the cache from other processes. 1 year is probably quite reasonable for Intel to redesign the architecture (in fact, is probably going to stretch to 2 years or more), but people need security fixes now. In this case, it looks like OpenBSD are taking the right approach.

YouAreGreat 8y ago

> disable HT outright That would describe it if they...disabled it outright. But they made HT user configurable, just like any other performance tuning knob.

_chris_ 8y ago

> So... they "strongly suspect" (but don't know and haven't shown) there may be a Spectre-class bug enabled by current HT implementations Spectre is about a) leaving side-effects of misspeculation in shared resources, and b) bandwidth contention (between a misspeculated instruction stream and an attacker) to shared resources. It is trivially obvious that HT exacerbates Spectre-class bugs, as the entire raison d'être to HT is to share pipeline resources. How quickly information can be leaked can be up for debate, but it's definitely non-zero.

ben_bai 8y ago
How about 17 seconds? https://www.blackhat.com/us-18/briefings/schedule/#tlbleed-when-protecting-your-cpu-caches-is-not-enough-10149 https://www.blackhat.com/us-18/briefings/schedule/#tlbleed-w...
- _chris_ 8y ago
  Thanks for the link! I should've been more precise: the question in my mind is how many kbits/second of arbitrary target memory can be leaked. That's what made Meltdown/Spectre so scary was that the entire kernel memory could be dumped on the order of hours.