3 ms·

Two of the three (current) top-level replies compare BSDs to Linux in general, but that really has nothing to do with whether you disable HT. Using Linux should

Two of the three (current) top-level replies compare BSDs to Linux in general, but that really has nothing to do with whether you disable HT. Using Linux should not have stopped anyone from listening to Theo and disabling HT months ago. Your security authorities don't have to be your kernel developers.

josteink 7y ago
> Using Linux should not have stopped anyone from listening to Theo and disabling HT months ago. Iirc OpenBSD actively disabled it for you, making it the default. Nobody else did that.
- danarmak 7y ago
  If that's true, it's wonderful and I applaud them for making this decision. I haven't been following this conversation closely; is there any serious change of Linux (some distributions, or the kernel upstream) disabling HT by default?
- beefhash 7y ago
  > Iirc OpenBSD actively disabled it for you, making it the default. They have, as of this commit[1] on 2018-06-19. [1] https://marc.info/?l=openbsd-cvs&m=152943660103446&w=2 https://marc.info/?l=openbsd-cvs&m=152943660103446&w=2
- baybal2 7y ago
  In fact, cache p3 timing attack was known as "theoretically possible" back in nineties, but was booed out of the conversation by "big name security analysts"
  - h2odragon 7y ago
    "I told you so" gets less satisfying each time you get to say it, yaknow? (* commiseration, no criticism)
bagacrap 7y ago
How many other decisions made by kernel developers are you supposed to second-guess because you know better?
- ertian 7y ago
  On your desktop? Probably none. On the image that you're pushing out to your fleet of production servers? Maybe a couple.
  - beatgammit 7y ago
    What about everyone else? Many companies only operate a handful of servers, and they often don't have the staff to know the kernel that intimately, so they rely on sane defaults. These companies are also not typically using their CPUs to the max, so disabling HT seems like a reasonable default. If you know enough to know whether up should be using HT, you can enable it yourself.

josteink 7y ago

> Using Linux should not have stopped anyone from listening to Theo and disabling HT months ago. Iirc OpenBSD actively disabled it for you, making it the default. Nobody else did that.

danarmak 7y ago
If that's true, it's wonderful and I applaud them for making this decision. I haven't been following this conversation closely; is there any serious change of Linux (some distributions, or the kernel upstream) disabling HT by default?
beefhash 7y ago
> Iirc OpenBSD actively disabled it for you, making it the default. They have, as of this commit[1] on 2018-06-19. [1] https://marc.info/?l=openbsd-cvs&m=152943660103446&w=2 https://marc.info/?l=openbsd-cvs&m=152943660103446&w=2
baybal2 7y ago
In fact, cache p3 timing attack was known as "theoretically possible" back in nineties, but was booed out of the conversation by "big name security analysts"
- h2odragon 7y ago
  "I told you so" gets less satisfying each time you get to say it, yaknow? (* commiseration, no criticism)

bagacrap 7y ago

How many other decisions made by kernel developers are you supposed to second-guess because you know better?

ertian 7y ago
On your desktop? Probably none. On the image that you're pushing out to your fleet of production servers? Maybe a couple.
- beatgammit 7y ago
  What about everyone else? Many companies only operate a handful of servers, and they often don't have the staff to know the kernel that intimately, so they rely on sane defaults. These companies are also not typically using their CPUs to the max, so disabling HT seems like a reasonable default. If you know enough to know whether up should be using HT, you can enable it yourself.