5c8f6a2e31
In the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the
trampoline stack. But XEN pv doesn't use trampoline stack, so
PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack.
In that case, source and destination stacks are identical, which means
that reusing swapgs_restore_regs_and_return_to_usermode() in XEN pv
would cause %rsp to move up to the top of the kernel stack and leave the
IRET frame below %rsp.
This is dangerous as it can be corrupted if #NMI / #MC hit as either of
these events occurring in the middle of the stack pushing would clobber
data on the (original) stack.
And, with XEN pv, swapgs_restore_regs_and_return_to_usermode() pushing
the IRET frame on to the original address is useless and error-prone
when there is any future attempt to modify the code.
[ bp: Massage commit message. ]
Fixes:
|
||
---|---|---|
.. | ||
syscalls | ||
vdso | ||
vsyscall | ||
Makefile | ||
calling.h | ||
common.c | ||
entry_32.S | ||
entry_64.S | ||
entry_64_compat.S | ||
syscall_32.c | ||
syscall_64.c | ||
syscall_x32.c | ||
thunk_32.S | ||
thunk_64.S |