6 ms·

Well, that's true (at least for the spectre attack). It's not a bug in Intel products. It's a bug in any CPU that uses branch prediction (please correct me if I

Well, that's true (at least for the spectre attack). It's not a bug in Intel products. It's a bug in any CPU that uses branch prediction (please correct me if I'm wrong, this is my current understanding)

bad_alloc 9y ago
IF the bug is present in all processors that use speculative execution AND Intel products use speculative execution THEN it is a bug in Intel products. It would only be correct to say "This is not a bug or a flaw exclusive to Intel products"
betterunix2 9y ago
The effect on Intel is far more severe than on other architectures. There were three vulnerabilities, two grouped together as "spectre" and one called "meltdown." Intel products are uniquely vulnerable to the meltdown attack, while many CPUs are vulnerable to spectre. The summary AFAIUI is that for most CPUs you can attack userspace processes with these techniques (think Javascript running in a browser), while for Intel CPUs you can also attack the kernel. Intel CPUs also seem to be somewhat easier to attack than others because of a higher-bandwidth side channel.
- Symmetry 9y ago
  A minor correction, ARM's upcoming A75 core looks like it will be vulnerable to Meltdown too. But since it isn't intended for use on server workloads the performance impact of the fix shouldn't be very significant.
- bzbarsky 9y ago
  > Intel products are uniquely vulnerable to the meltdown attack More precisely, there is only a PoC for Intel at this time. AMD processors are believed to not be vulnerable. Some ARM processors _are_ believed to be vulnerable. > for most CPUs you can attack userspace processes with these techniques Spectre can attack the kernel as well, at least according to http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html http://www.tomshardware.com/news/meltdown-spectre-exploits-i... . It's just harder to use than meltdown.
  - arohner 9y ago
    That link no longer loads for me. AIUI, Spectre can be used to attack the kernel, only if you can get code running in kernel-space, via, e.g. eBPF.
    - contrarian_ 9y ago
      No, you could also find a gadget with ROP techniques. The eBPF thing in the paper was purely due to convenience of exploitation.
    - bzbarsky 9y ago
      > That link no longer loads for me. Oh, right, ycombinator's URL parser is broken. I fixed the link to work around the buggy parser....
    - elihu 9y ago
      I think that's almost but not quite exactly right. Spectre variant 2 attacks vulnerable indirect jump code patterns that exist in the kernel (or some other process), but doesn't require running the attacker's code. Spectre variant 1 allows you to infer the contents of memory in the same address space, so that's the one where you'd use eBPF to attack the kernel. Meltdown (variant 3) if I understand correctly can infer memory contents of other address spaces without relying on any assumptions about the code running in the other address space. https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html https://security.googleblog.com/2018/01/more-details-about-m...
  - swsieber 9y ago
    I'm curious about AMD not being vulnerable, mostly because this page: https://www.kb.cert.org/vuls/id/584653 https://www.kb.cert.org/vuls/id/584653 makes me think that AMD has admitted to being vulnerable.
    - bzbarsky 9y ago
      That page talks about both Meltdown and Spectre, as far as I can tell. AMD is vulnerable to Spectre; everyone agrees on that. According to https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution AMD claims it's not vulnerable to Meltdown (aka "Variant Three").
- cma 9y ago
  "(at least for the spectre attack)"
- swsieber 9y ago
  I did not realize that Intel CPU's also open up the kernel to the Spectre attack, while others don't. That's noteworthy.
martinald 9y ago
Any CPU that uses branch prediction that doesn't invalidate the cache after failure I think.
- betterunix2 9y ago
  How is that supposed to work? You would have to flush the entire cache on every branch, which would mostly defeat the point of the cache in the first place. (The exploit involves reading an off-limits location in the speculative branch, then reading a legal location based on the off-limits value; so unless the entire cache was flushed the attack would still be possible.)
  - zelos 9y ago
    Could you somehow mark cache lines that are filled by speculatively executed instructions so they only become visible to normally executed instructions when the speculative instructions are committed? I guess that would require a lot more logic and more cache tag bits.
    - contrarian_ 9y ago
      You can then detect which addresses were loaded because they caused other cache lines to be evicted. Even if speculative loads do not modify the cache, you could still have a side channel by analyzing the memory bus contention. IMO there is no way to get rid of these timing attacks entirely without getting rid of SMT and speculation.
      - fyi1183 9y ago
        The solution may lie in a new "non-speculative load“ instruction that delays execution until preceding branches are confirmed. This would allow keeping the performance of speculative execution in the vast majority of cases, while also fixing the kind of potentially leaking double-indirections that Spectre variant 1 can exploit. Spectre variant 2 needs to be fixed by isolation of the branch prediction structures, i.e. tagging the BTB and others with the PCID and privilege level.
dekhn 9y ago
My interpretation is that they not calling this a bug or a flaw, but a logical consequence of the design, and does not represent a flaw because the original specification didn't specify the implementation be resistant to this kind of attack.
- dmannorreys 9y ago
  A bug is a bug regardless of what the original specification mentioned.
  - dekhn 9y ago
    I don't agree. If a spec leaves out details, the impelmentors are free to make reasonable decisions on how to implement it. It's more likely the spec didn't really have much to say about promises on the visible effects of speculative execution (the specs are often highly detailed about what side effects can be visible, this is a consequence of modern complex processors, which have very subtle designs). A bug would occur in the case where the specification specified that there were no visible side effects from these mispredicted speculative executions, and the processor implementor failed to implement that part of the specification. This is a big deal because if it's a bug, Intel is liable. It's likely all processors with these kinds of features, the specs will get updated to be more specific about these kinds of side effects.
    - dmannorreys 9y ago
      Are you saying a bug cannot exist unless some functionality is specifically mentioned in the specification, and broken in reality?
      - dekhn 9y ago
        From the perspective of Intel, as well as most of the microprocessor industry, yeah. Even "broken in reality" is arguable: while this is indeed an exploit, choosing performance over security (when the resources to implement a chip are finite) is a legitimate design tradeoff.
jonknee 9y ago
That's like if Takata claimed it wasn't a production issue in Takata airbags, it was an issue that affected any airbag that was designed like Takata airbags. It's a bunch of bullshit trying to dance around the fact that Intel shipped faulty products for years. The fact that other similar products may also be faulty isn't a valid excuse.
- chairmanwow 9y ago
  I'm not sure that calling it faulty is exactly fair. I feel like the attack is actually pretty brilliant, and has been non-obviously "vulnerable" for years.
  - betterunix2 9y ago
    It would be like Takata claiming their airbags are not a problem because all airbags can kill infants. There is a problem that uniquely affects one manufacturer's product line, and another problem that affects many manufacturers. Intel has been shipping chips that are uniquely and more severely affected by these attacks for many years now. They were ignorant, sure, but they did have a uniquely vulnerable design.
  - jonknee 9y ago
    The same can be said for many security vulnerabilities, but that doesn't make them any less faulty. Shellshock exploited a bug that had been in Bash for 25 years (!), but being non-obvious isn't a free pass. I am not angry at Intel and in general think they do a good job, but trying to dodge blame here comes off sounding pathetic.
  - emn13 9y ago
    The attack is pretty brilliant; but it's also not quite novel. Cache-timing attacks aren't new; certainly CPU suppliers should have known the general issues at hand for... at least a decade? See e.g. Colin Percival's somewhat related attack on hyperthreading way back in 2005: http://www.daemonology.net/papers/htt.pdf http://www.daemonology.net/papers/htt.pdf Actually exploiting the information leakage isn't easy; and its compounded by the secrecy surrounding cpu internals. So I think they definitely deserve some blame here. Yes, the PoC is new. But the attack surface was widely known more than a decade ago, and they chose to punt the issue onto software; a solution that was unlikely to really hold water.
lurker456 9y ago
But it is a bug in Intel products. Whether similarly designed products are also affected is orthogonal.
revelation 9y ago
It feels like you should be able to make a version of branch prediction with speculative execution that behaves the same as the non-speculative-fo-real execution. As in accessing memory you can't actually access doesn't cause a load and does not speculatively execute further instructions with data you weren't supposed to be able to load in the first place. This is after all what the real execution does; when you try to load from a memory address that you are not allowed to, it does not cause a memory load, it does not affect the cache and it does not continue executing instruction but instead generates a page fault. We skip the page fault thing in speculative execution, obviously, but we shouldn't continue normal control flow. I'm sure that is a lot more difficult to implement in silicon and may end up negating the performance benefits of speculative execution, but right now it feels like not having the memory protection in place in speculative execution is a performance hack that exploded in all our faces.
- Gracana 9y ago
  In spectre, the victim process is coerced (via branch misprediction, in their first example) to speculatively access its own memory, resulting in side-effects that you can measure to determine the memory contents. No violation of memory protection needed.

bad_alloc 9y ago

IF the bug is present in all processors that use speculative execution AND Intel products use speculative execution THEN it is a bug in Intel products. It would only be correct to say "This is not a bug or a flaw exclusive to Intel products"

betterunix2 9y ago

The effect on Intel is far more severe than on other architectures. There were three vulnerabilities, two grouped together as "spectre" and one called "meltdown." Intel products are uniquely vulnerable to the meltdown attack, while many CPUs are vulnerable to spectre. The summary AFAIUI is that for most CPUs you can attack userspace processes with these techniques (think Javascript running in a browser), while for Intel CPUs you can also attack the kernel. Intel CPUs also seem to be somewhat easier to attack than others because of a higher-bandwidth side channel.

Symmetry 9y ago
A minor correction, ARM's upcoming A75 core looks like it will be vulnerable to Meltdown too. But since it isn't intended for use on server workloads the performance impact of the fix shouldn't be very significant.
bzbarsky 9y ago
> Intel products are uniquely vulnerable to the meltdown attack More precisely, there is only a PoC for Intel at this time. AMD processors are believed to not be vulnerable. Some ARM processors _are_ believed to be vulnerable. > for most CPUs you can attack userspace processes with these techniques Spectre can attack the kernel as well, at least according to http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html http://www.tomshardware.com/news/meltdown-spectre-exploits-i... . It's just harder to use than meltdown.
- arohner 9y ago
  That link no longer loads for me. AIUI, Spectre can be used to attack the kernel, only if you can get code running in kernel-space, via, e.g. eBPF.
  - contrarian_ 9y ago
    No, you could also find a gadget with ROP techniques. The eBPF thing in the paper was purely due to convenience of exploitation.
  - bzbarsky 9y ago
    > That link no longer loads for me. Oh, right, ycombinator's URL parser is broken. I fixed the link to work around the buggy parser....
  - elihu 9y ago
    I think that's almost but not quite exactly right. Spectre variant 2 attacks vulnerable indirect jump code patterns that exist in the kernel (or some other process), but doesn't require running the attacker's code. Spectre variant 1 allows you to infer the contents of memory in the same address space, so that's the one where you'd use eBPF to attack the kernel. Meltdown (variant 3) if I understand correctly can infer memory contents of other address spaces without relying on any assumptions about the code running in the other address space. https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html https://security.googleblog.com/2018/01/more-details-about-m...
- swsieber 9y ago
  I'm curious about AMD not being vulnerable, mostly because this page: https://www.kb.cert.org/vuls/id/584653 https://www.kb.cert.org/vuls/id/584653 makes me think that AMD has admitted to being vulnerable.
  - bzbarsky 9y ago
    That page talks about both Meltdown and Spectre, as far as I can tell. AMD is vulnerable to Spectre; everyone agrees on that. According to https://www.amd.com/en/corporate/speculative-execution https://www.amd.com/en/corporate/speculative-execution AMD claims it's not vulnerable to Meltdown (aka "Variant Three").
cma 9y ago
"(at least for the spectre attack)"
swsieber 9y ago
I did not realize that Intel CPU's also open up the kernel to the Spectre attack, while others don't. That's noteworthy.

martinald 9y ago

Any CPU that uses branch prediction that doesn't invalidate the cache after failure I think.

betterunix2 9y ago
How is that supposed to work? You would have to flush the entire cache on every branch, which would mostly defeat the point of the cache in the first place. (The exploit involves reading an off-limits location in the speculative branch, then reading a legal location based on the off-limits value; so unless the entire cache was flushed the attack would still be possible.)
- zelos 9y ago
  Could you somehow mark cache lines that are filled by speculatively executed instructions so they only become visible to normally executed instructions when the speculative instructions are committed? I guess that would require a lot more logic and more cache tag bits.
  - contrarian_ 9y ago
    You can then detect which addresses were loaded because they caused other cache lines to be evicted. Even if speculative loads do not modify the cache, you could still have a side channel by analyzing the memory bus contention. IMO there is no way to get rid of these timing attacks entirely without getting rid of SMT and speculation.
    - fyi1183 9y ago
      The solution may lie in a new "non-speculative load“ instruction that delays execution until preceding branches are confirmed. This would allow keeping the performance of speculative execution in the vast majority of cases, while also fixing the kind of potentially leaking double-indirections that Spectre variant 1 can exploit. Spectre variant 2 needs to be fixed by isolation of the branch prediction structures, i.e. tagging the BTB and others with the PCID and privilege level.

dekhn 9y ago

My interpretation is that they not calling this a bug or a flaw, but a logical consequence of the design, and does not represent a flaw because the original specification didn't specify the implementation be resistant to this kind of attack.

dmannorreys 9y ago
A bug is a bug regardless of what the original specification mentioned.
- dekhn 9y ago
  I don't agree. If a spec leaves out details, the impelmentors are free to make reasonable decisions on how to implement it. It's more likely the spec didn't really have much to say about promises on the visible effects of speculative execution (the specs are often highly detailed about what side effects can be visible, this is a consequence of modern complex processors, which have very subtle designs). A bug would occur in the case where the specification specified that there were no visible side effects from these mispredicted speculative executions, and the processor implementor failed to implement that part of the specification. This is a big deal because if it's a bug, Intel is liable. It's likely all processors with these kinds of features, the specs will get updated to be more specific about these kinds of side effects.
  - dmannorreys 9y ago
    Are you saying a bug cannot exist unless some functionality is specifically mentioned in the specification, and broken in reality?
    - dekhn 9y ago
      From the perspective of Intel, as well as most of the microprocessor industry, yeah. Even "broken in reality" is arguable: while this is indeed an exploit, choosing performance over security (when the resources to implement a chip are finite) is a legitimate design tradeoff.

jonknee 9y ago

That's like if Takata claimed it wasn't a production issue in Takata airbags, it was an issue that affected any airbag that was designed like Takata airbags. It's a bunch of bullshit trying to dance around the fact that Intel shipped faulty products for years. The fact that other similar products may also be faulty isn't a valid excuse.

chairmanwow 9y ago
I'm not sure that calling it faulty is exactly fair. I feel like the attack is actually pretty brilliant, and has been non-obviously "vulnerable" for years.
- betterunix2 9y ago
  It would be like Takata claiming their airbags are not a problem because all airbags can kill infants. There is a problem that uniquely affects one manufacturer's product line, and another problem that affects many manufacturers. Intel has been shipping chips that are uniquely and more severely affected by these attacks for many years now. They were ignorant, sure, but they did have a uniquely vulnerable design.
- jonknee 9y ago
  The same can be said for many security vulnerabilities, but that doesn't make them any less faulty. Shellshock exploited a bug that had been in Bash for 25 years (!), but being non-obvious isn't a free pass. I am not angry at Intel and in general think they do a good job, but trying to dodge blame here comes off sounding pathetic.
- emn13 9y ago
  The attack is pretty brilliant; but it's also not quite novel. Cache-timing attacks aren't new; certainly CPU suppliers should have known the general issues at hand for... at least a decade? See e.g. Colin Percival's somewhat related attack on hyperthreading way back in 2005: http://www.daemonology.net/papers/htt.pdf http://www.daemonology.net/papers/htt.pdf Actually exploiting the information leakage isn't easy; and its compounded by the secrecy surrounding cpu internals. So I think they definitely deserve some blame here. Yes, the PoC is new. But the attack surface was widely known more than a decade ago, and they chose to punt the issue onto software; a solution that was unlikely to really hold water.

lurker456 9y ago

But it is a bug in Intel products. Whether similarly designed products are also affected is orthogonal.

revelation 9y ago

It feels like you should be able to make a version of branch prediction with speculative execution that behaves the same as the non-speculative-fo-real execution. As in accessing memory you can't actually access doesn't cause a load and does not speculatively execute further instructions with data you weren't supposed to be able to load in the first place. This is after all what the real execution does; when you try to load from a memory address that you are not allowed to, it does not cause a memory load, it does not affect the cache and it does not continue executing instruction but instead generates a page fault. We skip the page fault thing in speculative execution, obviously, but we shouldn't continue normal control flow. I'm sure that is a lot more difficult to implement in silicon and may end up negating the performance benefits of speculative execution, but right now it feels like not having the memory protection in place in speculative execution is a performance hack that exploded in all our faces.

Gracana 9y ago
In spectre, the victim process is coerced (via branch misprediction, in their first example) to speculatively access its own memory, resulting in side-effects that you can measure to determine the memory contents. No violation of memory protection needed.