There are suggestions it applies to Arm, as there is an arm64 patch for Linux although it hasnt been merged yet I don't think (although the performance hit for the fix might not be as bad).

We won't know until we know what the actual bug is. All we know is that people are writing patches for Intel chips, and what those patches do.

It's very possible that other processors are affected by the same issue in some different way that doesn't require this set of patches to mitigate.

We know that AMD is not affected:

https://lkml.org/lkml/2017/12/27/2

We know that "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against." E.g. that AMD does not need the patch that Intel does. That is not the same as saying AMD is not affected at all.

We do not know what the actual bug that prompted this activity is. Nobody has revealed that information. It is possible that the bug affects AMD also but does not require this patch.

The followup sentence: "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

That is a pretty specific reference to the root of the problem, and a pretty clear indication that AMD's design decisions protect against whatever the attack is. Sure, we may find out that there is more to the attack than just speculative memory references, but so far what we have seen suggests a fairly specific vulnerability (that just happens to involve the particular design choices of a dominant chipmaker).

And, 17 hours later, we now know that there were three distinct vulnerabilities, of which one applies to AMD.

https://googleprojectzero.blogspot.com/2018/01/reading-privi...

Only under specific software configurations that are not enabled by default, or confined to a userspace single process (which is bad for web browsers running Javascript but not nearly as bad as the Intel-specific attacks). So while AMD is somewhat vulnerable, the most severe and easiest to exploit vulnerabilities are pretty specific to Intel. In a pedantic sense you were right, AMD chips are affected, but it is literally not on the same level as for Intel chips.

That's correct and it is a fair way to see it. However, Intel dragging two of its main competitors name into the limelight is a rather uncool move.

We know that people think that AMD is not affected by this permutation of the attack. Intel may know differently; I'd withhold sweeping claims.

"The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

Sounds like AMD's chips are not affected by variants of this attack either. Sure, we should wait for the details to be published before making sweeping claims, but the details we have so far paint a reasonable picture of what the vulnerability involves. It is reasonable to assume that AMD's design decisions prevent this attack, while Intel's decisions enable it.

You think Intel considers AMD vulnerable while AMD considers itself not vulnerable? That's quite an assumption to ask of us.

It was an AMD engineer, and he referred to specific details about a microarchitecture bug that seems to be important in this attack. So we are really being asked to believe that Intel's PR team knows more about AMD's microarchitecture than AMD's engineers (or that AMD's engineers are secret PR agents).

Would not be the first time vendor X knows vendor Y is vulnerable even as vendor Y denies it.

Now my interest is piqued: what instances of `vendor X` and `vendor Y` do you know of?

Well, at least one time I found a bug in OpenBSD, told NetBSD, then looked at their fix and discovered our fix was incomplete because my regress had a false negative. But up until that moment I was pretty confident about our fix.

I think that's sort of a pattern. Vendor X is affected by a POC, so they fix the issue. They then develop more tests. Vendor Y concludes they are not affected, perhaps based on a false negative test, and fails to investigate further. Now X understands more about the true scope of the problem than Y and they have tests to demonstrate on Y, but Y does not.

If the general consensus that it's a timing attack related to speculative execution is correct, then Intel is correct to say that --- any CPU which does speculative execution in the aggressive manner that (most of --- AFAIK they still have some low-power non-OoO cores) Intels' do will be affected similarly.

There's this interesting post on RISC-V from roughly the same timeframe, that suggests it's not immune either: https://groups.google.com/a/groups.riscv.org/forum/#!msg/isa...

AMD manufactures some ARM 64 chips, which might make this "technically true" albeit intentionally misleading.

Intel may have code that shows PoC on other brands/ISAs.

But if they do they haven’t shared it.