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.
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.
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!
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.
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.
Like, "oh shit grandpa is doing an elevation attack on the family computer again".