The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels

[Volta]

So I'm sorry, but I'm tired of these security measures on on top of another that just reduce the performance of Linux desktop.
How about investing more into the other type of security that I said above?

I'm tired of people who think Windows is secure. When comes to your points it's rather KDE and Gnome job to do.

[road hazard]

What's with this AMD worship all of the time? Yes, Intel did worse, but AMD still made mistakes as they were hit by *some* of these issues.

Maybe because it's deserved? Unlike Intel, AMD didn't cut corners with their CPU design. All those years where benchmarks showed Intel CPU's dominating AMD..... now it all makes sense how they did it......... because they cut corners and security took a back seat to performance/profits.

Yes, AMD was impacted by some of these CPU vulnerabilities but not to the extent that Intel was. I'll never buy Intel CPUs again (because of them cutting corners) nor will I ever buy another Nvidia GPU (because of their hatred for Linux).

On a side note, I agree with others....... these tests should have included AMD hardware. Is there a reason why AMD wasn't tested?

[DanL]

Isn't 4.18 when CoC was inserted into the Linux kernel?

What does that have to do with anything?

[r08z]

I used to be one of those people that got the latest stable kernel thinking it would be faster and better. Then I learned about regressions.

You want a super fast kernel (set up for either latency or throughput) and don't care about security or debugging most things but aren't a dumb end user and takes the proper precautions when setting up userspace security sensitive programs like ssh, smb, ftp, vps, and don't download suspicious files then open them?

Get kernel 4.14 or 4.19 (your choice)

Disable all DEBUG features with the exception of hidden features available at "Configure standard kernel features (expert users)"
Enable hardware options for only YOUR hardware and what you might use in the future; using localmodconfig during first kernel config.
Disable almost all "Kernel Hacking" features expect the ones that might cause you much gray hair (like logging kernel oops or other goodies) some include:
printk and dmesg options --->
STRIP_ASM_SYMS=y
SECTION_MISMATCH_WARN_ONLY=y
STRICT_DEVMEM=y
IO_STRICT_DEVMEM=y

Disable Security kernel options: (can slow you down by 30% to 60%)
CONFIG_PAGE_TABLE_ISOLATION=n
RETPOLINE=n (Spectre v2 NSA hardware backdoor bugfix)
VMAP_STACK=n
STACKPROTECTOR=n
SLAB_FREELIST_RANDOM=n
HARDENED_USERCOPY=n

Disable two general features known to cause slow downs:
USERFAULTFD=n
MEMCG=n (Cgroup memory controller)

For latency performance set:
PREEMPT=y
HZ_1000=y

For throughput set:
PREEMPT_NONE=y
HZ_100=y

Set CPU frequency scaling to performance governor when plugged in to the wall or your distribution default when running on batteries.

Some sources:

http://www.hildstrom.com/projects/aestest/

https://blog.acolyer.org/2019/11/04/...perations/amp/

https://blog.nelhage.com/post/transparent-hugepages/

[birdie]

Security trumps performance. Its an essential tradeoff.

Its better to have it run more slowly than it have it untrustworthy. The additional security is as important on desktops and notebooks as well and you do not want to disable the security.

I would recommend against disabling it. Its not worth the risk.

Also the AMD CPUs do not suffer from much of a performance degradation which is due to AMD not playing fast and loose like Intel did. AMD was the one that did not cut corners in design, AMD is underappreciated, I think.

The best fix for the problem will come with hardware level fixes in a new generation of CPU.

If you're running untrustworthy code you're already fucked (aside from a web browser + JS + DRM plugins).

And if you're not running anything untrustworthy there's no need to have these mitigations in the first place.

What I'm trying to say is that applying blanket protection to all the code on your system means you're wasting CPU cycles on something totally superficial.

There's no security in slowing the system down - there's only a loss of electricity, time and money.

In a perfect world Linux and other OSes should apply transient execution vulnerabilities mitigations only to the apps you deem untrustworthy. Since most users are technically dumb, then maintainers could whitelist most of the apps, and apply the protections to all other applications.

Also in a perfect world web browsers should be removed as far as possible from the user session and data which is not done by any mainstream distro or OS. Web browsers have been the biggest threat to your security since the late 90's.

[MadCatX]

If you're running untrustworthy code you're already fucked (aside from a web browser + JS + DRM plugins).

And if you're not running anything untrustworthy there's no need to have these mitigations in the first place.

But that is not the point, is it? CPU attacks mitigations are important for two reasons. Even trustworthy software may have security bugs allowing the attacker to run some custom code and harvest data, protecting against CPU vulns helps reduce the attack surface. Much more importantly, CPU vulnerabilities break mechanisms that are supposed to make it possible to run untrusted code securely in an isolated environment. FWIW I believe that the kernel devs and distro maintainers are doing the right thing. You get a product that is secure by default. If you weight the risks and decide to trade security for speed, the kernel provides you with various means how to do it so what exactly is the issue here?

[Templar82]

"Current LTS release (4.19) out-performs all other kernels from 4.16 to unreleased 5.4. As expected".

Could you then enlighten us unwashed peasants as to why this is expected behavior?

[birdie]

But that is not the point, is it? CPU attacks mitigations are important for two reasons. Even trustworthy software may have security bugs allowing the attacker to run some custom code and harvest data, protecting against CPU vulns helps reduce the attack surface. Much more importantly, CPU vulnerabilities break mechanisms that are supposed to make it possible to run untrusted code securely in an isolated environment. FWIW I believe that the kernel devs and distro maintainers are doing the right thing.

On your desktop PC the only untrustworthy code which you usually run isJavaScript, period. What's the point of applying these protections to compilers? Video encoders/renderers? Word/Spreadsheets/Presentation applications? Graphics/Animation/CAD/etc? How any of these applications are able to run untrustworthy code in the first place?

I do understand the need to apply these protections to various network daemons which e.g. servers run, but again only to the ones which are facing the Internet directly, i.e. web servers (apache, nginx, etc), smtp/imap/pop3, probably sshd and that's it. All the rest should be firewalled, not be exposed to the Internet at all or placed beyond VPN anyways.

You get a product that is secure by default. If you weight the risks and decide to trade security for speed, the kernel provides you with various means how to do it so what exactly is the issue here?

No, that's not the case. Either you have all the protections enabled or all of them disabled and you cannot even enable/disable them in runtime, much less on a per app basis.

[birdie]

Disable Security kernel options: (can slow you down by 30% to 180%)

You can't slow down something by more than 100%, lol. And even slowing down something by 100% means it ceases to function completely, lol.

[eva2000]

Thanks Michael would like to see how a different cpu would fair like Intel 9900K vs 9900KS vs AMD Ryzen 3800X/3900X