Hacker News Reader

Comment by danarmak | Hacker News Reader

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.

View on HN

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

On your desktop? Probably none.

On the image that you're pushing out to your fleet of production servers? Maybe a couple.

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.

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

> 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

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"

"I told you so" gets less satisfying each time you get to say it, yaknow? (* commiseration, no criticism)

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?

Reply on news.ycombinator.com