[PATCH 0/2] x86_64,entry: Clear NT on entry and speed up switch_to

From: Andy Lutomirski
Date: Tue Sep 30 2014 - 15:40:51 EST

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

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

- 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(-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/