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.

Maybe it's just me but that name is just too general. Is there no other conceivable way an x86 CPU can ever be "insecure"? Why'd they use something so vague? Is this part of the redaction?

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.

I wrote that text. It's just documenting a bug that never affected Linux at all.

I'm having trouble finding a good reference right now.

That's an old issue, fixed many months ago, not related to the 'new' Intel bug. The comment was updated in this patch series, that's it.

It's a completely unrelated bug. This DragonFlyBSD commit message does a pretty good job of explaining it: http://lists.dragonflybsd.org/pipermail/commits/2017-August/...

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... :)