Spectre mitigations murder userspace performance • Hacker News Board

Re: Spectre mitigations murder userspace performance

#31

Post by temac » Sat, Jun 19, 2021, 1:32 PM UTC

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…

You would be surprised how "slow" a non speculative processor is.

Even Intel Atoms have been speculative since Silvermont.

If you take more mainstream historical processors, for example:

https://www.cpu-world.com/Compare/385/Intel_Pentium_Dual-Cor...

Let say the Pentium MMX 166 is roughly 60x slower, per core, than the Pentium G6950. So the "IPC" (I'm not sure of what the benchmark are doing, but I'm doing rough evaluations anyway) is approx 3.5 lower for the Pentium MMX.

And that is while the speed gap constantly increased between memory and CPU (esp latency), so a Pentium MMX cpu core somehow speed up to 2.8 GHz would actually probably perform even worse in a design with memory that actually exists. Maybe way worse.

The complexity of modern good ARMs is comparable or even higher in some area than the complexity of x86 processors.

Re: Spectre mitigations murder userspace performance

#32

Post by mhh__ » Sat, Jun 19, 2021, 1:32 PM UTC

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.

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

Re: Spectre mitigations murder userspace performance

#33

Post by mhh__ » Sat, Jun 19, 2021, 1:34 PM UTC

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…

But rendering isn't what makes a modern computer slow. For example, Assassin's creed isn't even that well optimized but it maxes all threads, uses all the GPU and looks beautiful.

And people have tried "simple" hardware (it ends up being not simple) that the programmer (compiler) understands before, it doesn't work.

Re: Spectre mitigations murder userspace performance

#34

Post by apgwoz » Sat, Jun 19, 2021, 1:35 PM UTC

kd913 wrote: post #19

Is this agnostic to hardware? I thought Intel/AMD had different strategies regarding variants of spectre with AMD having specific solutions of retpoline. Without knowing the hardware, what is the point of the performance comparison?

> Skylake, Linux 5.12

Re: Spectre mitigations murder userspace performance

#35

Post by temac » Sat, Jun 19, 2021, 1:36 PM UTC

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.

This has been tried (not on vaporhardware Mill, I'm more thinking about e.g. Intel Itanium) and it failed.

The reason is extremely simple: a speculative OOO processor optimizes dynamically. If you switch that with static compile time optimizations, you are bound to only be as fast as before in some quite limited parameter ranges (like: number of entries in a hash table, size of an image, etc.)

Re: Spectre mitigations murder userspace performance

#36

Post by dijit » Sat, Jun 19, 2021, 1:36 PM UTC

IshKebab wrote: post #23

dijit wrote: post #14

Earlier quoted context omitted.

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.

Three main things here:

1) we can’t trust people to categorise their own apps because the incentive for performance over security is a trade off we’ve all made time and time again.

2) efforts to address mandatory access controls have a coloured history here: selinux and apparmor both have very low adoption rates no matter your personal anecdotes.

3) These mitigation’s are so thorough that it would be more expensive on performance to even _check_ per application than it would be just to enable it everywhere.

Re: Spectre mitigations murder userspace performance

#37

Post by thrower123 » Sat, Jun 19, 2021, 1:36 PM UTC

dijit wrote: post #16

nerdponx wrote: post #5

Who is ultimately at risk because of Spectre and Meltdown? What additional risks am I taking on by disabling mitigations?

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.

Re: Spectre mitigations murder userspace performance

#38

Post by mhh__ » Sat, Jun 19, 2021, 1:36 PM UTC

nerdponx wrote: post #5

Who is ultimately at risk because of Spectre and Meltdown? What additional risks am I taking on by disabling mitigations?

Meltdown for example can exfiltrate data at a genuinely ridiculous rate, from any process (or at least any interesting ones).

Spectre is more context dependent but Meltdown is egregious.

Re: Spectre mitigations murder userspace performance

#39

Post by mhh__ » Sat, Jun 19, 2021, 1:38 PM UTC

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.

I assume the triple letters have done it, but these attacks require a lot of careful planning so why bother when you can exploit something else. That kind of protects us, but these exploits are terrifying for purveyors of homogenous interfaces (i.e. the cloud) that can be attacked in ways you are already imagining.

Also, anyone deploying this won't be stupid enough to chat.

Re: Spectre mitigations murder userspace performance

#40

Post by formerly_proven » Sat, Jun 19, 2021, 1:38 PM UTC

mhh__ wrote: post #32

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.

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.