linux-sg2042/arch
Andy Lutomirski 6c25da5ad5 x86/signal/64: Re-add support for SS in the 64-bit signal context
This is a second attempt to make the improvements from c6f2062935
("x86/signal/64: Fix SS handling for signals delivered to 64-bit
programs"), which was reverted by 51adbfbba5c6 ("x86/signal/64: Add
support for SS in the 64-bit signal context").

This adds two new uc_flags flags.  UC_SIGCONTEXT_SS will be set for
all 64-bit signals (including x32).  It indicates that the saved SS
field is valid and that the kernel supports the new behavior.

The goal is to fix a problems with signal handling in 64-bit tasks:
SS wasn't saved in the 64-bit signal context, making it awkward to
determine what SS was at the time of signal delivery and making it
impossible to return to a non-flat SS (as calling sigreturn clobbers
SS).

This also made it extremely difficult for 64-bit tasks to return to
fully-defined 16-bit contexts, because only the kernel can easily do
espfix64, but sigreturn was unable to set a non-flag SS:ESP.
(DOSEMU has a monstrous hack to partially work around this
limitation.)

If we could go back in time, the correct fix would be to make 64-bit
signals work just like 32-bit signals with respect to SS: save it
in signal context, reset it when delivering a signal, and restore
it in sigreturn.

Unfortunately, doing that (as I tried originally) breaks DOSEMU:
DOSEMU wouldn't reset the signal context's SS when clearing the LDT
and changing the saved CS to 64-bit mode, since it predates the SS
context field existing in the first place.

This patch is a bit more complicated, and it tries to balance a
bunch of goals.  It makes most cases of changing ucontext->ss during
signal handling work as expected.

I do this by special-casing the interesting case.  On sigreturn,
ucontext->ss will be honored by default, unless the ucontext was
created from scratch by an old program and had a 64-bit CS
(unfortunately, CRIU can do this) or was the result of changing a
32-bit signal context to 64-bit without resetting SS (as DOSEMU
does).

For the benefit of new 64-bit software that uses segmentation (new
versions of DOSEMU might), the new behavior can be detected with a
new ucontext flag UC_SIGCONTEXT_SS.

To avoid compilation issues, __pad0 is left as an alias for ss in
ucontext.

The nitty-gritty details are documented in the header file.

This patch also re-enables the sigreturn_64 and ldt_gdt_64 selftests,
as the kernel change allows both of them to pass.

Tested-by: Stas Sergeev <stsp@list.ru>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Borislav Petkov <bp@alien8.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/749149cbfc3e75cd7fcdad69a854b399d792cc6f.1455664054.git.luto@kernel.org
[ Small readability edit. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-02-17 08:32:11 +01:00
..
alpha dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
arc dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
arm Merge branch 'akpm' (patches from Andrew) 2016-01-23 11:13:56 -08:00
arm64 ARM: SoC support for Tegra platforms for v4.5 2016-01-22 17:30:52 -08:00
avr32 dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
blackfin dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
c6x dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
cris Merge branch 'akpm' (patches from Andrew) 2016-01-21 12:32:08 -08:00
frv dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
h8300 Merge branch 'akpm' (patches from Andrew) 2016-01-21 12:32:08 -08:00
hexagon dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
ia64 [IA64] Enable copy_file_range syscall for ia64 2016-01-22 14:20:01 -08:00
m32r m32r: fix m32104ut_defconfig build fail 2016-01-14 16:00:49 -08:00
m68k dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
metag dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
microblaze dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
mips Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus 2016-01-24 12:50:56 -08:00
mn10300 dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
nios2 dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
openrisc dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
parisc dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
powerpc wrappers for ->i_mutex access 2016-01-22 18:04:28 -05:00
s390 wrappers for ->i_mutex access 2016-01-22 18:04:28 -05:00
score Merge branch 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile 2015-10-04 16:31:13 +01:00
sh dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
sparc dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
tile dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
um um: kill pfn_t 2016-01-15 17:56:32 -08:00
unicore32 dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00
x86 x86/signal/64: Re-add support for SS in the 64-bit signal context 2016-02-17 08:32:11 +01:00
xtensa dma-mapping: remove <asm-generic/dma-coherent.h> 2016-01-20 17:09:18 -08:00
.gitignore
Kconfig dma-mapping: always provide the dma_map_ops based implementation 2016-01-20 17:09:18 -08:00