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

51–60 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#51

Post by technofiend »

dleslie wrote: post #35
mikece wrote: post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

At a time when the commercial BSD companies were fighting among themselves and allowing their technology to become stale and remain expensive, Linux came along with RedHat and SuSE. Those two made an effort to meet directly with business leaders, attend all the trade shows, and gave their product away for free. Their model was at least as shocking as their license; hitherto, hardly any business software was free and…

Even prior to RedHat and SuSE for some reason System V-based systems were deemed more suitable to business, at least by Sun Microsystems. I stand corrected based on beef's comment below: they migrated from BSD to Sys V as part of Solaris aka SunOS V. I was misremembering their adding streams support to SunOS 4 as the big switch but I was wrong about that.

Re: OpenBSD was right to disable hyperthreading [video]

#52

Post by roryrjb »

moviuro wrote: post #37
pas wrote: post #27

Earlier quoted context omitted.

Because you can get the same technical outcome with using off the shelf Linux and setting it up to be conservative just like OpenBSD. (Or simply run sensitive workloads on separated/isolated machines.) The dreaded TCO is likely lower with Linux, because it's easier to work with, better drivers, better performance, more software available natively, and so on. (The whole Linux ecosystem seems more efficient for busines…

> setting it up to be conservative just like OpenBSD Meh. Probably for superficial stuff, yes. But would Linux kill cat(1) if it did some network calls? I bet not. See https://www.openbsd.org/innovations.html

You can do this with seccomp, but of course not by default like pledge and OpenBSD.

Re: OpenBSD was right to disable hyperthreading [video]

#53

Post by ailideex »

moviuro wrote: post #37
pas wrote: post #27

Earlier quoted context omitted.

Because you can get the same technical outcome with using off the shelf Linux and setting it up to be conservative just like OpenBSD. (Or simply run sensitive workloads on separated/isolated machines.) The dreaded TCO is likely lower with Linux, because it's easier to work with, better drivers, better performance, more software available natively, and so on. (The whole Linux ecosystem seems more efficient for busines…

> setting it up to be conservative just like OpenBSD Meh. Probably for superficial stuff, yes. But would Linux kill cat(1) if it did some network calls? I bet not. See https://www.openbsd.org/innovations.html

You could block it's network access with network namespaces: http://man7.org/linux/man-pages/man1/unshare.1.html

I'm sure you could engineering something to kill it also with currently kernel functionality - though I would need to do more research to say what.

Re: OpenBSD was right to disable hyperthreading [video]

#54

Post by AnIdiotOnTheNet »

marcosdumay wrote: post #40
mikece wrote: post #2

Why aren’t the *BSD operating systems more popular in the server and workstation spaces?

It has lower performance than Linux, and some compatibility problems that appear once in a while. It used to be fashionable to run BSD on security focused machines (like firewalls). I'm not sure why Linux won there too.

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

Re: OpenBSD was right to disable hyperthreading [video]

#56

Post by AnIdiotOnTheNet »

geggam wrote: post #44
danarmak wrote: post #11

Earlier quoted context omitted.

On the other hand, if BSDs had been more popular, one of these splinters might have dominated the market as much as Linux does, due to the many positive feedback effects of being the most successful free OS.

It still is a possibility. The Linux community is becoming a mess of things stuck together in and its getting to be really interesting to support.

The BSDs aren't really much better in that regard once you leave the base install, and their hardware support is substantially worse.

Re: OpenBSD was right to disable hyperthreading [video]

#57

Post by mitchtbaum »

tyingq wrote: post #30
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.

Tannenbaum perhaps somewhere in the middle. Huge install base, but little noteriety.

the middle is kind of a funny territory

appearances would say it's between two polar complements

as some bridges extend beyond the scene, even from behind it

reminds me of 'a message that discredits the medium that carries it'

~~

sun and moon watercolor painting, "Polar Complements" original watercolor painting, zentangle art, wall art, decor living room decor

https://www.etsy.com/dk-en/listing/626399645/sun-and-moon-wa...

https://imgur.com/2Te9EBF

https://imgur.com/XIWBmum

~~

(maybe to slow down thy downvotes: I don't intend for this comment to make a whole lot of sense to you, right at this moment.. hopefully you'll at least enjoy the painting...)

Re: OpenBSD was right to disable hyperthreading [video]

#58

Post by dleslie »

technofiend wrote: post #51
dleslie wrote: post #35

Earlier quoted context omitted.

At a time when the commercial BSD companies were fighting among themselves and allowing their technology to become stale and remain expensive, Linux came along with RedHat and SuSE. Those two made an effort to meet directly with business leaders, attend all the trade shows, and gave their product away for free. Their model was at least as shocking as their license; hitherto, hardly any business software was free and…

Even prior to RedHat and SuSE for some reason System V-based systems were deemed more suitable to business, at least by Sun Microsystems. I stand corrected based on beef's comment below: they migrated from BSD to Sys V as part of Solaris aka SunOS V. I was misremembering their adding streams support to SunOS 4 as the big switch but I was wrong about that.

Sun probably had a good sales team. ;)

Re: OpenBSD was right to disable hyperthreading [video]

#59

Post by zdw »

geggam wrote: post #17
chrisseaton wrote: post #12

Earlier quoted context omitted.

> Because the people who pay folks to work on systems dont like to pay enough money to get that level of talent. People like Google can't pay enough? Do all the BSD developers work as front-end quants or something? How are they all earning so much that nobody can afford them?

Google doesn't use BSD. (to my knowledge) Yahoo! did but they also had BSD developers on the payroll. Any Silicon Valley company will pay enough but that is why when you leave Silicon Valley or a big tech hub everything is windows. The pay attracts the talent.

To speak to the specific case, Google does use some BSD components - large portions of the C library in android are OpenBSD sourced:

https://undeadly.org/cgi?action=article&sid=20140506132000

Google also has donated to the OpenBSD foundation historically in relatively small amounts: https://www.openbsdfoundation.org/contributors.html

Re: OpenBSD was right to disable hyperthreading [video]

#60

Post by rrss »

throwaway2048 wrote: post #24
dnautics wrote: post #10

Perhaps someone might know better than me: why is hyperthreading necessarily bad? Can't you just keep it on and give your tenants cores with affinity? For example, some tenant wants two cores, you give them two vcores on the same core; some tenant wants four cores, you give them two vcores over two, etc.

Because unless you make hyperthreading a purely opt in thing, there is no way to know as a kernel if two things that are security sensitive relative to each other are being run on the same core as Hyperthreading neighbors. Two threads in a web browser that are assigned to different websites for instance.

> there is no way to know as a kernel if two things that are security sensitive relative to each other

The kernel has a way, and it is process isolation. The kernel doesn't care if you want two threads in the same process to be isolated from one another - that's your problem, not the kernel's.

Anyway, thread isolation already doesn't work even without hyperthreading-specific attacks: "we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels. In the face of this reality, we have shifted the security model of the Chrome web browser and V8 to process isolation" (from https://arxiv.org/pdf/1902.05178v1.pdf).

Post reply on HN