x86/signal/64: Fix SS handling for signals delivered to 64-bit programs
authorAndy Lutomirski <luto@amacapital.net>
Thu, 12 Mar 2015 20:57:51 +0000 (13:57 -0700)
committerIngo Molnar <mingo@kernel.org>
Tue, 17 Mar 2015 08:25:25 +0000 (09:25 +0100)
commitc6f2062935c8fcb31235799eaee8bcd5b649936b
tree475bd9963438b644df6e47cf1c4eeaebacff7496
parent263042e4630a85e856b4a8cd72f28dab33ef4741
x86/signal/64: Fix SS handling for signals delivered to 64-bit programs

The comment in the signal code says that apps can save/restore
other segments on their own.  It's true that apps can *save* SS
on their own, but there's no way for apps to restore it: SYSCALL
effectively resets SS to __USER_DS, so any value that user code
tries to load into SS gets lost on entry to sigreturn.

This recycles two padding bytes in the segment selector area for SS.

While we're at it, we need a second change to make this useful.

If the signal we're delivering is caused by a bad SS value,
saving that value isn't enough.  We need to remove that bad
value from the regs before we try to deliver the signal.  Oddly,
the i386 code already got this right.

I suspect that 64-bit programs that try to run 16-bit code and
use signals will have a lot of trouble without this.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
arch/x86/include/asm/sigcontext.h
arch/x86/include/uapi/asm/sigcontext.h
arch/x86/kernel/signal.c