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

Spectre mitigations murder userspace performance

robert.ocallahan.org

Post reply on HN
Print view View original

41–50 of 294 posts

Re: Spectre mitigations murder userspace performance

#41

Post by dijit »

thrower123 wrote: post #37
dijit wrote: post #16

Earlier quoted context omitted.

The scope of the potential damage is rather huge and can't really be overstated. It's akin to handing over your entire working OS memory to a person, complete with all encryption keys, session tokens and whatever documents you're working on. Potentially, anyway. The working proof-of-concept attacks I've seen use a lot of CPU to read memory and they read slowly, but those are proof-of-concepts and it would not be terr…

Has there ever been a real-world attack of this type? All kinds of things are possible, but you don't cut your leg off because theoretically you might possibly one day get gangrene from an ingrown toenail.

Yes there are working proofs of concept using JavaScript for this kind of attack.

https://leaky.page/ Is a good example

The proof of concept code has been further mitigated by removing high precision timers from JavaScript in most/all browsers; however it is not terribly difficult to create code which bypasses that restriction.

The only thing that’s prevented more investment into this method of attack is that it has essentially no value due to everyone being immune.

Re: Spectre mitigations murder userspace performance

#43

Post by mhh__ »

reader_mode wrote: post #22
thanksforfish wrote: post #9

Earlier quoted context omitted.

Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. So the risk may be closer to "clicking a link". https://www.zdnet.com/article/google-this-spectre-proof-of-c... Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.

How long would you have to run JavaScript on your desktop to leak sensitive information and has there been any known exploits in the wild ?

https://leaky.page/

I don't know about the wild, but if this were tuned (i.e. this requires a lot of work for the first byte, the rest are easy) for a HVT you wouldn't know.

Re: Spectre mitigations murder userspace performance

#44

Post by hjek »

thanksforfish wrote: post #9
FunnyLookinHat wrote: post #4

Should we have a debate as to whether or not Spectre mitigations matter for some (or all) desktop computers? I know that, theoretically, I could install a piece of software on my Linux box that is malware and could try to read my memory via those methods, but let's be honest - we're all mostly concerned with servers that run code for dozens or hundreds of different clients. I'm a foil hat as much as the next - securi…

Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. So the risk may be closer to "clicking a link". https://www.zdnet.com/article/google-this-spectre-proof-of-c... Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.

> Unfortunately "install a piece of software" also includes allowing javascript to run in your browser.

Per-process Spectre mitigations could be helpful there, but I don't understand the technical details to know whether that would be possible to implement. It would be nice to disable mitigations on a video editor and for gaming.

Re: Spectre mitigations murder userspace performance

#46

Post by mhh__ »

formerly_proven wrote: post #40
mhh__ wrote: post #32

Earlier quoted context omitted.

Why would you fans start spinning? You can extract data at at least hundreds of MB/s with these exploits, you wouldn't know.

That's the first time I have heard a number this high for these exploits. All prior numbers I've heard were many orders of magnitude smaller, more like byte/s. The article linked above cites 1 kB/s as novel.

That was a number I heard (Meltdown pre-mitigations) when the "oh shit" papers started dropping a few years ago, could be misremembering. I'm also still slightly inebriated so thank you for nerdsniping me (Lit Review time!)

Re: Spectre mitigations murder userspace performance

#48

Post by treis »

thanksforfish wrote: post #9
FunnyLookinHat wrote: post #4

Should we have a debate as to whether or not Spectre mitigations matter for some (or all) desktop computers? I know that, theoretically, I could install a piece of software on my Linux box that is malware and could try to read my memory via those methods, but let's be honest - we're all mostly concerned with servers that run code for dozens or hundreds of different clients. I'm a foil hat as much as the next - securi…

Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. So the risk may be closer to "clicking a link". https://www.zdnet.com/article/google-this-spectre-proof-of-c... Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.

I thought the browsers had put in their own mitigations that stop spectre/meltdown attacks.

Re: Spectre mitigations murder userspace performance

#49

Post by hjek »

xrisk wrote: post #30
christophilus wrote: post #25

Earlier quoted context omitted.

Yes, but your fans would start spinning like mad. I kill any browser that does that. You’d have to execute a successful attack within a few seconds to pull it off. I think that’s a risk I’ll take.

I don’t think that’s a good safety heuristic.

I agree that it's not good, yet anecdotally I've realized that a device has been compromised by running `top`, on Windows and on Linux. It's not a good heurestic because it's only disvoverable post-compromise.

Re: Spectre mitigations murder userspace performance

#50

Post by paulryanrogers »

nickpeterson wrote: post #3

I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…

Consider the philosophy of MAME which plays old games and avoids optimizing for GPUs and (IIRC) most specialized graphics layers like Direct3D or Metal. As I understand it this makes it more portable and easier to maintain, at the cost of some performance.

Now MAME's scope is limited to aging games which aren't evolving. Only the underlyibg OS's and runtime hardware are changing.

Console games pushing aging hardware have a very small variety of runtime hardware to optimize for. And optimizations pay off in better graphics or features that differentiate. Optimizing for ever evolving desktop computers with near infinite hardware is a whole different story.

Post reply on HN