Long-Term Consequences of Spectre and Its Mitigations
robert.ocallahan.org
robert.ocallahan.org
I wonder what software redesigns he has in mind. As far as I can tell, best practices are already trending toward only one trust zone per address space. Some might argue that that's the whole point of multiple address spaces. I suspect that Spectre will accelerate this trend.
I do know how difficult this kind of change can be. The example I have in mind started before Spectre, and is unique to one platform. On Windows, developers of third-party screen readers for the blind are going through a painful transition where they can no longer inject code into application processes in order to make numerous accessibility API calls with low overhead. This change particularly impacts the way screen readers have been making web pages accessible since 1999. For the curious, here's a blog post on this subject: https://www.marcozehe.de/2017/09/29/rethinking-web-accessibi...
Mobile Safari's decision not to reflow the paragraphs when the user does the inverse of the pinch gesture ("zoom"?), which seems to have encouraged the makers of the other browsers to give less priority to reflow even though they did not completely give up on it; at large text sizes, that decision required the user to scroll horizontally left and right for every line of text;
Google's purchase of Blogger followed by its changing Blogger so it will not show the reader any text unless Javascript is enabled, which seems to have encouraged other sites to do the same; this made it impossible for me to continue to visit those sites in Lynx (a browser that ran inside a terminal window, but did not support Javascript);
HTML5 in general was a disaster for me. For example, at large text sizes, the elements that remain at a fixed position relative to the window regularly end up taking up most of the window's real estate, leaving little room for the text I want to read.
Clarification: those have been my frustrations when trying to read what is or easily could have been static content; this comment is not about web apps.
I have set my font size to 32pt and do not allow web sites to use smaller fonts or typefaces other than my preferred one. Also, I have set text color to green on black, which is easiest to read for me. You would not believe how many web sites do change background color, but do not set text color, leaving me with bright-green on white text. :/
Then, a large font causes components to overlap, rendering text and buttons inaccessible. Disabling style sheets does not always help, either (and turns every modern web site into a complete mess). Semantic web? LOL.
Javascript, as others mentioned, is a huge problem, because it somehow seems to be able to bypass my font and color settings. I have it turned off all the time now and just do not visit sites that require it. Well, more time for more interesting things! A silver lining in every cloud! :)
All these isolation changes are ostensibly for "security", but I suspect DRM is at least part of the motivation; corporations want to be able to silo content more and restrict the free flow thereof. To a user, a screenreader is a benevolent helper; to them, it's a malicious "attack", a way of extracting and consuming content that they may not want.
Source: I'm the dev who built the foundation for this transition in Gecko.
My argument, though, is that 10 is basically just getting started with how nested most div based layouts are. The new "grid" world is a bit of an improvement. Probably a large one, honestly.
In many ways, spectre is one more kind of attack on code that doesn’t properly separate validating untrusted input from acting on that input, except unlike overruns and TOCTOU races, this is microarchitectural.
But Spectre variant 1 is really a consequence of the CPU working correctly. For a large number of branches, perhaps most, we want loads to proceed during speculative execution. This is because the code accesess the same or closely related data on both sides of the branch, so priming the caches during speculation is very valuable even when the branch is mispredicted.
I remember reading a study of different binary search implementations which is probably the clearest example of this: when the data is laid out in a heap layout (with child nodes next to each other in an array) the branchy variant of the code performs better than the branchless variant due to this cache priming effect.
What CPU designers could and should probably help with is providing instructions to cheaply mark the (comparatively few!) cases where this speculative execution behaviour leaks secret information.
How can we, as software developers, find these cases in our multi-megabyte code bases, and how can we be sure we haven't missed any?
For example, if you're paranoid, make your compiler be conservative, in the same way that you might address buffer overflows by using a language/compiler that inserts bounds checks everywhere.
If you're less paranoid and/or more worried about performance, invest in static analysis tools or languages with augmented type systems. After all, you only have to worry about Spectre variant 1 when handling attacker-controlled data. Tracking type info like this is already done by existing static analysis tools.
Finally, if you're not handling attacker-controlled data at all - which is the case for a lot of performance-sensitive code - you really don't want to (and don't have to) do anything about Spectre variant 1.
By the way, this is really the big difference between the two Spectre variants, and why it's a shame that they fall under the same name. Variant 2 affects all code with indirect jumps/calls, even code that doesn't ever touch attacker-controlled data. That's a huge difference between the variants.
Anyway, the bottom line is that you shouldn't punish the performance of all code over a class of security bugs that a lot of code isn't affected by. Buffer overflows haven't stopped us and shouldn't stop us from writing performance sensitive but security uncritical code in unsafe languages either.
No. the problem here is that the code isn't wrong. The CPU is wrong. Whether or not the CPU will leak data depends on the make and model of CPU. Most MIPS CPUs and many ARM CPUs don't have this problem. Some AMD x86-type CPUs may not. It has to be fixed on the CPU side.
This could introduce Intel to a world auto manufacturers know well - recalls. Intel has been there before, with the floating point bug.
Look: When other side channel leaks were found, e.g. people recovering RSA or AES keys from plain cache timing without speculative execution, maybe there were people similarly arguing that it's the CPU's fault. They lost that fight, too. Today, the uncontested consensus is that cache timing leaks are the code's fault, for good reason.
Because what are you going to do, stop building caches? Obviously not, they exist for very good reasons. The same is true for speculative execution. What do you expect CPU people to do? Rip that out entirely? Be real. (Please, seriously think about that: what is it that you actually want CPU people to do? Don't just handwave!)
This kind of discussion is why Linus Torvalds regularly flames security people.
I don't see a problem with that. "Web applications" are inherently untrusted code. If it were not for untrusted code these attacks would not be an issue, so it doesn't seem unfair for a mitigation to negatively affect them.
In particular, browsers could always run JS in a separate process that's appropriately virtualized (i.e. has limited access to host information and resources).
That is, we seem to be plagued by misplaced trust moreso than untrusted applications.
The analogy to civil engineering is we trust building makers. Few of us enter buildings we don't trust to stay up around us.
> The second thing is that it’s not just about speculation. We now live in a world with side channels in microarchitectures that leave no real trace in the machine’s architectural state. There is already work on leaks through prefetching, where someone learns about your activity by observing how it affected a reverse-engineered prefetcher. You can imagine similar attacks on TLB state, store buffer coalescing, coherence protocols, or even replacement policies. Suddenly, the SMT side channel doesn’t look so bad.
One of the most common ways major ad networks get compromised to the extent that they serve malware to hundreds of thousands of web users (this happens at least once a year) is that they hotlink to JS libraries, that hotlink to JS libraries, that hotlink to more JS libraries.
If you use a script blocker, it's not that uncommon to see that once you get down far enough, scripts are being loaded from bare IP addresses rather than domain names. Every now and again, someone compromises one of these deep-nested hotlinked JS files and maliciously modifies the javascript, and random sites all over the web dutifully serve the malware.
It's not that I don't trust the first-party website owners, more like I don't trust their friends friends friend.
EDIT: I would love a list of minimum required scripts for certain sites. It's painful to fight through what I need- and I really resent it when I am a PAYING FUCKING CUSTOMER.
"Decompressors, especially in HTTP(S) stacks. Data decompression inherently involves a large number of steps of "look up X in a table to get the length of a symbol, then adjust pointers and perform more memory accesses" — exactly the sort of behaviour which can leak information via cache side channels if a branch mispredict results in X being speculatively looked up in the wrong table. Add attacker-controlled inputs to HTTP stacks and the fact that services speaking HTTP are often required to perform request authentication and/or include TLS stacks, and you have all the conditions needed for sensitive information to be leaked."
[1] http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-...
See e.g. https://lwn.net/Articles/691932/
Look what happened after the VW diesel scandal ('dieselgate'): VW had to pay for repairs, and pay buyers (my friend bought one of the cars and got about $6k IIRC). Some people even went to jail.
Intel (or any other CPU maker) will probably not suffer similar fates. This situation is a bit different, because they may not have known about the problem. Still, everyone who bought a CPU is going to get a 10-30% performance haircut because they made a mistake. And Intel isn't going to have to pay for it.
Per dictionary.com, the legal definition of negligence is "the failure to exercise that degree of care that, in the circumstances, the law requires for the protection of other persons or those interests of other persons that may be injuriously affected by the want of such care. "
What Intel did was not recognize that a specific attack possibility existed. Nobody else recognized it either, for a decade. That's not negligence. That's failure to be omniscient.