Live data from Hacker News

OpenBSD was right to disable hyperthreading [video]

youtube.com

281–284 of 284 posts

Re: OpenBSD was right to disable hyperthreading [video]

#281
post #254
post #165

Earlier quoted context omitted.

no jail support on linux..

you miss the other point of Docker: cross-platform dev (and only occasionally cross-platform deployment)... I can run same set of docker containers that make up an app, including scaling multiple instances of each container, on (1) my macbook, (2) my ubuntu linux laptop, (3) my centos server (4) my windows laptop, (5) my other windows laptop, (6) my client's windows server. I can do this without bothering to configur…

... all 6 of which were running a linux vm until recently, and still predominately so (windows containers are hugely niche and have just about as much 'loner children' baggage in the larger commmunity)

writing a gui to spin up the VM flavor du-jour with one hipster command that you can show in an animated terminal in your bloated website doesn't make something cross platform underneath the hood, and that same VM runtime could run just about anything else.

and no, i don't miss the point. you miss the point - you are arguing market share as if it is technical merit. I'll take 1 true school unix hacker over 5 million 'noders' who cant debug their super hip k8s clusters they provisioned 'in the cloud' with wget|sh when they break.

Re: OpenBSD was right to disable hyperthreading [video]

#282

Earlier quoted context omitted.

I'm a right-wing libertarian, and I've never felt excluded or anything like that because of his leftist views. This for many reasons: 1) He's not a hypocrite in any way. He's honest and you can tell that he has truly thought about his opinions. 2) In my country, I get bombarded with a ralentless stream of leftist ideology. The worst kind of leftism: the lazy 'slogan' leftism, from people too stupid to realize the ful…

> 1) He's not a hypocrite in any way. He's honest and you can tell that he has truly thought about his opinions. I think that's crucial. I remember he was discussing one of the aspects of software freedom with my friend and she said "I don't agree." He answered: "No problem, you have your view, I have mine, we don't have to agree on everything." It struck me as I had expected he'll try to convince and win her over hi…

RMS has seen (and likely started) more flamewars in his lifetime than most of us ever will. He has clearly developed (or adopted) a meta-system to deal with differing views. If you ever talk to a smart priest, it's the same playbook: when it comes to deep beliefs, there is no point hammering something in your face, because it won't stick. Either you get to "truth" out of your own reasoning, or it's not worth it.

Re: OpenBSD was right to disable hyperthreading [video]

#283

Earlier quoted context omitted.

Close but not quite -- sibling hyperthreads (logical cores) share cache state. Physical cores do not share cache state. Different processes, threads, or VMs on sibling hyperthreads (by definition on the same physical core) can infer the other's memory state based on the cache state. If an attacker is pinned to one hyperthread, and the victim is pinned to another which isn't a sibling hyperthread, none of the spectre…

That's not true. Spectre works due to speculative execution leaking memory data through a side channel exposed by hyperthreading. That memory can be in use by any of the threads, not just the ones on sibling threads.

The side channel for most of the spectre variants is the latency of misses on the cache lines. L1 and L2 cache lines are local to a physical core. As far as I know, nobody has made any of the spectre variants work by measuring the latency of L3 cache misses, which are local to NUMA nodes if I understand correctly, but I'd love to hear otherwise.

The most recent round of spectre variants measured the latency of the line fill buffers and other parts which are local to a physical core's memory subsystem.

Re: OpenBSD was right to disable hyperthreading [video]

#284
post #37
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

AppArmor does that. I don't know what's the default profile for cat, but a simple one line "deny network;" works. It's up to the distribution.
Post reply on HN