there is nospectre_v1 and nospectre_v2 written in there, unless you've been living under a rock you should get a pretty good idea that this is not a very safe thing to do.
yeah it looks great for air-gapped machines or if you've disabled the tcp/ip stack in the menuconfig AND can guarantee that nobody else ever has physical access to your machine
You run a Hadoop/Spark cluster on-prem. It's isolated from the rest of the world. If foreign code is executing there, the game is already up. You turn `mitigations=off`.
Are you Jeff Bezos, Bill Gates, Tim Cook or other high profile billionaire or head of state target or work for such a target? If yes, do not do what the site says.
If not, it doesn't affect you.
Such security measures take into account possibility, but usually ignore probability.
I don't think I agree. Instead, I'd rephrase: "Do you ever use your web browser on this computer to go to less-than-trustworthy sites? Ones that use ad networks or load a cryptominer? Then you may not want to turn these on."
The risk for most individuals isn't that they'll be held ransom, rather their property will be abused and they'll have to repair it.
What do you believe is going to happen if you visit a less-than-trustworthy site? For a drive-by exploit to work (assuming there is one, just because a site is "shady" it doesn't mean it will be 100% sure that it will try to infect your computer with something) it will need to make a TON of assumptions about your setup and chances are (here again the probability that security types ignore) you wont be affected.
And really those issues should be solved at the browser level not the OS level level that affects every single application that runs on it. And AFAIK they already are.
I do not want my compiler or game or renderer or whatever else to certainly become slower just because someone may visit a site that may have an infected ad that may match an exploit their browser may have and may manage to extract some information that may be useful for whoever wrote the exploit (assuming they even manage to get that info back).
Also a cryptominer will only work for as long as you have the site open, of all the things that could go wrong, this is the most benign one.
> And really those issues should be solved at the browser level not the OS level level that affects every single application that runs on it.
They aren't -- this is exploitable in the browser if not patched at the OS level.
> For a drive-by exploit to work (assuming there is one, just because a site is "shady" it doesn't mean it will be 100% sure that it will try to infect your computer with something) it will need to make a TON of assumptions about your setup
If you run these on an ad network, you get access to millions of different setups - you don't need to make any assumptions, you're virtually guaranteed to find someone with a vulnerable setup.
Yes, but the chances are very low that the someone is you if you're using a recent browser version (I'd say not cutting edge, but recent). Probably far, far lower if you use uBO or similar. On Linux, at home, they're probably infinitesimal unless you're being targeted.
Mostly FUD. It's not really exploitable in a practical real world sense. Show me the exploit that can read my password or SSH key, and not some fixed set of data that's been staged by the PoC.
The problem is, without using all mitigation, at all times you /may/ have been exploited. So every time your system acts weird, you'll have that extra doubt. And can it can be pretty difficult to get remove a sophisticated exploit. I could see a sophisticated exploit network probing, tagging and targeting different exploits, for profit or just for fun. Probably not worth the risk for "most" people.
Are there any live exploits detected for Meltdown or Spectre? When talking about these vulnerabilities people seem to forget that these are pretty costly attacks: complex, slow (iirc at most you can read memory at 5kB/s) and require targeting to specific memory locations/software/etc. Why would an ad network or a cryptominer invest in such an attack when "Click here to download more RAM" still works?
There aren’t even POCs that work on modern browsers. These things are real on the cloud server level but it’s exploitability on the desktop/laptop level is over stated. Much easier vectors.
There's a lot of FUD going on. You're correct in that _many_ speculative execution attacks in general are very difficult to exploit in a useful way. I.e. things like timing side-channels using shared TLDs or in a hyper-threaded core.
The Meltdown attack (also a speculative execution attack) is a much bigger deal - it's easy to exploit, and an attacker could basically read arbitrary memory on your system. It is easier to mitigate, too, with KPTI. Before KPTI, your OS kept the full set of kernel page tables mapped when user processes are running, the contents of which could be exfiltrated using the speculative execution side-channel.
AMD processors (and I believe newer Intel processors) are basically immune to Meltdown, so it may be safe for you to turn off KPTI for a (minor) performance boost. Having said that, newer CPU TLBs have process-context IDs that let the OS make up for some of the performance impact, so you might not notice a difference at all.
The original "Spectre" attack (name in the whitepaper - not to be confused with the greater class of Spectre attacks) allowed out-of-bounds memory access within a process' address space via speculative execution. So, if your browser was running in a single process, then some Javascript could read other browser memory containing things like passwords, keys, etc. If your browser is running scripts or pages in their own sandboxed process, then the risk is pretty low.
Any Spectre mitigations performed by the kernel are not going to be a silver bullet, anyhow. These are _mitigations_, not "magic Spectre attack prevention" features. Unless out-of-order execution (or caches!) is eliminated entirely, speculative execution attacks are going to be a threat. (Interestingly, Itanium CPUs and it's VLIW architecture appears to be immune to these attacks.)
Even compiling your software with Spectre mitigations turned on (available in MSVC, not sure if GCC has implemented it yet) doesn't do a whole lot of magic - it will insert a serializing instruction (LFENCE on x86-64) to clear out the pipeline during certain loop-branch combinations, ensuring that a speculative read can't occur before the outcome of the branch is decided.
Any time there are shared resources between processes, CPUs, computers, datacenters, etc. there is a side-channel - period. What can be leaked via this side-channel, how noisy the side-channel is, what the rate of data exfiltration is, these are things under our control, but eliminating side-channels entirely is a fool's errand.
So, would I risk turning off the Spectre mitigations? I'll put it this way: I'd worry about the Spectre kernel flags after I had a Linux antivirus program installed, and turned on and tightened up my AppArmor or SELinux configs.
I'm sure many of the people crying out against the crime of disabling Spectre mitigations haven't done that yet (just like I haven't) - because it's a PITA! So, if you disable the mitigations and decide the performance increase is worth the risk, I wouldn't fault you for it.
The whole reason these exploits exist in the first place is because the CPU performance increases available with speculative execution, out-of-order execution, deep CPU pipelines was worth the risk (to their reputation, at least). I don't see a lot of people going back to buy Itaniums because they're worried about Spectre attacks.
Now - would I turn off KPTI? On an AMD CPU, sure. On Intel (unless you've double checked, the CPU was produced in the last couple of years, and it's immune to Meltdown) - ABSOLUTELY NOT!
Well, if you have an idea what to do with the undocumented string returned by the site, maybe you also have an idea of what effects it might have, beyond making linux fast again?
> You are (probably) an adult. You can and should wisely decide just
how much risk you are willing to take. Do or don't try this at home.
You do not want to try this at work.
> As the above charts show: The effect of default parameters vs
mitigations=off is measurable but not hugely impressive. (…)
> You can and should wisely decide just how much risk you are willing to take
That requires informed consent. But we can see that people are not well informed: many don't realize that a web broswer or an attacker accessible network stack are attack vectors.
I've been using these options for a while (well, mitigations=off is new to me)... on dedicated rendering computers that are on a port isolated network inaccessible to the internet and without the ability to make outgoing connections at all.
That's probably (I hope?) a reasonable usecase for these settings... but not exactly a super common one.
I'm truly shocked by the comments I'm seeing here. When did so many people forget everything we've learned about security? You know what a zero-day attack is right? You know how fast those can cover the whole internet these days right? So why would you purposely leave a gaping security hole in your system to get some performance on a CPU that's probably too fast for your realistic workload already?
These academic PoCs read data that they themselves have staged during execution. This is very different from reading arbitrary, random memory that contains something like a cookie for another web site, password, or SSH key. When someone is looking for a real world exploit, this is what they want.
