https://www.zdnet.com/article/google-this-spectre-proof-of-c...
Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.
Per-process Spectre mitigations could be helpful there, but I don't understand the technical details to know whether that would be possible to implement. It would be nice to disable mitigations on a video editor and for gaming.
If anything Spectre has shown us that the only real mitigation is to go back to multiprocessing with IPC, with the extra hardware resources it entails, as the exploit exists regardless of the language for in-process memory.
If you were do to do per process mitigation it would need to prevent certain process execution flows from happening, because the vulnerability is a problem with the CPU pulling memory from the way speculative execution works. This actually impacts things that are typically protected and is much more impactful than people think... for example, because the bug allows reading from nearly any memory address space, you could also pull in things like crypto keys from the OS or passwords from memory.
For example, a speculative execution vulnerability might exist when there is a string of data in memory that has a memcp pattern, with memory addresses that are valid. To speed up the execution of programs, the processor might proactively read the memory from that memcp pattern because it is sending a command to the memory controller already.
Many of the mitigation techniques are to flush the caches/buffers and be careful about memory reads, which are the precise things that actually take the performance hits. And one of the problems is since they are access patterns, the vulnerabilities can be the html renderer compiled with an application, an SVG rendering library or a mail client.
For example, lets say there are mitigations built into the JS library... if you build a specifically crafted SVG, you could create similar access patterns to get around it. Its a huge cat and mouse game if there aren't OS protections and it only takes a single app to lose your secrets stored in memory.
Now it is not possible for every kind of mitigations, because e.g. patching the kernel between mitigated processes and unmitigated ones would be more costly than just always running the mitigations.
edit: thinking more about it: you could have crazy ideas like two versions of the whole kernel space always loaded :D not sure about the cache impact in this case though.
The JavaScript argument is interesting to me in that it's already flawed. I suppose I'd rather focus on the security issues with browsers running code on my computer more than anything else since it's effectively the "but what about ___" answer to so many threads like this one.
I've seen a few other comments suggesting per-process rules to enable or disable branch protections. That's an interesting thought, especially considering you could apply it to either "trusted" or "untrusted" code depending on it's source.
Also, I wonder if disabling mitigations on the desktop and running the browser in a VM with mitigations enabled would be effective.
I don't know about the wild, but if this were tuned (i.e. this requires a lot of work for the first byte, the rest are easy) for a HVT you wouldn't know.
This is on Chromium 91.0.4472.106 and kernel 5.12.11-arch1-1. lscpu shows vulnerabilities:
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Spec store bypass: Vulnerable
Spectre v1: Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers
Spectre v2: Vulnerable, IBPB: disabled, STIBP: disabled
Srbds: Mitigation; TSX disabled
Tsx async abort: Not affectedTo use an analogy, these side-channel timing attacks are really a "looking for a needle in a haystack" (or heap...) situation, except that [1] you don't necessarily know what a needle looks like, and [2] the haystack is constantly changing. AFAIK all the PoCs shown so far relied on having a deep knowledge of the system and carefully constructed conditions.
If these attacks could undetectably dump all of your RAM in a few seconds, that would definitely be a huge concern. But they're more like being able to read a few bytes per second, from somewhere in the address space, with no idea what they are or where they're being read from, and no guarantee that they're even contiguous.
Good lord, I hope this is satire.
What they did do is move tabs to their own process so they can take average of the operating systems protections. Yes you can read the memory of the process hosting the JavaScript, but now there isn't anything interesting in it. Google's security team released a proof of concept attack that can read the memory in the renderer in many systems.
(Just to be clear, I'm perfectly happy with the performance of my old-ish machine, so I have no motivation to disable those mitigations.)