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

21–30 of 294 posts

Re: Spectre mitigations murder userspace performance

#21

Post by netr0ute »

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.

That's what JavaScript blockers like NoScript and uBlock Origin are for.

Re: Spectre mitigations murder userspace performance

#22

Post by reader_mode »

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.

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 ?

Re: Spectre mitigations murder userspace performance

#23

Post by IshKebab »

dijit wrote: post #14
neilsimp1 wrote: post #2

`mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable Spectre/Meltdown mitigations, in case anyone is wondering. This page has a pretty decent write-up on it: https://leochavez.org/index.php/2020/11/16/disabling-intel-a... .

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

Kind of feels like apps should opt in to (or out of) mitigations individually. Obviously a web browser needs it, but does Clang? VSCode? Zoom? Probably not.

Re: Spectre mitigations murder userspace performance

#24

Post by zozbot234 »

infogulch wrote: post #15
UncleMeat wrote: post #7

Earlier quoted context omitted.

> 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”. Turning off speculative execution reduces performance enormously . Yes, code is often less efficient than it could be but "surprise, you need 5x as large of a datacenter because your hardware isn't doing fancy stuff" is not going to…

I suspect our heavy reliance on speculative execution is just a local optimum, and we can grow out of it by providing the processor more information about the data flow, making memory access more explicitly asynchronous, and simplifying the hot paths. I like the way the mill approaches these architectural problems.

The interesting part about the Mill is that it's not even all that complex. It's just taking the existing VLIW architectural approach and adding a number of custom "tweaks" to improve the programming model over what VLIW provides.

Re: Spectre mitigations murder userspace performance

#25

Post by christophilus »

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.

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.

Re: Spectre mitigations murder userspace performance

#26

Post by tux3 »

infogulch wrote: post #15
UncleMeat wrote: post #7

Earlier quoted context omitted.

> 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”. Turning off speculative execution reduces performance enormously . Yes, code is often less efficient than it could be but "surprise, you need 5x as large of a datacenter because your hardware isn't doing fancy stuff" is not going to…

I suspect our heavy reliance on speculative execution is just a local optimum, and we can grow out of it by providing the processor more information about the data flow, making memory access more explicitly asynchronous, and simplifying the hot paths. I like the way the mill approaches these architectural problems.

I'm very unconvinced by these arguments. Providing enough information to the processor to claw back all the performance that predictors give you, that requires some way of knowing all those things in advance. Statically.

And so you fall into the pit of tar and despair that is relying on Sufficiently Smart Compilers. Same one that couldn't save Intel's shiny new IA-64 architecture (the "Itanic").

Static analysis is just not a tractable way to replace hardware predictors. Even profile-guided information is a questionable answer. Could it be we're missing some key idea that'll take us far beyond all of this? Maybe, but it's probably not the same WLIV designs that require impossible feats of software comparable to asking for the weather 2 years in advance so you can save yourself the hardware cost of an umbrella.

Now, perhaps it would be unfair to criticize the Mill for not taping out an actual chip, after all having new ideas is valuable and fabs are very expensive. But we know this is a tricky subject. Performance optimization ideas only have value after you benchmark them, and they don't have an RTL implementation. Nothing that can run on an FPGA, not even "abstract" Verilog running in a testbench on a software simulator.

If what you want is a DSP that runs super simple hot loops very fast, then build a DSP and make it VLIW all you like. But that's not the workloads people run on a general purpose computer.

Re: Spectre mitigations murder userspace performance

#27

Post by pjc50 »

infogulch wrote: post #15
UncleMeat wrote: post #7

Earlier quoted context omitted.

> 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”. Turning off speculative execution reduces performance enormously . Yes, code is often less efficient than it could be but "surprise, you need 5x as large of a datacenter because your hardware isn't doing fancy stuff" is not going to…

I suspect our heavy reliance on speculative execution is just a local optimum, and we can grow out of it by providing the processor more information about the data flow, making memory access more explicitly asynchronous, and simplifying the hot paths. I like the way the mill approaches these architectural problems.

Is the Mill dead? I've not seen the regular flow of HN posts about it recently. Everyone got excited about RISC-V instead.

Re: Spectre mitigations murder userspace performance

#28

Post by mhh__ »

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…

The issue is that virtual machines could be very easy targets if there weren't mitigations (It's much more complicated than that but that's the idea)

Re: Spectre mitigations murder userspace performance

#29

Post by dustingetz »

dijit wrote: post #14
neilsimp1 wrote: post #2

`mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable Spectre/Meltdown mitigations, in case anyone is wondering. This page has a pretty decent write-up on it: https://leochavez.org/index.php/2020/11/16/disabling-intel-a... .

I love that this is a toggle like this, having control of my system is why I love Linux. But I must caution desktop users against doing this for performance, it's _much_ better to have some kind of build server somewhere else with this kernel flag than to run it on your desktop. Why? because your desktop executes untrusted and rather arbitrary code pretty often, not just in the form of Javascript but that's the large…

your desktop is already rooted by Zoom

Re: Spectre mitigations murder userspace performance

#30

Post by xrisk »

christophilus wrote: post #25
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.

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.
Post reply on HN