>6.4 Limitations on ARM and AMD
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 described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
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, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.
Seems like the possibility exists that AMD/ARM could be affected, based on the behavior they saw, but they were not able to successfully verify.
the intel behaviour is probably the result of an optimization / architectural decision. like when the micro ops fetch a value from memory they are probably fetching the real value then setting a flag that the instruction is invalid. like it might be cheaper to deal with the problem later in the pipeline than earlier.
but it might also be reasonable in a different architecture to fetch 0 straight away to the micro op when the memory access is invalid and set a flag to raise the exception as well. in this situation you don't have the problem because you are just shuffling around invalid data.
That's fair, but the leads on multiple press releases are that this affects all processors equally which feels very disingenuous to me. Intel's latest press release for example.
>6.4 Limitations on ARM and AMD 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 described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow 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, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Seems like the possibility exists that AMD/ARM could be affected, based on the behavior they saw, but they were not able to successfully verify.