3 ms·

Meltdown is far worse in practice than Spectre. Spectre needs a more perfect storm of factors to lead to exploitation. No hardware is immune to it, but not all

Meltdown is far worse in practice than Spectre. Spectre needs a more perfect storm of factors to lead to exploitation. No hardware is immune to it, but not all software is vulnerable, either. You need code execution and you need a vulnerable target and you need to somehow trigger the vulnerable targets path and that vulnerable target needs data you want. Meltdown just needs code execution and you have full read access to all memory.

ars 9y ago
> Meltdown is far worse in practice than Spectre. Far worse for an unpached system, yes. But in terms of fixing the problem, Spectre is much worse, with a larger impact. It's so bad that I suspect some people will deliberately run without Spectre protection.
- kllrnohj 9y ago
  Other than javascript in a browser there does not appear to be much in the way of actual spectre attack vectors, though. So once browsers are patched spectre appears to be basically "fixed" for most practical purposes. Worth noting that many of the claims around Spectre are wholly un-demonstrated. The PoC only involves reading memory from within the same process (aka, the PoC read memory through a side channel that it had full ability to read anyway). Trying to exploit this in a different process is entirely undemonstrated, and there's not even any real discussion in the paper of how it would work. In theory it's doable, but the issues around how you do this once process switching and IPC enters the picture seems substantial yet the paper does not make any attempt to tackle any of that.
  - cthalupa 9y ago
    >Worth noting that many of the claims around Spectre are wholly un-demonstrated. This is untrue. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi... Variant 2 is Spectre. "This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second."
    - kllrnohj 9y ago
      Note that variant 2 of spectre has not been demonstrated on AMD and AMD claims to be unaffected ( http://www.amd.com/en/corporate/speculative-execution http://www.amd.com/en/corporate/speculative-execution ) However, the description of spectre from spectreattack.com is this: "Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets." That, however, is not demonstrated by any of these PoC, not that I can find.
    - strongholdmedia 9y ago
      >>Worth noting that many of the claims around Spectre are wholly un-demonstrated. >This is untrue. Anything that is not demonstrated in a reproducible way (that is, some downloadable PoC code) is wholly un-demonstrated. To date, afaik, that goes for Spectre in whole.
- boltzmann_brain 9y ago
  They're both leveraging speculative execution - Meltdown by executing instructions after exception has been raised, Spectre by running them when branch prediction failed. Meltdown method is simpler - just access kernel addresses, so the fix was to remove kernel mapping. But branch prediction methods are a lot more involved and fixing them has so much wider impact as you say -- I mean we're going to have live with even slower virtual calls from now on!

ars 9y ago

> Meltdown is far worse in practice than Spectre. Far worse for an unpached system, yes. But in terms of fixing the problem, Spectre is much worse, with a larger impact. It's so bad that I suspect some people will deliberately run without Spectre protection.

kllrnohj 9y ago
Other than javascript in a browser there does not appear to be much in the way of actual spectre attack vectors, though. So once browsers are patched spectre appears to be basically "fixed" for most practical purposes. Worth noting that many of the claims around Spectre are wholly un-demonstrated. The PoC only involves reading memory from within the same process (aka, the PoC read memory through a side channel that it had full ability to read anyway). Trying to exploit this in a different process is entirely undemonstrated, and there's not even any real discussion in the paper of how it would work. In theory it's doable, but the issues around how you do this once process switching and IPC enters the picture seems substantial yet the paper does not make any attempt to tackle any of that.
- cthalupa 9y ago
  >Worth noting that many of the claims around Spectre are wholly un-demonstrated. This is untrue. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi... Variant 2 is Spectre. "This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second."
  - kllrnohj 9y ago
    Note that variant 2 of spectre has not been demonstrated on AMD and AMD claims to be unaffected ( http://www.amd.com/en/corporate/speculative-execution http://www.amd.com/en/corporate/speculative-execution ) However, the description of spectre from spectreattack.com is this: "Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets." That, however, is not demonstrated by any of these PoC, not that I can find.
  - strongholdmedia 9y ago
    >>Worth noting that many of the claims around Spectre are wholly un-demonstrated. >This is untrue. Anything that is not demonstrated in a reproducible way (that is, some downloadable PoC code) is wholly un-demonstrated. To date, afaik, that goes for Spectre in whole.
boltzmann_brain 9y ago
They're both leveraging speculative execution - Meltdown by executing instructions after exception has been raised, Spectre by running them when branch prediction failed. Meltdown method is simpler - just access kernel addresses, so the fix was to remove kernel mapping. But branch prediction methods are a lot more involved and fixing them has so much wider impact as you say -- I mean we're going to have live with even slower virtual calls from now on!