x86/entry/64/compat: Preserve r8-r11 in int $0x80
authorAndy Lutomirski <luto@kernel.org>
Tue, 17 Apr 2018 14:36:36 +0000 (07:36 -0700)
committerThomas Gleixner <tglx@linutronix.de>
Fri, 27 Apr 2018 15:07:58 +0000 (17:07 +0200)
commit8bb2610bc4967f19672444a7b0407367f1540028
treec0d0fec57aa9866fad60d843fa32f6b84d5c9ed8
parent316d097c4cd4e7f2ef50c40cff2db266593c4ec4
x86/entry/64/compat: Preserve r8-r11 in int $0x80

32-bit user code that uses int $80 doesn't care about r8-r11.  There is,
however, some 64-bit user code that intentionally uses int $0x80 to invoke
32-bit system calls.  From what I've seen, basically all such code assumes
that r8-r15 are all preserved, but the kernel clobbers r8-r11.  Since I
doubt that there's any code that depends on int $0x80 zeroing r8-r11,
change the kernel to preserve them.

I suspect that very little user code is broken by the old clobber, since
r8-r11 are only rarely allocated by gcc, and they're clobbered by function
calls, so they only way we'd see a problem is if the same function that
invokes int $0x80 also spills something important to one of these
registers.

The current behavior seems to date back to the historical commit
"[PATCH] x86-64 merge for 2.6.4".  Before that, all regs were
preserved.  I can't find any explanation of why this change was made.

Update the test_syscall_vdso_32 testcase as well to verify the new
behavior, and it strengthens the test to make sure that the kernel doesn't
accidentally permute r8..r15.

Suggested-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Link: https://lkml.kernel.org/r/d4c4d9985fbe64f8c9e19291886453914b48caee.1523975710.git.luto@kernel.org
arch/x86/entry/entry_64_compat.S
tools/testing/selftests/x86/test_syscall_vdso.c