This was very well known when the mitigations came out but I do wonder if they were too broad.
sure mitigation in place for a platform that run untrusted code like a browser make sense but should it affect every program running? I know trust is fickle but at least for power user there should be an option to disable mitigation on a per program basis.
Spectre mitigations murder userspace performance
11–20 of 294 posts
Re: Spectre mitigations murder userspace performance
#12I’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…
We’re seeing a full frontal assault on Intel by competing computing architectures. Everyone is jockeying to see who is going to have the better next gen architecture. The problem is that in order to start attacking general computing as a problem, you need first customers who buy a lot of chips, and those customers tend to have specific workloads they want accelerated. Now we’re back to designing for customers instead…
I think this has cause and effect reversed. Advancing general purpose CPU's is very hard and expensive nowadays. The slower rate of progress means that custom chips make more sense, they take longer to become obsolete.
Re: Spectre mitigations murder userspace performance
#13I’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…
> 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…
More specifically, we should point out that speculative execution is important for papering over IO/memory latency. We can incant all we want about 'inefficient code', but the compute vs memory latency imbalance is a whole different beast.
Re: Spectre mitigations murder userspace performance
#14`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 largest example I can think of.
Right now there's a kind of herd immunity for these things, nobody would really attack spectre because everyone is running mitigations, but if you make the target large enough there will be working exploits.
For isolated machines running trusted workloads (thinking: databases or webservers serving static content) then it's a really nice flag to have on-hand.
Re: Spectre mitigations murder userspace performance
#15I’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…
> 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.
Re: Spectre mitigations murder userspace performance
#16Who 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 terribly difficult for a motivated person to make them significantly faster and less obvious.
Re: Spectre mitigations murder userspace performance
#17For interested Windows users, you can disable spectre and meltdown mitigations using InSpectre:
Re: Spectre mitigations murder userspace performance
#18This was very well known when the mitigations came out but I do wonder if they were too broad. sure mitigation in place for a platform that run untrusted code like a browser make sense but should it affect every program running? I know trust is fickle but at least for power user there should be an option to disable mitigation on a per program basis.
> sure mitigation in place for a platform that run untrusted code like a browser make sense but should it affect every program running?
The issue is that mainstream OS's are simply not designed to protect against information disclosure vulns like Spectre in a principled way. https://en.wikipedia.org/wiki/Multilevel_security is a very well known approach academically but practical implementation is lacking. So we have to go with one-size-fits-all mitigations that treat all code as untrusted, and all data as potentially sensitive.
Re: Spectre mitigations murder userspace performance
#19Is 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?
Re: Spectre mitigations murder userspace performance
#20`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…
Nice 3rd party toggle for windows: https://www.grc.com/inspectre.htm
Or a Powershell script from MS: https://support.microsoft.com/en-us/topic/understanding-get-...