Earlier quoted context omitted.
Because sane defaults are important.
Isn't this a "sane" default only in specific contexts though? (VMs). For a desktop PC that almost always runs a single heavy task (games, rendering, video encoding, etc) hyperthreading can be a day and night difference.
OpenBSD was right to disable hyperthreading [video]
101–110 of 284 posts
Re: OpenBSD was right to disable hyperthreading [video]
#102Earlier quoted context omitted.
Isn't the reason that technically the CPU is still fast and it is the OS (that is outside Intel's control) that slows it down? And AFAIK all OSes can disable these mitigations (are they even a concern for personal computers, especially for cases like gaming?) so if you really want you can get your performance back.
If you look at it this way, then the computer manufactures are to blame, and you should be refunded by them. That's the same as buying a car from CarCompany(TM) with an A/C and a Android Car touchscreen interface/radio/..., and an automatic android updates disables your A/C and changes the engine paramters so you have 20hp less... wouln't you expect "them" to fix it? As a consumer, you shouldn't have to worry if it's…
Re: OpenBSD was right to disable hyperthreading [video]
#103Earlier quoted context omitted.
Because sane defaults are important.
Isn't this a "sane" default only in specific contexts though? (VMs). For a desktop PC that almost always runs a single heavy task (games, rendering, video encoding, etc) hyperthreading can be a day and night difference.
Re: OpenBSD was right to disable hyperthreading [video]
#104Why aren’t the *BSD operating systems more popular in the server and workstation spaces?
Linux came after the BSDs, so you would think the BSDs would have won. There are many reasons Linux-based systems are generally much more popular than the BSDs in the server and workstation spaces. Here's why I think that happened: * GPL vs. BSD license. Repeatedly someone in the BSD community had the bright idea of creating a proprietary OS based on a BSD. All their work was then not shared with the OSS BSD communit…
For me, I ran FreeBSD for about a year around 1999. I lasted about a week before breaking down and installing a GNU userspace. Excellent CLI ergonomics for the day.
Linux had quite a few "easy to install" distros where, if your critical hardware was fully supported, you had something that was easier to get up and running than Windows 95/98. X configurations and sound drivers were a sticking points back then though. BSD had no such "easy mode" gateway drugs.
Re: OpenBSD was right to disable hyperthreading [video]
#105Earlier quoted context omitted.
Tannenbaum perhaps somewhere in the middle. Huge install base, but little noteriety.
Minix only has a "huge install base" because of Intel ME firmware junk. Its not really meaningful, because the firmware could be pretty much any arbitrary OS and it would make zero difference to any end user. Tannenbaum himself didnt even know about Intel using MINIX in their ME firmware until recently, so that should show you how much relevance it has.
Re: OpenBSD was right to disable hyperthreading [video]
#106Earlier quoted context omitted.
If I sell you a lock, and then 10 years later someone finds a vulnerability with the lock I sold you, should I refund you? That seems absurd. You are basically saying the product has to be perfect and the architects have to be able to see the future. Even if your hardware is formally verified, people can do physical attacks like listening to high frequency chirps of your cpu and using that to break security. Do you s…
Indeed its the difference between lying and making a mistake. Off course they hoped with, plausible deniability, to mask those lies as mistakes: but they got caught. Hence the class action suits.
Re: OpenBSD was right to disable hyperthreading [video]
#107Earlier quoted context omitted.
One must consider the potential damages that can happen when the default is wrong, as it’s nigh certain that people are going to be careless and not change it. If the desktop PC has wrong default the performance is bad. Still functional though. If in case of VM the default is wrong we will read another headline about how N million customers of $company got their personal data leaked.
I think we'll read such headlines regardless of that setting :-P. I'm actually wondering if there should be some sort of premade "profiles" when it comes to default settings. Debian for example is used in a lot of contexts so perhaps it'd make sense to have a way to ask you what sort of usage you'll do when installing and provide different defaults based on that (not just at the initial installation time but also whe…
Re: OpenBSD was right to disable hyperthreading [video]
#108The important thing to remember is that I am intentionally making those choices and considering that trade-off. Most users are not. It is somewhat better to leave things like ASLR enabled and hyperthreading disabled by default, because that is what is best for the average user.
Lastly, it is of not that if something such as this is disabled and there is a resulting security breach, every one will run around screaming, "Linux is insecure; ahh!" This will happen, even if the user is informed he is supposed to do this for things which need to be secure.
Re: OpenBSD was right to disable hyperthreading [video]
#109Earlier quoted context omitted.
Tannenbaum perhaps somewhere in the middle. Huge install base, but little noteriety.
Minix only has a "huge install base" because of Intel ME firmware junk. Its not really meaningful, because the firmware could be pretty much any arbitrary OS and it would make zero difference to any end user. Tannenbaum himself didnt even know about Intel using MINIX in their ME firmware until recently, so that should show you how much relevance it has.
Re: OpenBSD was right to disable hyperthreading [video]
#110Earlier quoted context omitted.
> 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.
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"