OpenBSD disables Intel's hyperthreading due to security concerns

Post by ben_bai » Wed, Jun 20, 2018, 6:35 PM UTC

_chris_ wrote: post #141

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…

> 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…

Post by bigato » Wed, Jun 20, 2018, 8:32 PM UTC

keldaris wrote: post #142

bigato wrote: post #140

Earlier quoted context omitted.

They don't set defaults for the average use case when security is involved. This is the difference between: "Secure by default", turn knobs if you need more speed "Fast by default", turn knobs if you need more security Not that the knobs will be always available for each design decision, but sometimes they are there and you can turn them at your own risk. It probably would be wise to understand the consequences. Some…

> They don't set defaults for the average use case when security is involved. They certainly set the defaults for some usecase, it just happens to be more security-biased than most. They don't ship an OS for an airgapped toaster, so it can't ever literally be "secure by default", it's just a compromise on the tradeoff scale that's more security-oriented than most. It still needs to be usable (for some set of people)…

Post by keldaris » Thu, Jun 21, 2018, 10:38 AM UTC

bigato wrote: post #153

keldaris wrote: post #142

Earlier quoted context omitted.

> They don't set defaults for the average use case when security is involved. They certainly set the defaults for some usecase, it just happens to be more security-biased than most. They don't ship an OS for an airgapped toaster, so it can't ever literally be "secure by default", it's just a compromise on the tradeoff scale that's more security-oriented than most. It still needs to be usable (for some set of people)…

You seem to imply that security will always result in less speed or less usability, and that is not always the case. The thing with OpenBSD is that security will always come first between the three values when they clash, but they don't always clash. And yes, it is the most secure OS out there if you are to judge by the statistics over its history. I'd say that only two remote holes in so many years pretty much grant…

Post by bigato » Thu, Jun 21, 2018, 12:56 PM UTC

keldaris wrote: post #155

bigato wrote: post #153

Earlier quoted context omitted.

You seem to imply that security will always result in less speed or less usability, and that is not always the case. The thing with OpenBSD is that security will always come first between the three values when they clash, but they don't always clash. And yes, it is the most secure OS out there if you are to judge by the statistics over its history. I'd say that only two remote holes in so many years pretty much grant…

> You seem to imply that security will always result in less speed or less usability, and that is not always the case. Certainly not always, but often enough and more so than usual with Spectre and Meltdown. > As an example of simplicity, I am not personally aware of any install that is so simple as theirs. Except maybe ubuntu's, but then with ubuntu you end up with a mess of interdependent packages and it will be a…