Not quite -- without his patch, the performance penalty will hit them too. Tom is proposing to be excluded from the proposed solution as it would hit AMD with collateral damage from the `X86_BUG_CPU_INSECURE` fix.

I'm sure there are frantic emails claiming that AMD shouldn't be punished for Intel's mistake.

EDIT: actually the fix will go out with 4.14.12 and 4.15rc7, both `X86_BUG_CPU_INSECURE` and AMD's addendum to be protected from the collateral damage.

Not so sure about that. I am reading the merge commit, and comments are pretty interesting:

  --- a/arch/x86/include/asm/processor.h  
  +++ b/arch/x86/include/asm/processor.h
  + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
  + * address, then that syscall will enter the kernel with a
  + * non-canonical return address, and SYSRET will explode dangerously.
  + * We avoid this particular problem by preventing anything executable  
  + * from being mapped at the maximum canonical address.
  + *
  + * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
  + * CPUs malfunction if they execute code from the highest canonical page.
  + * They'll speculate right off the end of the canonical space, and
  + * bad things happen.  This is worked around in the same way as the
  + * Intel problem.

As long as the patch is all anyone notices then it looks great from AMD marketing. But I'm fairly confident (and a quick browse through the patched in the latest RC confirms at least one instance of this) where comments call out that AMD CPUs do things that should be considered bugs, so there's probably not going to be a lot of PR people telling the masses to read the source code. It's not exactly flattering to anyone.

One thing I can definitely respect about the kernel developers is that they don't seem to make any effort to be nice about the fact that they need to deal with undocumented nonsense from vendors all round.

Tom Lendacky works at AMD, so yes... :)