Originally posted by Danny3
View Post
Announcement
Collapse
No announcement yet.
The Disappointing Direction Of Linux Performance From 4.16 To 5.4 Kernels
Collapse
X
-
Originally posted by Vistaus View Post
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.
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?
- Likes 9
Comment
-
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:
https://blog.acolyer.org/2019/11/04/...perations/amp/
Last edited by r08z; 20 November 2019, 10:23 AM.
- Likes 6
Comment
-
Originally posted by Neraxa View Post
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.
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.Last edited by birdie; 11 November 2019, 03:26 PM.
- Likes 3
Comment
-
Originally posted by birdie View Post
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.
- Likes 3
Comment
-
Originally posted by MadCatX View PostBut 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.
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.
Originally posted by MadCatX View PostYou 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?Last edited by birdie; 11 November 2019, 04:03 PM.
- Likes 3
Comment
-
Comment