Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

Re:Intel Confronts Potential ‘PR Nightmare’ With Reported Ch... by uniformlyrandom on Wednesday January 03, 2018 @01:51PM (#16063834)

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.

[ Parent | on HN ]

Re:Intel Confronts Potential ‘PR Nightmare’ With Reported Ch... by amluto on Wednesday January 03, 2018 @02:44PM (#16064367)

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.

[ Parent | on HN ]

Re:Intel Confronts Potential ‘PR Nightmare’ With Reported Ch... by juergbi on Wednesday January 03, 2018 @02:24PM (#16064170)

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.

[ Parent | on HN ]

Re:Intel Confronts Potential ‘PR Nightmare’ With Reported Ch... by xeeeeeeeeeeenu on Wednesday January 03, 2018 @03:35PM (#16064820)

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/...

[ Parent | on HN ]