6 ms·

One obvious question: Is there a way to fix the problem compatibly? AMD doesn't seem to be vulnerable, so you'd imagine that code couldn't rely on this behavio

by cbd1984 11y ago

One obvious question: Is there a way to fix the problem compatibly? AMD doesn't seem to be vulnerable, so you'd imagine that code couldn't rely on this behavior because then it would fail on AMD chips, but... well, once you've read enough of The Old New Thing, you get a feel for how gonzo some developers get with This Never Fails and This Will Never Change, and if they have to write different codepaths for Intel and AMD instead of doing things sanely, that doesn't seem such a huge imposition to the irrational mind.

cbd1984 11y ago
So apparently this bug is here to stay, since there's only software workarounds, but no actual fixes.
cnvogel 11y ago
There is, and it's been fixed in Linux for a few years, possibly the severity of the issue wasn't even realized back then. In linux-mainline/arch/x86/entry/entry_64.S, at syscall_return you'll find a comment explaining that a more complicated and slower method will used to return to usespace should a few conditions not be met. https://github.com/torvalds/linux/blob/master/arch/x86/entry/entry_64.S#L294 https://github.com/torvalds/linux/blob/master/arch/x86/entry... The original fix is from 2006, then at x86_64/kernel/entry.S https://github.com/torvalds/linux/commit/7bf36bbc5e0c09271f9efe22162f8cc3f8ebd3d2 https://github.com/torvalds/linux/commit/7bf36bbc5e0c09271f9... [PATCH] x86_64: When user could have changed RIP always force IRET Intel EM64T CPUs handle uncanonical return addresses differently from AMD CPUs. The exception is reported in the SYSRET, not the next instruction. This leads to the kernel exception handler running on the user stack with the wrong GS because the kernel didn't expect exceptions on this instruction. This version of the patch has the teething problems that plagued an earlier version fixed. This is CVE-2006-0744 Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial patches.
- cbd1984 11y ago
  That's a software patch. I meant changing the hardware to fix the bug at the source.

by cbd1984 11y ago

cbd1984 11y ago

So apparently this bug is here to stay, since there's only software workarounds, but no actual fixes.

cnvogel 11y ago

There is, and it's been fixed in Linux for a few years, possibly the severity of the issue wasn't even realized back then. In linux-mainline/arch/x86/entry/entry_64.S, at syscall_return you'll find a comment explaining that a more complicated and slower method will used to return to usespace should a few conditions not be met. https://github.com/torvalds/linux/blob/master/arch/x86/entry/entry_64.S#L294 https://github.com/torvalds/linux/blob/master/arch/x86/entry... The original fix is from 2006, then at x86_64/kernel/entry.S https://github.com/torvalds/linux/commit/7bf36bbc5e0c09271f9efe22162f8cc3f8ebd3d2 https://github.com/torvalds/linux/commit/7bf36bbc5e0c09271f9... [PATCH] x86_64: When user could have changed RIP always force IRET Intel EM64T CPUs handle uncanonical return addresses differently from AMD CPUs. The exception is reported in the SYSRET, not the next instruction. This leads to the kernel exception handler running on the user stack with the wrong GS because the kernel didn't expect exceptions on this instruction. This version of the patch has the teething problems that plagued an earlier version fixed. This is CVE-2006-0744 Thanks to Ernie Petrides and Asit B. Mallick for analysis and initial patches.

cbd1984 11y ago
That's a software patch. I meant changing the hardware to fix the bug at the source.