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

[Andy Lutomirski]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/