3 ms·

Do you have any source on why AMD64 is unaffected? The paper only mentions that they couldn't make their current approach work on AMD, but it doesn't rule out t

Do you have any source on why AMD64 is unaffected? The paper only mentions that they couldn't make their current approach work on AMD, but it doesn't rule out that it could be improved and made work

betterunix2 9y ago
AMD's microarchitecture does not perform speculative loads that would cause a segfault, according to this AMD engineer: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2
- deleted 9y ago
  [deleted]
- K0nserv 9y ago
  > We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack de- scribed in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our im- plementation might simply be too slow and a more opti- mized version might succeed. For instance, a more shal- low out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indi- cating that out-of-order execution generally occurs and instructions past illegal memory accesses are also per- formed. From the Meltdown paper[0] section 6.4 it would seem that out of order execution referencing illegal memory locations still occurs unless of course I'm misunderstanding something. 0: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf
  - Khoth 9y ago
    The section 3 toy example is demonstrating that OOO execution can cause instructions after a faulting instruction to be speculatively executed, but in that example the subsequent instructions do not depend on the result of the faulting instruction. AMD's claim is that the result of the faulting instruction can never end up affecting a later speculated instruction - ie, for Intel the bad access says "here's the value you asked for" and later says "actually you don't have permission, forget you saw that". For AMD the bad access says "you don't have permission, so no result available"
    - K0nserv 9y ago
      Thanks for the explanation. So it's down to when the access check is performed. I wonder why Intel did it the way they did, performance maybe?
deleted 9y ago
[deleted]

Do you have any source on why AMD64 is unaffected? The paper only mentions that they couldn't make their current approach work on AMD, but it doesn't rule out that it could be improved and made work

betterunix2 9y ago

AMD's microarchitecture does not perform speculative loads that would cause a segfault, according to this AMD engineer: https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2

deleted 9y ago
[deleted]
K0nserv 9y ago
> We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack de- scribed in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our im- plementation might simply be too slow and a more opti- mized version might succeed. For instance, a more shal- low out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indi- cating that out-of-order execution generally occurs and instructions past illegal memory accesses are also per- formed. From the Meltdown paper[0] section 6.4 it would seem that out of order execution referencing illegal memory locations still occurs unless of course I'm misunderstanding something. 0: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf
- Khoth 9y ago
  The section 3 toy example is demonstrating that OOO execution can cause instructions after a faulting instruction to be speculatively executed, but in that example the subsequent instructions do not depend on the result of the faulting instruction. AMD's claim is that the result of the faulting instruction can never end up affecting a later speculated instruction - ie, for Intel the bad access says "here's the value you asked for" and later says "actually you don't have permission, forget you saw that". For AMD the bad access says "you don't have permission, so no result available"
  - K0nserv 9y ago
    Thanks for the explanation. So it's down to when the access check is performed. I wonder why Intel did it the way they did, performance maybe?

deleted 9y ago

[deleted]