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

From: Andy Lutomirski
Date: Wed Oct 01 2014 - 14:49:14 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
here.

These patches filter NT on all kernel entries. For syscall (both
bitnesses), this is free. For sysenter, it seems to cost very
little (less than my ability to measure, although I didn't try that
hard). Patch 2, which isn't tagged for -stable, speeds up context
switches by avoiding saving and restoring flags, so this series
should be a decent overall performance win.

See: https://bugs.winehq.org/show_bug.cgi?id=33275

Note to bikeshedders: I have no desire to go crazy micro-optimizing
the sysenter path. :) This version seems to be good enough (and
should be a performance *increase* for most workloads).

Changes from v3:
- Added a better description of the impact in patch 1

Changes from v2:
- Move the flag fixup out of line
- Fix a CFI buglet

Changes from v1:
- Spell stable@xxxxxxxxxxxxxxx correctly
- Tidy up changelog text
- Actually commit an asm constraint fix in patch 2 (egads!)
- Replace the unconditional popfq with a branch

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 | 18 +++++++++++++++++-
arch/x86/include/asm/switch_to.h | 12 ++++++++----
arch/x86/kernel/cpu/common.c | 2 +-
3 files changed, 26 insertions(+), 6 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/