Disappointed I didn't see fairly reasonable explanations around processor security bugs which impact broad system performance such as Spectre and Meltdown.
> What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware.
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.
An alternative interpretation is that there are no current "performance hits", just the legitimate performance is now (better) known. Those former "performance gains" were cheated, akin to Volkswagen emissions tests.
It’s news to me that Intel, AMD, and various ARM licensees all knew about these problems (and vague “the ~truth~ side channels are out there” handwaves that were made for many years don’t count) when the requisite speculation changes were made 20 years ago and left them in anyway. And that still isn’t quite an equivalence to the Volvo emission tests, since the processors don’t try to detect if you’re testing them and change behavior.
It's my understanding that the bulk of the vulnerabilities in question are not present to near the degree on AMD and ARM. If AMD and ARM could do things mostly properly, why couldn't Intel?
There are a number of the vulnerabilities that affect other platforms than Intel x86 (including some POWER and ARM), though you're correct, a good amount of those disclosed are specific to Intel. But there has also been at least one that was AMD specific, too.[1]
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.
Or simply none of them were aware that the kinds of speculation they were doing were capable of producing exploitable vulnerabilities. It took security researchers a long time to find these issues, and the kind of speculation that the original Spectre and Meltdown exploited were well known outside of the chipmakers for over a decade. Intel was simply more aggressive at that particular avenue of performance improvement.
No. Isolation has always been a security feature, not a reliability feature.
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.
> 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
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...
Yes, I 100% disagree with Stallman's goofy conflation of OS permissions segmentation with aristocracies, and think the idea that the permissions model of the early 1980s is at all workable in the internet era is profoundly, stunningly naive.
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.
> but what we're talking about is allowing every VSCode extension and Docker image someone installs to read your GMail.
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.
C’mon. Ability to read the cache is obviously a much much lower threat than the ability to read the browser processes’ memory – the browser doesn’t cache your GMail password.
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:
Isolation (Rings) was first implemented in Multics (first in software, then in hardware..a bit like today (user-mode and kernel/hypervisor mode)), foremost for security second for stability.
didn't immediately see the answer in a quick google.
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.
Just searched "emissions cheating" and uh, is like, every auto maker cheating on emissions? I remember the VW scandal, but this quick search leaves me to conclude that VW is only the most memorable one that got mass media attention of late.
But hey, we love our corporate overlords, they only want what's best for us, the shareholders.
> Just searched "emissions cheating" and uh, is like, every auto maker cheating on emissions?
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.
What I find most disappointing is that even processors manufactured TODAY contain these flaws and have performance hits put into the firmware.
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.
I've seen a research paper that talks about something called "DAWG" that is supposed to preserve speculative execution while mitigating timing attacks. With some performance hit, but less than what we have today. The graphs in the paper seem to suggest a hit of 10% or less.
Not my area of expertise, so no idea how promising it is.
The Spectre/Meltdown issues are fundamental and "difficult" to fix - but mostly exist because we can observe state using very fine grained performance counters. Why not disable (or dumb down) the performance counters, and leave the bugs and better performance in place?
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.
An incredibly low probability multiplied by ~billion+ users means somebody is going to lose something valuable sooner or later. And then the odds of MS getting sued for “not even patching a well-known vulnerability” becomes 100%.
But that's also a billion+ users with much slower computers! So you need to compare the harm on both sides.
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.)
Think of the average windows user. This person uses Chrome because they got a popup when they went to Gmail. The shortcut for candy crush is still in their start menu because it doesn't bother anything. I am not being insulting -- this is the average, median windows user. This is the person for whom Windows Home is designed. There is ZERO CHANCE that this user knows what a "speculative execution mitigation" is. There is a nonzero chance some cleaner site will tell them to turn it off because it "makes windows faster". They don't understand it can be executed from a website because they don't think of websites as programs because they don't have an icon on the desktop. There is no way this turns out well.
Yes, so Microsoft has to make the decision for them. I'm not sure "we're going to make your computer 30% slower because there's a 0.0001% chance someone could steal your password" is the right decision.
(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.)
An unpatched data exfil against the OS with the largest install base in the world? It doesn't matter it's a byte at a time, cryptominers have done more with less. The question isn't if, the question is who and how many. The fallout from SMB2 is still ongoing, and it was patched 10 years ago. The idea of not patching EVER opens up harms for the next twenty years for everyone.
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.
What is the chance that this user has unbacked up data that someone could extort them for $500. Multiply this chance by the proportion who would enable a "go faster" option and then by 1.5 billion computers.
Let us say 20% and 25% * 1.5B. Maybe 75M targets give or take depending on how you want to do the math.
> But that's also a billion+ users with much slower computers! So you need to compare the harm on both sides.
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.
There's already third party tools (0) to disable those mitigations in windows. I suspect the small barrier to entry of needing to use a search engine is enough to keep the risk minimized to the general population. Hopefully only people who are knowledgeable of and willing to accept the risk use this.
If you could trivially enable a "go much faster" setting in the gui that would in turn make you much more vulnerable you would see people sharing on facebook how they found the secret go faster option and 1/4 of machines would have this setting enabled rendering exploiting it much more profitable and you would see attacks become widespread after which people would ask why windows came with a suicide switch. This issue comes to a head when somewhere some important company or 3 is attacked via possibly poorly managed employee laptops enabling this feature after when the gui option is deleted. Then someone can have the same 5 years later after people have forgotten about the first go round.
I’m not suggesting Microsoft does this intentionally to push consumers to buy new computers because that is obviously not the primary motivator for the mitigation patches, but I’m sure they don’t mind.
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.
Spectre and meltdown aren’t often used because of the mitigations in modern operating systems. The attacks are complex and the chance of finding a vulnerable machine is low. But if instead windows users were all vulnerable, you bet all sorts of scammy websites would go after these vulnerabilities.
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.
> And the attacks are really bad - they can read arbitrary memory.
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.
The term “Random memory access” is a horribly confusing misnomer from before I was born. It’s used as a contrast with sequential memory access, to mean memory can be accessed in any arbitrary order.
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.
Until there's an actual documented in the wild attacks against individuals, I see zero reason to enable these crippling security measures on my home desktop.
It's very unclear to me how much of a performance hit there is for most desktop use-cases.
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.
> I use is a desktop i5-8500 which doesn't feel faster than my older i7-3930k
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.
That was my first thought. I remember reading an article before Spectre was patched, that it could slow down the speed by ~5%? I never checked back in on it.
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...