8 ms·

Long-Term Consequences of Spectre and Its Mitigations

136 points by sankha93 9y ago

fulafel 9y ago
Does anyone know how things are going in GPU land? Don't they support concurrent separate protection domains these days too?
- deepnotderp 9y ago
  No OoO speculation though.
andreiw 9y ago
One thing curiously missing from this article is ARM’s laudable in-depth analysis - https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update, and their efforts (https://developer.arm.com/support/security-update/compiler-support-for-mitigations https://developer.arm.com/support/security-update/compiler-s...) to bring in architecture-neutral compiler intrinsics to address variant 1.
- roca 9y ago
  Perhaps I probably should have mentioned that, but I think the array index masking approaches are going to prevail.
  - andreiw 9y ago
    That’s assuming the only thing you want to prevent is speculative bounds overrun. Even with masking, you can still leak the secret in the array from the path not taken? Do you see evidence of gcc or clang gravitating to the MS approach? 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.
mwcampbell 9y ago
> I think it would be a grave mistake to simply give up on mixing code with different trust labels in the same address space. Apart from having to redesign lot of software, that would set a hard lower bound on the cost of transitioning between trust zones. It would be much better if hardware mitigations can be designed to be usable within a single address space. 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-accessibility-on-windows/ https://www.marcozehe.de/2017/09/29/rethinking-web-accessibi...
- candiodari 9y ago
  According to a blind friend of mine, the web, despite the constant touting of it as being great for accessibility, has been a total disaster for accessibility. As you point out, windows applications have much better accessibility (and Microsoft still cares) than most webpages.
  - mwcampbell 9y ago
    I'm not surprised by your friend's observations, but that's rather beside the point of my comment. I was simply giving one example I know of a case where redesigning a system to work efficiently across address space boundaries is difficult. I'm curious about other examples, particularly in mainstream applications.
  - dotancohen 9y ago
    The Web is great for accessibility in the traditional sense of the word. Information is accessible. The HCI sense of accessibility is completely dependent on the Web page authors. The hoards and hoards of them, who are using a technology that was specifically designed to be used by people with no training in the medium.
Animats 9y ago
The article is by someone with no involvement in the CPU business. We need to hear from CPU architects and manufacturers. This is a fundamental CPU design defect and needs to be fixed in silicon.
- flukus 9y ago
  All you'll get from manufacturers is PR speak, most qualified CPU architects would also not be able to speak publicly due to corporate media policies.
- roca 9y ago
  Intel has spoken, and for Spectre variant 1 they have said we need to fix it in software (they recommend inserting fences "in appropriate places"). https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...
- cm2187 9y ago
  Fixing it in silicon will do nothing to the hundreds of millions of machines that are already deployed and many for as long as ten years (particularly servers).
- fyi1183 9y ago
  I'm not a CPU architect, and I'd agree with you that Spectre variant 2 should be fixed by CPU designs, simply because software is helpless against it. Luckily, fixing it shouldn't be too expensive, it just requires tagging the BTB with the trust zone. 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.
mehrdadn 9y ago
Could someone please explain to me why there is so much focus on Spectre vulnerabilities in Javascript and not really any on HTML/CSS, when it seems that a server could also be able to cause the client to perform speculative execution via pure HTML? Or is it not possible for some reason? The focus on Javascript as though it's somehow special is rather baffling to me, making me wonder whether I'm really understanding the fundamental issues. (?)
- gaius 9y ago
  Because JS is JIT compiled in a way that HTML isn’t - you can guess what machine instructions a+1 will compile into, its not so clear how a table layout say, will actually execute
- Sir_Substance 9y ago
  >The focus on Javascript as though it's somehow special is rather baffling to me 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.
  - dhimes 9y ago
    This is so annoyingly true. So when you start to allows scripts because you need the website to work, you reload and then see a bunch of new scripts were loaded that you didn't see before. It's a total shitshow. 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.
- IshKebab 9y ago
brndnmtthws 9y ago
I doubt Intel will be lowering their prices, or refunding anyone a portion of the price of their previously purchased CPUs, that's for sure. 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.
- acranox 9y ago
  Volkswagen deliberately engineered their cars to falsify government emission tests. What intel did was negligent. Volkswagen was malicious. These are very different. I don’t see them in remotely the same boat.
  - AnimalMuppet 9y ago
    "Negligent" is even too strong. 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.
- jacobush 9y ago
  But haven't there been references thrown around that show they knew at least a couple of years and could also have known for 10 years, if there weren't busy not understanding what their bottom line depended upon them not understanding.
faragon 9y ago
In my opinion, the worst long-term consequence will be that even having newer CPUs with the issues fixed in hardware, we'll have a performance impact because of code compiled to work with both old and new CPUs. Just like the case of having a new CPU with fancy features unused because of code compiled to be backwards compatible.
- josefx 9y ago
  Intels C compiler could generate code that detects CPU features at runtime years ago, I think the current GCC can do the same. Binaries only have to become a bit more bloated to store both versions of the compiled code.
  - faragon 9y ago
    Runtime checks cost CPU cycles as well.
    - em3rgent0rdr 9y ago
      The runtime check only needs to be done one during program execution.
      - faragon 9y ago
        So you mean having two executables in one? A la Apple "fat executables"?
        davidcuddeback 9y ago
        Probably something like a table of function pointers for "hot" code that gets setup at program start. But compiler writers are way more clever than I am at this sort of thing, so I'm actually curious what solutions they came up with.
        jabl 9y ago
        No, it's on a per-function basis. On program startup it does the necessary checks (CPUID etc.) and sets up the function pointers appropriately (see the IFUNC mechanism in the linker). See e.g. https://lwn.net/Articles/691932/ https://lwn.net/Articles/691932/
leoc 9y ago
Obligatory: https://millcomputing.com/topic/meltdown-and-spectre/ https://millcomputing.com/topic/meltdown-and-spectre/
moyix 9y ago
It's interesting to pair this with Adrian Sampson's (an academic who works on hardware architecture) thoughts, particularly his musings about other vectors: > 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. http://www.cs.cornell.edu/~asampson/blog/spectacular.html http://www.cs.cornell.edu/~asampson/blog/spectacular.html
phkahler 9y ago
>> browsers are trying to keep the problem manageable by making it difficult for JS to extract information from the timing channel (by limiting timer resolution and disabling features like SharedArrayBuffer that can be used to implement high-resolution timers), but this unfortunately limits the power of Web applications compared to native applications. 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.
- tomp 9y ago
  I consider any computer platform that cannot run an "untrusted" application in a manner that doesn't endanger its user (within certain limits - e.g. it's practically impossible to limit what kind of internet traffic the application can do, or what kind of scams it can make the user click through), a failed computer platform. 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).
  - taeric 9y ago
    This leaves a big hole. Many malicious packages will solicit trust from the user. 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.
- koheripbal 9y ago
  What happens when these issues are addressed at the hardware level. Are users on new chips going to continue to live with performance nerfs to protect those who haven't upgraded, or will patches and fixes detect some CPU feature that IDs it as a "fixed" CPU... of course spoofing that will have its own security implications.

136 points by sankha93 9y ago

Does anyone know how things are going in GPU land? Don't they support concurrent separate protection domains these days too?

deepnotderp 9y ago
No OoO speculation though.

andreiw 9y ago

One thing curiously missing from this article is ARM’s laudable in-depth analysis - https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update, and their efforts (https://developer.arm.com/support/security-update/compiler-support-for-mitigations https://developer.arm.com/support/security-update/compiler-s...) to bring in architecture-neutral compiler intrinsics to address variant 1.

roca 9y ago
Perhaps I probably should have mentioned that, but I think the array index masking approaches are going to prevail.
- andreiw 9y ago
  That’s assuming the only thing you want to prevent is speculative bounds overrun. Even with masking, you can still leak the secret in the array from the path not taken? Do you see evidence of gcc or clang gravitating to the MS approach? 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.

mwcampbell 9y ago

> I think it would be a grave mistake to simply give up on mixing code with different trust labels in the same address space. Apart from having to redesign lot of software, that would set a hard lower bound on the cost of transitioning between trust zones. It would be much better if hardware mitigations can be designed to be usable within a single address space. 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-accessibility-on-windows/ https://www.marcozehe.de/2017/09/29/rethinking-web-accessibi...

candiodari 9y ago
According to a blind friend of mine, the web, despite the constant touting of it as being great for accessibility, has been a total disaster for accessibility. As you point out, windows applications have much better accessibility (and Microsoft still cares) than most webpages.
- mwcampbell 9y ago
  I'm not surprised by your friend's observations, but that's rather beside the point of my comment. I was simply giving one example I know of a case where redesigning a system to work efficiently across address space boundaries is difficult. I'm curious about other examples, particularly in mainstream applications.
- dotancohen 9y ago
  The Web is great for accessibility in the traditional sense of the word. Information is accessible. The HCI sense of accessibility is completely dependent on the Web page authors. The hoards and hoards of them, who are using a technology that was specifically designed to be used by people with no training in the medium.

Animats 9y ago

The article is by someone with no involvement in the CPU business. We need to hear from CPU architects and manufacturers. This is a fundamental CPU design defect and needs to be fixed in silicon.

flukus 9y ago
All you'll get from manufacturers is PR speak, most qualified CPU architects would also not be able to speak publicly due to corporate media policies.
roca 9y ago
Intel has spoken, and for Spectre variant 1 they have said we need to fix it in software (they recommend inserting fences "in appropriate places"). https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf https://newsroom.intel.com/wp-content/uploads/sites/11/2018/...
cm2187 9y ago
Fixing it in silicon will do nothing to the hundreds of millions of machines that are already deployed and many for as long as ten years (particularly servers).
fyi1183 9y ago
I'm not a CPU architect, and I'd agree with you that Spectre variant 2 should be fixed by CPU designs, simply because software is helpless against it. Luckily, fixing it shouldn't be too expensive, it just requires tagging the BTB with the trust zone. 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.

mehrdadn 9y ago

Could someone please explain to me why there is so much focus on Spectre vulnerabilities in Javascript and not really any on HTML/CSS, when it seems that a server could also be able to cause the client to perform speculative execution via pure HTML? Or is it not possible for some reason? The focus on Javascript as though it's somehow special is rather baffling to me, making me wonder whether I'm really understanding the fundamental issues. (?)

gaius 9y ago
Because JS is JIT compiled in a way that HTML isn’t - you can guess what machine instructions a+1 will compile into, its not so clear how a table layout say, will actually execute
Sir_Substance 9y ago
>The focus on Javascript as though it's somehow special is rather baffling to me 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.
- dhimes 9y ago
  This is so annoyingly true. So when you start to allows scripts because you need the website to work, you reload and then see a bunch of new scripts were loaded that you didn't see before. It's a total shitshow. 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.
IshKebab 9y ago

brndnmtthws 9y ago

I doubt Intel will be lowering their prices, or refunding anyone a portion of the price of their previously purchased CPUs, that's for sure. 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.

acranox 9y ago
Volkswagen deliberately engineered their cars to falsify government emission tests. What intel did was negligent. Volkswagen was malicious. These are very different. I don’t see them in remotely the same boat.
- AnimalMuppet 9y ago
  "Negligent" is even too strong. 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.
jacobush 9y ago
But haven't there been references thrown around that show they knew at least a couple of years and could also have known for 10 years, if there weren't busy not understanding what their bottom line depended upon them not understanding.

faragon 9y ago

In my opinion, the worst long-term consequence will be that even having newer CPUs with the issues fixed in hardware, we'll have a performance impact because of code compiled to work with both old and new CPUs. Just like the case of having a new CPU with fancy features unused because of code compiled to be backwards compatible.

josefx 9y ago
Intels C compiler could generate code that detects CPU features at runtime years ago, I think the current GCC can do the same. Binaries only have to become a bit more bloated to store both versions of the compiled code.
- faragon 9y ago
  Runtime checks cost CPU cycles as well.
  - em3rgent0rdr 9y ago
    The runtime check only needs to be done one during program execution.
    - faragon 9y ago
      So you mean having two executables in one? A la Apple "fat executables"?
      - davidcuddeback 9y ago
        Probably something like a table of function pointers for "hot" code that gets setup at program start. But compiler writers are way more clever than I am at this sort of thing, so I'm actually curious what solutions they came up with.
      - jabl 9y ago
        No, it's on a per-function basis. On program startup it does the necessary checks (CPUID etc.) and sets up the function pointers appropriately (see the IFUNC mechanism in the linker). See e.g. https://lwn.net/Articles/691932/ https://lwn.net/Articles/691932/

leoc 9y ago

Obligatory: https://millcomputing.com/topic/meltdown-and-spectre/ https://millcomputing.com/topic/meltdown-and-spectre/

moyix 9y ago

It's interesting to pair this with Adrian Sampson's (an academic who works on hardware architecture) thoughts, particularly his musings about other vectors: > 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. http://www.cs.cornell.edu/~asampson/blog/spectacular.html http://www.cs.cornell.edu/~asampson/blog/spectacular.html

phkahler 9y ago

>> browsers are trying to keep the problem manageable by making it difficult for JS to extract information from the timing channel (by limiting timer resolution and disabling features like SharedArrayBuffer that can be used to implement high-resolution timers), but this unfortunately limits the power of Web applications compared to native applications. 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.

tomp 9y ago
I consider any computer platform that cannot run an "untrusted" application in a manner that doesn't endanger its user (within certain limits - e.g. it's practically impossible to limit what kind of internet traffic the application can do, or what kind of scams it can make the user click through), a failed computer platform. 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).
- taeric 9y ago
  This leaves a big hole. Many malicious packages will solicit trust from the user. 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.
koheripbal 9y ago
What happens when these issues are addressed at the hardware level. Are users on new chips going to continue to live with performance nerfs to protect those who haven't upgraded, or will patches and fixes detect some CPU feature that IDs it as a "fixed" CPU... of course spoofing that will have its own security implications.