This is a little outside of my normal blatherings format but after stumbling upon a video from Red Robbo’s YouTube channel. I wanted to investigate his claims that maybe, just maybe the security mitigations that I have chosen they are a bit excessive for my use case. Recently, openSUSE has added a feature to make this easily user adjustable. Since they made it easy, obviously, someone far smarter than I am has decided that some of the mitigations may be excessive and not worth the performance loss for all use cases. I written about the mitigations some time ago and how it is fun to see all that is being implemented. Maybe it’s time to dial it back.
This is the video that made me pause and think about the choices I’ve made.
Red Robbo made the statement, “how many people are actually impacted by this, not potentially impacted but actually…”
Fair statement, what is my actual risk. not imaginary but actual risk. So that got me thinking. My setup has been to keep the mitigations on “Auto”. That seems fair to me. Let the system decide how many mitigations I need to have in place. Then this video came out and It got me thinking…
“How many mitigations do I really need to have to protect my system?”
“What are the threats against my main machine, a laptop, that does not run any services?”
“How much of a performance improvement would I have if I switched the mitigations off?”
According to SUSE, by leaving the mitigations to Auto, “All CPU side channel mitigations are enabled as they are detected based on the CPU type. The auto-detection handles both unaffected older CPUs and unaffected newly released CPUs and transparently disables mitigations. This options leave SMT enabled.”
It was time to explore this further. Do some, self-discovery, as it were.
In reading all the CVEs on the subject, they are worded as either, “Local attacker”, “In theory”, “…a possible approach”, “could be made to leak”.
I couldn’t help but think, golly, this is all… speculative… isn’t it. I now wonder what the actual threat is. I appreciate how the fixes were very much preemptive before any attacks were made but it almost seems like building my house so that it is meteor proof, just in case of meteor strike.
What I’ve done
So I did as Red Robbo suggested, not on all my machines, just the machines that that, I shut them off. I am not on anyone’s target list. I don’t run any kind of service that has tons of people in this system and it doesn’t often face the scary internet directly as it is going through a firewall that filters most of the scary traffic away. Making the change was really quite easy and underscores the beauty of YaST. To get to the right module, I go into YaST and select the Boot Loader module under System.
Within the bootloader module, select the Kernel Parameters tab and under the CPU Mitigations, I selected the drop down and the Off option.
After selecting okay and rebooting the system I can’t say I noticed any major improvement to performance. I tested Auto vs Off and I couldn’t actually tell the difference in performance. There may be some improvement but either I am personally too slow or nothing I do on a regular basis is affected by the mitigations.
Final Thoughts
For “desktop” machines, I am pretty confident that the other security features of Linux is quite adequate to keeping you safe on the Scary Internet. This desktop machine doesn’t provide any services to anyone outside of me as I am using it. I don’t have an Internet facing web service or database that has a risk in being compromised by bad actors.
For my personal server, that really doesn’t do a lot, I am keeping the mitigations to Auto. Although it does not face the internet, it is on all the time, I am not asking too much of it and it has a great chance at getting poked by something. Though, since I am not a target, the chances of that machine being compromised is also rather slim.
Your situation is dependent on your level of paranoia. Crank up your mitigations to 11 if you think it is best. As for this particular machine and the other little laptops and netbooks I use, I don’t see it as necessary.
References
SUSE.com Centralized CPU issue Mitigation document
Red Robbo’s Workshop YouTube Video: Improve Intel CPU performance on openSUSE
CubicleNate.com Spectre and Meltdown Vulnerability Status
TID 7022512 – Security Vulnerability: “Meltdown” and “Spectre” side channel attacks against CPUs with speculative execution.
TID 7022937 – Security Vulnerability: Spectre Variant 4 (Speculative Store Bypass) aka CVE-2018-3639.
TID 7023075 – Security Vulnerability: Spectre side channel attack “Bounds Check Bypass Store” aka CVE-2018-3693.
TID 7023076 – Security Vulnerability: Spectre side channel attack “Lazy FPU Save/Restore” aka CVE-2018-3665.
TID 7023077 – Security Vulnerability: “L1 Terminal Fault” (L1TF) aka CVE-2018-3615, CVE-2018-3620 & CVE-2018-3646.
