3 ms·
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
by uniformlyrandom 9y ago
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.
- juergbi 9y agoThat'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.
- amluto 9y agoI 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.
- xeeeeeeeeeeenu 9y agoIt'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/626190.html http://lists.dragonflybsd.org/pipermail/commits/2017-August/...