diff options
author | Andy Lutomirski <luto@kernel.org> | 2018-04-17 17:36:36 +0300 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2018-04-27 18:07:58 +0300 |
commit | 8bb2610bc4967f19672444a7b0407367f1540028 (patch) | |
tree | c0d0fec57aa9866fad60d843fa32f6b84d5c9ed8 /fs | |
parent | 316d097c4cd4e7f2ef50c40cff2db266593c4ec4 (diff) | |
download | linux-8bb2610bc4967f19672444a7b0407367f1540028.tar.xz |
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
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions