This issue is so fundamental to how CPU caches work, that there really is not a true performance-neutral fix.
The first (private) disclosure of the Spectre vulnerabilities was sometime in mid-late 2017. Partial hardware mitigations launched in 2019 for some Spectre variants, where the mitigations could be easily patched in to already taped-out designs.
Beyond those easy wins, even if foundries weren’t slammed by COVID delays, I don’t think it’s realistic to expect that we’d be any further along? Most of these sidechannels require deep rethinks of the execution pipeline and speculation engines, and fundamentally redesigning those systems, taping out those designs, and finally manufacturing those chips was always going to be a process that was measured in the better part of a decade.
Edit: it was Volkswagen not Volvo.
I hypothesize it could have come down to "well, we made this type of decision this way before, and the world didn't fall down, so we can probably make it that way again, right?" Since these aren't formally proven systems, to some extent deciding whether an optimization is safe is going to be a judgment call - and if you go for "well, if this assumption is false, we're already doomed because we did X elsewhere...", the results could look like this.
Or maybe not, I've never worked for a chip design house.
why would cache performance be considered a cheat?
Consider that local privilege escalations are generally (and I'd say correctly) treated as critical severity issues. Any general purpose process memory read-isolation leak is a quick route to a local privilege escalation, so how could isolation be anything other than a security feature? In its absence, you might as well run everything as root and there would be no point whatsoever to caring about privilege escalations.
> In its absence, you might as well run everything as root
this is what 99% of people with a home computer did until windows XP (and even then most people today run under an admin account of some sorts on their computers)
isolation between users is only relevant for clusters, it's a super minority usecase versus what is the main thing that matters, home computers which only have one human user anyways. But I guess you'd disagree with Stallman's paragraph at the end here: https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_nod...
The XKCD argument misses the point entirely; if someone p0wns your browser, they p0wn your browser, but what we're talking about is allowing every VSCode extension and Docker image someone installs to read your GMail. It's an absolute dipshit idea that would make every current security problem with computing orders of magnitude worse.
I don't understand, this is already the status quo today. Any vscode extension can access your filesystem and connect to a socket, so it can just pipe your ~/.cache/mozilla to some server in russia, and even read the memory of any of your processes through /proc/$PID/maps. Ditto for any shell script you run, any build script for any software you clone from github before building it, unless you are running Qubes OS.
Also let’s stop here and admire just how far you’ve shifted the goal posts: we’ve gone from “memory isolation isn’t a security measure it’s actually just for reliability” to “ok sure it’s obviously a security critical measure, but check out this boneheaded RMS rant and also what about the lower threat value data that gets cached, what about that. And do we even need security or can we just go back to the 1980s with our Amigas when everything was cool and advanced persistent threats didn’t exist, man”.
Pick a coherent point you’re trying to argue and some kind of intelligible threat model, at least. If we’re concerned about leaking filesystem data, there’s more aggressive sandboxing measures which several OSes employ, but they even more strongly rely on memory isolation, not less.
The point, which you seem to have conceded several posts ago, remains: Memory isolation is a security measure, not just or even primarily a reliability issue.
Also you don’t seem to understand what you’re trying to talk about, because:
> and even read the memory of any of your processes through /proc/$PID/maps
This requires root permissions (or for you to have explicitly changed /proc/sys/kernel/yama/ptrace_scope to a non-default value to allow processes to PTRACE_ATTACH to arbitrary non-child processes, which you shouldn’t do on a general purpose internet-facing machine unless you are a clinically insane person) for the obvious reason that this would be incredibly dangerous otherwise. Proving once again my entire point:
Memory isolation is a security measure.
Whether happening organically or through the magic of reputation management, that's pretty alarming, actually. Give it another few years and nobody will even remember.
But hey, we love our corporate overlords, they only want what's best for us, the shareholders.
(Not actually a shareholder of anything)
More or less, yes, they all did.
As an European I'd say it's a shared blame, though, as in the officials around Europe (both at national and at the EU level) who had very strongly pushed for diesel for the previous two to three decades (mostly through taxation/pricing policies) also deserve a very big part of this blame.
The Americans got it right (especially states like California) when relegating diesel to mostly commercial/truck/public transport use, but the hybris and the "we know better than the silly Americans when it comes to the environment" prevailed in the end, that's why it took Dieselgate and at least a couple of decades for those officials to reverse their past mistakes.
Alternatively: if you don't care about timing side-channels (which is true in a lot of applications where the only code being run is trusted, such as with HPC clusters and the like), you can run at full performance, and if you do, you can load the microcode to increase the security at the expense of performance.
Not my area of expertise, so no idea how promising it is.
We could enable the counters (and the mask bugs and reduce performance) by normally-off a BIOS flag. I for one would rather have the performance and don't need the counters for day-to-day ops.
The chances of Spectre or Meltdown actually managing to acquire sensitive data seems incredibly low. Is that worth the very large performance impact?
And then MS could add a switch in Settings for anyone who is concerned. (I realize not many people would find it, but it seems important for the option to be accessible, without digging into the registry or some such.)
(These numbers are completely made up. Any decision would depend on getting the right numbers, but this appears to be easier said than done. I've seen very different estimates.)
This made me wanna cry. Jokes aside, there's much truth to this. Attack vectors at this scale are seriously dangerous.
I'm still hoping we can prevent the namewreck fallout of SCADA systems, because at one point or another, 8200 is gonna make a mistake with their offensive cybersec operations.
Let us say 20% and 25% * 1.5B. Maybe 75M targets give or take depending on how you want to do the math.
Far more likely Microsoft would be legally exposed due to a skipped patch than a patch that slows machines down. Intel on the other hand, that'd be more interesting.
> And then MS could add a switch in Settings for anyone who is concerned. (I realize not many people would find it, but it seems important for the option to be accessible, without digging into the registry or some such.)
Any such switch would just be disabled via GPOs by corporate security teams anyway, so what's the point? The entities who would most "benefit" wouldn't even be able to do it.
How about we just skip a step?
Also your average user isn’t going to know or understand even if you gave them the option somewhere. It just doesn’t make sense.
If you are knowledgeable enough to understand, then you can disable the mitigations. This seems like the best approach to me for everyone.
And the attacks are really bad - they can read arbitrary memory. What are the chances another browser tab has a bank website open with active auth cookies, or a valuable email account? Really really high.
But—and please tell me if I’m just totally wrong about this—my understanding was they can read random memory, right? The attacker can’t control what they get.
Out of the gigabytes of memory on a system, I’d expect only a handful of bytes to be actually valuable, and only then if certain combinations can be retrieved together.
My understanding is that these vulnerabilities allow reading the memory at arbitrary mapped pointers, from the perspective of the CPU, in kernel or user space. So you could use the kernel’s data structures to figure out what other programs are mapped, and where, and go read their memory.
My most recent CPU I use is a desktop i5-8500 which doesn't feel faster than my older i7-3930k aside from disk access [0], both of which are impacted by the vulnerabilities. I practically never use the i5.
Until recently my daily driver was a MacBook Pro that came out in 2013, and I don't really remember a before / after change in perceived performance or responsiveness – I haven't done any scientific benchmarks, but that computer never felt slow, and still doesn't.
There's also this Phoronix benchmark [1] that compares performance with and without `mitigations=off` on linux. There are some tests where there's a very big difference, but mostly, to me, it doesn't look that crazy.
In the Firefox benchmarks they do say that there's a big hit, but then I probably don't read the graphs correctly, nothing looks particularly worrisome to me.
---
[0] The i5 has some NVME as opposed to an older, regular SATA drive in the i7. Still, I run a lightweight Linux install on both, so drive speed is never an issue for me, everything can fit in RAM.
[1] https://www.phoronix.com/scan.php?page=article&item=spectre-...
I mean, looking at the specs on Intel ark that's to be expected, a newer generation mid-range CPU is typically the same speed as a high tier CPU of old.
Faster bus speeds, higher turbo, some newer under the hood instruction sets for SIMD, and if the datasheet is correct, for roughly half the thermal output thanks to a process shrink.
I have noticed that the latest update feels faster than all the other ones, but it's always hard to tell since that's the only time I really reboot the machine.
This has a significant impact on Linux and Microsoft has even outlined that these fixes impact their performance (there have been many more security bugs identified since): https://www.microsoft.com/security/blog/2018/01/09/understan...