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

Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

phoronix.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#41

Post by [deleted] »

CamperBob2 wrote: post #39
rayiner wrote: post #33

I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.

I would rather wait for reports of dangerous JavaScript exploits in the wild, myself. Considering that no real-world exploits of Spectre and related attacks have actually been reported, the odds that I'll fall victim to such an exploit without hearing about it in plenty of time to mitigate it are in the millions to one. Instead, everyone has to pay the performance tax proactively, regardless of their individual threa…

[deleted]

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#42

Post by Aardwolf »

According to this [1], the coffee lake refresh has hardware mitigation to meltdown variant 3 and variant 5 (which are only a few of all the things).

Would that hardware mitigation reduce this performance loss?

[1]: https://www.anandtech.com/show/13400/intel-9th-gen-core-i9-9...

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#43

Post by [deleted] »

rwmj wrote: post #26
bonzini wrote: post #6

This was known. https://lwn.net/Articles/765837/ reports 21% performance impact and the plan was to handle STIBP as an opt-in security feature. I am not sure why that was not furthered in the patches that have actually been committed to Linux, as I did not follow them closely.

Apparently the way to turn this and other mitigations off is the following mouthful: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier Would it make sense to have a single flag to "run insecure but fast" that we can use on pure development machines, test servers and the like? My Intel development server only runs code I choose.

[deleted]

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#44

Post by garaetjjte »

xxpor wrote: post #37
rayiner wrote: post #33

I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.

Do you expect Grandpa to do that analysis? The mitigations are probably behind KCONFIG flags anyway.

No need to modify build config, this and other spectre mitigations can be disabled in cmdline (spectre_v2=off)

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#45

Post by bronzeage »

I'm just sitting here waiting for all the security fiasco to stop ruining performance for ridiculous unpractical attacks. Just a matter of time, the pressure for better performance in a world where moore's law is getting stuck will eventually cause every sane person to throw these ridiculous patches out of the window.

If the choice is between unsecure but fast to secure and slow, the default should be fast. Let applications who care about side channel deal with it their way, why the fuck should everything be so slow just so that few apps which actually care about side channel will be secure?

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#47

Post by amaranth »

bronzeage wrote: post #45

I'm just sitting here waiting for all the security fiasco to stop ruining performance for ridiculous unpractical attacks. Just a matter of time, the pressure for better performance in a world where moore's law is getting stuck will eventually cause every sane person to throw these ridiculous patches out of the window. If the choice is between unsecure but fast to secure and slow, the default should be fast. Let appli…

This is just the mitigations at the kernel level, to protect the kernel from applications and applications from each other. Without this applications can't even attempt to secure themselves from these issues. I think to allow applications a chance to opt into being secure from these attacks without applying the fixes system-wide you'd need a way to disable speculative memory reads per page which would nerf performance even harder for the applications that turned that option on.

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#48

Post by crustycoder »

rwmj wrote: post #26
bonzini wrote: post #6

This was known. https://lwn.net/Articles/765837/ reports 21% performance impact and the plan was to handle STIBP as an opt-in security feature. I am not sure why that was not furthered in the patches that have actually been committed to Linux, as I did not follow them closely.

Apparently the way to turn this and other mitigations off is the following mouthful: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier Would it make sense to have a single flag to "run insecure but fast" that we can use on pure development machines, test servers and the like? My Intel development server only runs code I choose.

This alphabetti spaghetti of boot flags is getting ridiculous, there seems to be no central list anywhere, just random snippets across the web. Why is there not a Linus rant when you really need one? :-(

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#49

Post by frostburg »

CamperBob2 wrote: post #39
rayiner wrote: post #33

I don't like how these Scepter mitigations are being rolled out with no cost/benefit analysis. On a client machine, I'd rather just disable Javascript than pay a 30-50% performance penalty for mitigating these vulnerabilities.

I would rather wait for reports of dangerous JavaScript exploits in the wild, myself. Considering that no real-world exploits of Spectre and related attacks have actually been reported, the odds that I'll fall victim to such an exploit without hearing about it in plenty of time to mitigate it are in the millions to one. Instead, everyone has to pay the performance tax proactively, regardless of their individual threa…

Would you like a nuclear powerplant to be ran with this kind of approach to safety? Given the amount of possible targets and how unreliable people can be at assessing what risk they're exposed to, having mitigation active by default is obviously the only sane answer.

Re: Bisected: The Unfortunate Reason Linux 4.20 Is Running Slower

#50

Post by gizmo686 »

bronzeage wrote: post #45

I'm just sitting here waiting for all the security fiasco to stop ruining performance for ridiculous unpractical attacks. Just a matter of time, the pressure for better performance in a world where moore's law is getting stuck will eventually cause every sane person to throw these ridiculous patches out of the window. If the choice is between unsecure but fast to secure and slow, the default should be fast. Let appli…

And I'm sitting here waiting for the industry to start taking security seriously. These are not ridiculously unpractical attacks. These are attacks that have been hypothesized for years and are only now getting attention because people finally started to create (public) demonstrations. I would be shocked if there were not already non-public exploits based on these vulnerabilities.

The only reason these attacks even have the appearance of being unpractical is because there are so many other areas of our computing systems that are even easier to attack.

The only reason we are in this current Spectre et. al. mess is that CPU vendors choose to prioritize performance over security, and we now have to live with their bluff getting called for another hardware generation or two. I suspect that the performance impact will be far less when the fixes are done during the hardware design process, instead of figuring out how to bolt them on after the fact.

Ultimately, I think we are overdo for a new computer architecture (both in terms of security and performance, we are being encumbered by the need to keep new architectures backwards compatible with old ones).

Post reply on HN