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

[caligula]

I claim that every user should disable those cpu "fixes". They have been here for a decade or so and never be an issue. The pesky effect is that linux (and i understand that for the public appearance and server market it serves) just patches the hell out of it's kernel to make it secure. That's fine. But for desktop users, there is no threat when not applying the patches. Unless you prove me wrong? You can't.

FWIW, many of the security switches in the kernel don't really slow down gaming performance. You can mitigate the slowdown by overclocking your system 1% or more. Disabling security features won't help you fix slow framerates. Consider buying a GTX 2080 Ti if there's not enough steam in the engine. Maybe also 4 channel memory and a 8700k CPU with proper liquid cooling.

[cybertraveler]

BS on top of BS.

1) Chrome/Chromium and Firefox are used by > 98% of Linux users out there. There are practically no other popular browser engines in Linux other than these two. Exploiting Meltdown and Spectre via JS is a very expensive ($$$) and tedious attack - you have to leave your browser window open for ages for the attacker to able to do anything. JS is still a lot slower than native code.

2) I'm pretty sure about that because I trust Firefox/Google developers a lot more than I trust your opinion. After all it's Google developers who discovered those vulnerabilities in the first place.

3) Among the people who I know no one uses any game mods and I'm talking about at least a hundred of people. Over 95% of them never play any games aside the ones which are built into the OS they are running (solitaire and such). You have to be insane to believe that someone is going to waste literally hundreds of thousands of dollars to implement and embed a Spectre/Meltdown-like exploit in a game mod. Such vulnerabilities are usually used against very high profile targets.

You may stand by whatever BS you don't really understand but that doesn't make your stance any more valuable. I'm also sure you have never written a single line of code in C or assembler which further invalidates everything you're saying. I'm also pretty sure you understand nothing about CPU/RAM architectures. You've heard about these vulnerabilities yet you understand shat about what they really are and how they can be exploited yet you have the guts to incite people to follow your advice.

To this date, and those vulnerabilities are now eight months old, there hasn't been a single virus detected or an intrusion incident occured which involved them yet kernel developers have slowed down our PCs without giving an option to have the lost performance back.

1) I was talking about Windows as well as GNU/Linux. I was speaking generally. Look at the thread before my post. People are also talking about Windows. I deliberately used general terms to include them. So many users are going to be using other browsers. Also: even if it was just 2% purely on GNU/Linux (which it isn't), you're saying it's ok to recommend people turn it off because... those other 2% don't matter? I sure hope you never give tech advice to anyone in my family.

2) Have you even checked to see whether the latest Chrome and Firefox builds are accounting for the latest CPU issues?

3) Again, not only is your personal experience not something worthy of drawing conclusions about but you once again put 5% (by your probably wrong number) of people in danger.

Finally: I am a software developer by profession and my current project is a massively-concurrent, cross platform, C application that interfaces with hardware and has networking features. I'm not an expert in CPU design but I know a lot more about computers than your average person.

I am not arguing that there shouldn't be options to disable these fixes. I haven't and wouldn't say that. I am stating that when dealing with your typical home user and gamer, you should not be advising them to turn these protections off. You don't know what software they're going to run. You don't know if they're going to be targetted at some point. You don't know if someone will write attack code that targets a specific, popular, application/CPU/OS combination to mass-infect lots of PCs.

[cybertraveler]

markg85 - you don't know what you're talking about. You made tons of mistakes in your post. At least birdie understands the topic.

[Danny3]

A global switch to kill all the Linux CPU vulnerabilities migigation would be great and greatly needed.
I believe there are many cases where these are not required like when the OS in on a standalone computer not connected to the internet or it's installed in a virtual machine with the network disabled or there are literaly no sensitive information on it.
I hope the developers will let the people decide for themselves for their specific cases.

[markg85]

markg85 - you don't know what you're talking about. You made tons of mistakes in your post. At least birdie understands the topic.

Feel free to point them out.
Note that i am a software developer and know my way in performance profiling and (to some degree) cpu instructions.
The only thing i'm likely wrong about is my purely out-of-thin-air written down percentage.

I am however wrong in the cpu instructions with billion and trillion. That should be more realistically in the millions and billions.

[cybertraveler]

Feel free to point them out.
Note that i am a software developer and know my way in performance profiling and (to some degree) cpu instructions.
The only thing i'm likely wrong about is my purely out-of-thin-air written down percentage.

I am however wrong in the cpu instructions with billion and trillion. That should be more realistically in the millions and billions.

I'm not having a discussion with you dude. Just read your own post back. It's packed with nonsense. I can sense that as soon as I point out just 1 of the many issues with it, you're going to churn out more nonsense in response.

Ain't nobody got time for that.

[birdie]

Unless you prove me wrong? You can't.

[Weasel]

Typical home users and gamers should absolutely not disable these spectre and meltdown mitigations. Without them a custom map for a game, a website running javascript or malicious code running in a virtual machine could either take control of the system or gain access to sensitive data.

This is not to even mention that meltdown can enable privilege escalation. This means that a user process or even a security sandboxed user process which is compromised by an attacker could gain access to kernel memory and essentially gain full control over the PC.

The vast majority of computer users should leave all these mitigations enabled.

All of these vulnerabilities are read-only and writes during speculative execution (which get discarded). So they can only leak data.

[flower]

FWIW, many of the security switches in the kernel don't really slow down gaming performance. You can mitigate the slowdown by overclocking your system 1% or more. Disabling security features won't help you fix slow framerates. Consider buying a GTX 2080 Ti if there's not enough steam in the engine. Maybe also 4 channel memory and a 8700k CPU with proper liquid cooling.

Depends on the game
Cities Skylines with many mods is a real problem and the reason why i had to disable them (i7-4ghz 16gb ram).

(And yes.. i know that i am at risk. especially because i run foreign and closed-source mods/games. but i dont really care because if someone hacks my gaming-pc... well he can run games and change my save games: not a real problem)

EDIT: i still think it is a bad idea to run untrusted code on a trusted system. just because we don't know that an exploit exists doesnt mean it doesnt exist. i only trust physically seperated machines for important data

[cybertraveler]

All of these vulnerabilities are read-only and writes during speculative execution (which get discarded). So they can only leak data.

Thanks.

Considering what you've said, it may be possible to execute code with kernel-level privileges if the permission system is coded in a particular way. If for instance an operating system handles privilege elevation using kernel-generated, secure access tokens (which I think Windows does IIRC), then a process using Meltdown may be able to elevate itself. It's likely that the people designing permission systems make the assumption that kernel memory is not readable by user-land processes, so there is likely all sorts of information in kernel memory which could be used by an attacker to get extra control.