▲ 90 points
back
17 comments
If you want prevent Meltdown and Spectre patches from slowing down Your PC, on Windows you can use the InSpectre tool: https://www.grc.com/inspectre.htm
On linux add the following boot parameter: pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
I saw a measurable decrease in build times in Linux. '$ time make' dropped nearly 10%.
Of course do not do this if you visit sketchy websites, install dodgy software, or open random attachment in email. That said, I can't find any evidence that any mass attack has been based on these exploits. <tin foil hat> Have a feeling our machines are made slower to make cloud providers safer or sell more CPUs.</tin foil hat>
Since it's just boot parameters on Linux, you could add an extra boot option to your grub.cfg (or whatever you use) that boots into 'insecure mode' and reboot whenever you want the extra performance.
I think it should be explicitly called out that meltdown is exploitable via JS, I wouldn't use 'insecure' mode for web browsing except on well known sites (e.g. docs.your-programming-language.org), and I would use an ad(malware)-blocker.
Fyi:
Compiled "mkvtoolnix" ( https://mkvtoolnix.download/ ) on Gentoo Linux twice, once without and then with the kernel options "pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier":
No kernel options:
merge time: 13 minutes and 38 seconds.
merge time: 13 minutes and 44 seconds.
merge time: 13 minutes and 5 seconds.
merge time: 13 minutes and 28 seconds.
Parallel compilation set to max 3 threads (" MAKEOPTS="-j3" ") but mkvtoolnix compilation seems to use most of the time max 2 threads.
gcc (Gentoo 8.2.0-r6 p1.7) 8.2.0
I guess that the 2nd rounds have higher runtimes than the 1st ones because the CPU got hotter... .
I'd say dont disable mitigations on systems not used for only trusted code. I'd do it on e.g. HPC or dedicated metal server nodes. I'd never disable it on a desktop or mixed tenancy node.
> If you want prevent Meltdown and Spectre patches from slowing down Your PC, on Windows you can use the InSpectre tool: https://www.grc.com/inspectre.htm
Yes, use the tool to get the actual patches...
> Protection from these two significant vulnerabilities requires updates to every system's hardware–its BIOS which reloads updated processor firmware–and its operating system–to use the new processor features.
> This InSpectre utility was designed to clarify every system's current situation so that appropriate measures can be taken to update the system's hardware and software for maximum security and performance.
If this tool had the secret fix that didn't impact performance in any way then wouldn't it have been incorporated everywhere?
My understanding is it shows you the current status of mitigations/patches and allows disabiling/enabiling them. Just my take on it YMMV.
Steve Gibson makes some fantastic stand-alone-simple-executable tools!!
The scariest thing for a cloud provider I'd imagine is a VM being able to read the cloud services login/key from an adjacent VM, then using that key to spawn more VMs that steal more keys and so on. Crypto mining allows the exploiter to directly translate that stolen compute into something valuable so there's a profit incentive to do so as well.
The cloud environment as a whole seems a lot more homogeneous, accessible, and easier to profit from than exploiting desktops.
I would expect cloud providers to easily detect crypto mining activity and to shut it down: https://www.reddit.com/r/MoneroMining/comments/9b31b7/how_to...
I would assume hardware and electric outlets that are not professionally supervised to be most vulnerable. If you find your way into some type of NAS, then you've probably found a homogeneous environment: https://www.computerworld.com/article/2490759/hacked-synolog...
Microsoft also released a similar powershell module:
https://www.windowscentral.com/how-check-if-your-pc-still-vu...
Note that this will not stop the slowdowns illustrated in this blog entry as those are associated not with any particular mitigations being enabled, but seem simply to occur always with the newest microcode versions.
I've got to somewhat agree with that. Meltdown and spectre were very serious, but were also branded and marketed specifically to be "viral". Also, web browsers, possibly the single biggest risk, were patched separately iirc.
Some, such as Google developers, have said these vulnerabilities can't be fixed in software: https://arstechnica.com/gadgets/2019/02/google-software-is-n...
And it's ridiculous to give credence to the idea that the people pushing software mitigations to Linux, and the maintainers merging them, are doing so in bad faith.
Bad faith is unlikely. Overzealous sacrificing of performance for nebulous gain in a large mount of use cases is, however, quite likely.
they were but i guarantee they were tested on systems with mitigations in place so who knows what the result is when ran on systems with the mitigations turned off.
that being said, i just disable javascript and only turn it on when i need to.
Did AMD ever release Spectre ucode updates for K10 processors? We've got a pretty good handle on the internal format of those and it'd be interesting to see exactly what changed.
Haha, that title reminds me of "Eddie, what have you done for me lately" from Eddie Murphy's "Raw"!