3 ms·
> 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-
by 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 agoThe 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 agoThanks 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?