A Global Switch To Kill Linux's CPU Spectre/Meltdown Workarounds?

[torsionbar28]

It probably depends heavily on the games you play. The games I play are almost entirely CPU limited on my machine.

Yes that's true. There's a Linus Tech Tips video where he does this exact comparison, and he found that maybe 20% of AAA games are CPU bound, while the vast majority are not.

It also depends on the settings. E-sports gamers like lowest possible graphics detail, and often have large numbers of other players onscreen. This is demanding on the CPU, but not so much on the GPU. E-sports gamers want the very fastest i7 cpu, paired with a mid-range gpu like Rx 480 or GTX 1060.

But for most visually demanding AAA titles, you want the biggest baddest GPU you can get, but a midrange cpu is fine. I'll share my own personal setup, it's an Opteron 4386 (circa 2012) with a Vega 56 @ 1080p. This *six* year old CPU paired with a modern GPU, gets me 100+ fps on Ultra settings for most AAA games released through ~2017.

Edit: You don't have to take my word for it. Look at the system requirements for the newly released (Feb 2019) Metro Exodus. Look at the "recommended" hardware for 1080p. It recommends a very new GPU, Radeon Vega or Nvidia RTX. But it recommends a six year old CPU from 2013, the i7-4770k: https://www.guru3d.com/articles_page...chmarks,2.html

[cybertraveler]

Actually they're not. There's only a handful of games that stress the cpu. Most games are heavy on the gpu, and only moderate to light on the cpu. It's why you can game comfortable on a 5+ year old CPU, paired with a Vega or RTX.

It probably depends heavily on the games you play. The games I play are almost entirely CPU limited on my machine.

[torsionbar28]

Actually, most games are limited by the CPU, and usually because the game does not take advantage of as many threads as it could.

Actually they're not. There's only a handful of games that stress the cpu. Most games are heavy on the gpu, and only moderate to light on the cpu. It's why you can game comfortable on a 5+ year old CPU, paired with a Vega or RTX.

[chrcoluk]

1) Why do you assume the user is using Chrome or Firefox? This is an unreasonable thing to assume, because there will be lots of users who don't use them. There are probably also lots of users that use an old version of Chrome or Firefox because some addon they like only works with it or simply because "the updates were annoying".

2) There have been a constant stream of new avenues of attack recently. Even if the user is using Chrome or Firefox are you sure that their browser is patched against the latest exploitable CPU bugs?

3) I noticed you completely ignore my game map example. Tons of people run mods these days. If you play CS:GO, then there's a good chance you've run a community map before. Maps and mods contain code and it's possible that this code in some engines can be used to exploit these CPU vulnerabilities.

I also noticed that you started re-framing the conversation from "typical home user and gamer" to "typical Linux user" and you also added specifics about what activities are safe. You are giving out very bad advice if you are suggesting typical home users and gamers disable OS spectre & meltdown mitigations. You likely have no idea what applications they will install and use on their PC over time.

Also: VMs can creep onto the average person's PC quite easily these days without them even fully understanding that they are using a VM. This can come in the form of a modern game console emulator. It could come in the form of an Android emulator (there are a number of them on the market now aimed at allowing users to play Android games and use other popular Android apps on their x86 PC).

The typical home user and gamer does not have the knowledge and OPSEC to be able to make a well informed decision on whether it is safe for them to disable these mitigations or not.

I stand by my claim. Typical home users and gamers should absolutely not disable these spectre and meltdown mitigations.

Well I am confident in saying this.

Lets say we got two different users.

One has fully patched OS, all these mitigation's enabled (also bear in mind these mitigation's aside from PTI are partial only, they have ways to bypass), however he allows all javascript by default in browser, has no filesystem isolation, no isolated process in browser and no ad filtering.
Second user has no intel cpu mitigation activated, either disabled or OS not up to date, but does block all javascript in browser unless whitelisted, blocks ads unless whitelisted, is vigilant so doesnt click on random url's that are spoofed, doesnt download exe's from dodgy sources etc., isolates his filesystem with things like SRP, Applocker, isolates his browser.

My bet would be on the first guy getting bad things happening to his PC before the second, easily.

[chrcoluk]

all those patches only make sense in environments where you could have other users on the same cpu. So that would be cloud environment, a hosting provider, ... So the googles and amazons of this world are indeed better off applying those.

For any local linux desktop use these patches are total bullshit.
As a user you would only be very VERY VERY marginally more insecure by not having those patches. There are far easier ways to hack a user then to go though cpu bugs.

I stopped considering these patches as "sane" since the latest L1TF ones where disabling hyper-threading was a solution (thus crippling your performance). We basically get thrown back years in performance if we start applying those suggestion. This is just security paranoia that makes no sense at all anymore.

And i'm not being sarcastic here. I'm dead serious.

One of the few on the net who gets it, I applaud your post.

I try and explain to people, that these exploits in the real word are not much of an issue, but they cry "but it can read unauthorised memory blah blah blah", they are in panic mode and not thinking rationally.

Malware authors go for low hanging fruit, and none of these exploits are low hanging fruit, they are difficult to pull off and all the test cases have been done with admin/root access already on a machine, in other words you need to be already compromised.

When looking as security one should always balance the pros and cons, do not just blindly apply every single security measure without thinking about it. One of the worse pieces of advise I often read is "always update your machine, its the number one thing you can do for been secure", that advice is given because its what computer illiterate users are capable of doing, its sort of like the old tech support "clear your internet cache and reboot".

The reality is these exploits are probably only going to be a problem for a typical end user if all other aspects of computer security get locked down, these are literally a last resort type exploit for malware authors, so one is basically throwing away large chunks of performance for maybe a decade in the future someone has a tiny chance of trying to use these exploits in the wild.

Its akin to spending $300 on anti ransomware software "just incase" you get asked for $200 to get your files back. The former is a guarantee, the latter is a extremely low chance maybe.

I find these tests really good, pretty much noone else has done anything like this, but what I would like to see is the impact of these mitigations one by one, so we can see if individual impacts have a reasonable level of impact that can be disregarded.

On proxmox qemu on a ivy bridge xeon host (has PCID but not NVPCID), I compared a fully patched system on its defaults against toggling individual mitigations. They were only toggled on the proxmox host I didnt bother to toggle on the guests as well which may make the results even bigger.

The result was in my case.

PTI on its own had a small but not ignorable level of impact, tasks on a guest dont take noticeably longer but do have higher cpu utilisation, on average 1.1 or 1.2x multiple on cpu utilisation so 10-20% more cpu cost.
IBRS, almost doubles cpu utilisation and makes things slower on the guest, absolutely trashes hypervisor performance.
l1tf on its default setting, makes compiling code on a guest take about 30% longer, cpu utilisation isnt much affected on low threaded workloads, but high threaded workloads like compiling are noticeably more expensive in cpu cycles. So e.g. on a pfsense firewall in a guest, it has pretty much no impact, but if you encoding stuff, compiling, that sort of thing, you will feel it. Disabling this on the host I noticed also disabled it on qemu, qemu auto appended the flag that disables it in the guest when I disabled it on the host.

Microsoft have clearly been uneasy about IBRS, they pulled the intel microcode from automatic updates and have recently announced they switching to the reptoline solution in a future build of windows 10, the microcode solution was never even offered to win 7/8 users at all. The reality is this stuff should not have been disclosed given there is no evidence ofit been out in the wild, and in addition to that patches should not have been deployed in such a rushed and panic'd manner, IBRS should never have even reached stable clode, reptoline should have been the "first" spectre v2 mitigation on offer, and things like l1tf should not be enabled by default as the benefit is very situational.

[ilmaisin]

AFAIK publishing or forwarding private correspondence is a copyright violation in pretty much every country.

I don't think that a bunch of insults will surpass the treshold of originality.

Btw it's funny when this guy accuses that "people with zero security/IT background keep talking nonsense", when that's what he himself does (no, a sysadmin is not a software developer let alone a security specialist).

[RussianNeuroMancer]

AFAIK publishing or forwarding private correspondence is a copyright violation in pretty much every country.

There is interesting opinion about this in another thread:

you are confusing private correspondence with private attacks

[bridgman]

In fact in certain countries of the world leaking of private correspondence is considered a misdemeanor or even a crime.

AFAIK publishing or forwarding private correspondence is a copyright violation in pretty much every country.

[chithanh]

This is how you do it properly (obviously you've never had any manners, so the concept must be totally alien to you):

This is not exactly a novelty. Because that Intel was working on Adaptive-Sync/FreeSync support was already known to anyone who was up to date about developments in the Linux graphics stack:

Not sure who originally pushed back on upstreaming as AMD-only code but the focus for the last year has been on finding a cross-vendor solution. I believe the main participants have been Manasi from Intel plus some AMD folks.

Only those Windows-only hardware reviewers who are generally not interested in anything Linux could have missed that. And that tech writer who actually questioned it, yikes.

[TheGrave]

e

Phoronix: A Global Switch To Kill Linux's CPU Spectre/Meltdown Workarounds?

Something I have seen asked in our forums and elsewhere -- most recently on the kernel mailing list -- is whether there is a single kernel option that can be used for disabling all of the Spectre/Meltdown workarounds and any other performance-hurting CPU vulnerability workarounds...

http://www.phoronix.com/scan.php?pag...p-Spectre-Melt

Very useful, applied it to my laptop. Does the list of switches cover Foreshadow as well or simply there are no mitigation techniques implemented yet?

How about the opposite - enable all Spectre/Meltdown/Foreshadow mitigation options? I'd like to enable them (to some extent, without killing HT) on my server.