Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD was right to disable hyperthreading [video]

youtube.com

Post reply on HN
Print view View original

141–150 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#141

Post by AnIdiotOnTheNet »

derpherpsson wrote: post #118
AnIdiotOnTheNet wrote: post #54

Earlier quoted context omitted.

Generally people prefer stuff that works over stuff that is nebulously "more secure".

Stuff breaks when it is hacked. State actors are now targeting whole populations. It takes less and less time to enumerate the entire IPv4 address space. Knowledge about hacking is becoming more and more accessible to a larger group of people. This problem is not going away - it is growing larger for every year. If you don't believe me: Just attach an object to the internet and watch the logs.

> Stuff breaks when it is hacked.

Yep, but you have to grade it based on likelyhood. Which costs more, a thing that doesn't work right now or a thing that might not work in the future, maybe. If you can make it work now and be secure, good, otherwise people will, quite rationally, prefer that it work.

Re: OpenBSD was right to disable hyperthreading [video]

#142

Post by gwright »

x0x0 wrote: post #99
ScottFree wrote: post #90

Earlier quoted context omitted.

Does that apply here? The BSD guys chose security over speed, as is their mantra, but companies that run linux for profit prioritize speed and cost per computing unit over security. I think 'disable hyperthreading' would be a difficult sell even for Steve Jobs.

This is why we need enormous fines for security breaches, and smaller fines just for not following best practices. Right now, only the people worried about paying more for performance, dev time, or security engineers are listened to. We need the legal teams inside companies to have something more substantial than possible negative publicity with which to motivate the CEO and CTO as a countervailing balance. Just like…

Not taking anything away from your point, I think we should also have real negative consequences for the people who commit security breaches.

There is a real social stigma with regard to committing robbery, burglary, breaking and entering, etc. I feel like there isn't so much with online crime. As a community we really pile the blame on the victim for not be prepared and seem to give the perpetrators a pass for taking advantage of the situation.

Also, there is a real tension between anonymity on the Internet and the ability to identify perpetrators. It is a difficult tradeoff.

Re: OpenBSD was right to disable hyperthreading [video]

#143

Post by cosarara »

x0x0 wrote: post #101
Crinus wrote: post #76

Earlier quoted context omitted.

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.

Your desktop PC is regularly running largely unverified code, some of it potentially hostile: all the javascript in your browser.

Browsers have mitigations in place, don't they? Aren't they enough, at least on paper?

Re: OpenBSD was right to disable hyperthreading [video]

#144

Post by ScottFree »

mikepurvis wrote: post #133
x0x0 wrote: post #99

Earlier quoted context omitted.

This is why we need enormous fines for security breaches, and smaller fines just for not following best practices. Right now, only the people worried about paying more for performance, dev time, or security engineers are listened to. We need the legal teams inside companies to have something more substantial than possible negative publicity with which to motivate the CEO and CTO as a countervailing balance. Just like…

Isn't GDPR supposed to be an attempt at this kind of thing, treating privacy issues as a punishable negative externality similar to pollution? I only ask because that all makes perfect sense to me, but I see a lot of negativity about GDPR on here, that all it ever does is stifle innovation and produce ever more cookie-agreement popups.

The EU has seen poor results with fines. The big tech companies (Google, Amazon, etc) pay them with the change they find in their couch cushions. Then, they continue doing whatever they want to do. It doesn't dissuade them.

Re: OpenBSD was right to disable hyperthreading [video]

#145

Post by [deleted] »

atheowaway4z wrote: post #131
x0x0 wrote: post #99

Earlier quoted context omitted.

This is why we need enormous fines for security breaches, and smaller fines just for not following best practices. Right now, only the people worried about paying more for performance, dev time, or security engineers are listened to. We need the legal teams inside companies to have something more substantial than possible negative publicity with which to motivate the CEO and CTO as a countervailing balance. Just like…

What ever incentive you create and analogy you make. The hardware / software / internet has no parrellel. I’ve been thinking about the place of software in the context of other disciplines and here is the thing. If you are thrown back to the prehistory with 50 man dream team of engineers, and are told to recreate ... something. Let’s say the train station I was just in. A rudimentary train network could be created in…

[deleted]

Re: OpenBSD was right to disable hyperthreading [video]

#146

Post by morpheuskafka »

throwaway2048 wrote: post #92
tyingq wrote: post #30

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

Yes, but it is significant that an industry leading company chose it over a RTOS or other embedded system for a high volume project.

Re: OpenBSD was right to disable hyperthreading [video]

#147

Post by riffraff »

alxlaz wrote: post #127
dleslie wrote: post #9

History will show that Theo was right in a manner similar to how Stalman was right: technically correct analysis and eerily accurate predictions, but lacking in sufficient charisma to create more than a small following. To some extent, you might say they are like Cassandra; speaking the truth but not believed or listened to.

Lacking in charisma hardly describes a person like Theo de Raadt. I've never met the man, but I doubt that someone who lacks charisma could have lead a dedicated, opinionated team through more than 40 releases (counting OpenBSD releases alone!), over a period of almost 25 years now, a team which not only developed a sturdy (if equally opinionated) operating system but also a bunch of highly successful projects like,…

the same applies to Stallman, if you consider that the FSF has been running for 34 years.

But I believe grandparent didn't mean they lack charisma, but that they didn't have enough to swerve the general public.

Re: OpenBSD was right to disable hyperthreading [video]

#148

Post by jimbob45 »

x0x0 wrote: post #99
ScottFree wrote: post #90

Earlier quoted context omitted.

Does that apply here? The BSD guys chose security over speed, as is their mantra, but companies that run linux for profit prioritize speed and cost per computing unit over security. I think 'disable hyperthreading' would be a difficult sell even for Steve Jobs.

This is why we need enormous fines for security breaches, and smaller fines just for not following best practices. Right now, only the people worried about paying more for performance, dev time, or security engineers are listened to. We need the legal teams inside companies to have something more substantial than possible negative publicity with which to motivate the CEO and CTO as a countervailing balance. Just like…

In all honesty, security is just really hard and we're really bad at it. Perhaps an alternative would be to establish standards when it comes to security team headcount and salary in an organization? That way they're incentivized to follow the rules and you have more leeway to punish them if they don't follow the baseline.

Re: OpenBSD was right to disable hyperthreading [video]

#149

Post by throw0101a »

marmaduke wrote: post #79
throw0101a wrote: post #26

Earlier quoted context omitted.

NetApp, Dell-EMC Isilon, Juniper, iXsystems, pfSense, etc: * https://en.wikipedia.org/wiki/List_of_products_based_on_Free... If you follow the commit logs, you'll regularly see "Sponsored by" messages: * https://www.freshsource.org/commits.php Not just for the core OS, but also in ports and also drivers (Intel, Chelsio, Mellonox). FreeBSD in particular has always been persnickety about acknowledging work done on beha…

Not all EMC systems are FreeBSD; at least the VNX I managed is a Linux derivative

Hence why I wrote Dell-EMC Isilon.

Isilon and their OneFS was a stand-alone company (like Panasas still is). EMC bought Isilon. Then Dell and EMC merged.

Re: OpenBSD was right to disable hyperthreading [video]

#150

Post by throw0101a »

siffland wrote: post #67
throw0101a wrote: post #26

Earlier quoted context omitted.

NetApp, Dell-EMC Isilon, Juniper, iXsystems, pfSense, etc: * https://en.wikipedia.org/wiki/List_of_products_based_on_Free... If you follow the commit logs, you'll regularly see "Sponsored by" messages: * https://www.freshsource.org/commits.php Not just for the core OS, but also in ports and also drivers (Intel, Chelsio, Mellonox). FreeBSD in particular has always been persnickety about acknowledging work done on beha…

I have been using FreeBSD since 1999, a great OS and i love it, at work i am a Linux system administrator. One of the huge reasons people use FreeBSD is simply licensing. If you dont want to release any source code simply build your custom app on FreeBSD and only include BSD licensed software. Makes being proprietary simple. Note, this does not mean any companies that do this do not give back to the project, they do…

Companies that do not give back non-secret sauce patches will find they will contribute to their own pain (unless they're big enough to fork and not care about going back).

Isilon did not contribute back for a while, and then the FreeBSD project kept moving forward, and so the patches they kept in-house kept getting bigger and bigger, which was overhead in their development.

They've basically caught up now:

* https://en.wikipedia.org/wiki/OneFS_distributed_file_system#...

Post reply on HN