Anish Bhatt noticed that user programs can set RFLAGS.NT before syscall or sysenter, and the kernel entry code doesn't filter out NT. This causes kernel C code and, depending on thread flags, the exit slow path to run with NT set.
The former is a little bit scary (imagine calling into EFI with NT set), and the latter will fail with #GP and send a spurious SIGSEGV. One answer would be "don't do that". But the kernel can do better here. These patches, which I'm not completely thrilled by, filter NT on all kernel entries. For syscall (both bitnesses), this is free. For sysenter, it costs 15 cycles or so. As a consolation prize, we can speed up context switches by avoiding saving and restoring flags. If we don't like the added sysenter overhead, there are few other options: - Try to optimize it by folding it with other flag manipulations (my attempt to do that didn't end up being any faster). - Only do the syscall part. That's free, but it serves little purpose other than being polite to buggy userspace code. - Don't filter NT on sysenter. Instead, filter it on EFI entry and modify the IRET code to retry without NT set if NT was set. - Don't filter NT on sysenter. Instead, only filter it when sysenter jumps to the slow path. (This is trivial, but it does nothing to reduce the chance that evil user code can cause trouble by, say, reading from sysfs with NT set using sysenter.) See: https://bugs.winehq.org/show_bug.cgi?id=33275 Andy Lutomirski (2): x86_64,entry: Filter RFLAGS.NT on entry from userspace x86_64: Don't save flags on context switch arch/x86/ia32/ia32entry.S | 10 +++++++++- arch/x86/include/asm/switch_to.h | 10 +++++++--- arch/x86/kernel/cpu/common.c | 2 +- 3 files changed, 17 insertions(+), 5 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
