Re: [PATCH 24/24] x86/syscall/64: Move the checking for sysret to C code

From: Lai Jiangshan
Date: Fri Sep 10 2021 - 03:30:25 EST




On 2021/9/10 15:20, Nikolay Borisov wrote:


On 31.08.21 г. 20:50, Lai Jiangshan wrote:
From: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx>

Like do_fast_syscall_32() which checks whether it can return to userspace
via fast instructions before the function returns, do_syscall_64()
also checks whether it can use sysret to return to userspace before
do_syscall_64() returns via C code. And a bunch of ASM code can be removed.

No functional change intended.

Signed-off-by: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx>

<snip>

+/*
+ * Check if it can use SYSRET.
+ *
+ * Try to use SYSRET instead of IRET if we're returning to
+ * a completely clean 64-bit userspace context.
+ *
+ * Returns 0 to return using IRET or 1 to return using SYSRET.
+ */
+static __always_inline int can_sysret(struct pt_regs *regs)

nit: Since this is a predicate function why not simply return bool ?

I don't have any preference.

The choice came from my limitation of the needed knowledge.

I followed the design of do_fast_syscall_32() which returns a 4-byte word
to indicate if it can fast return to userspace, and I know how to test the
result in ASM for a 4-byte word. If it was a bool, I don't know how to
test the result in ASM.


+{
+ /* In the Xen PV case we must use iret anyway. */
+ if (static_cpu_has(X86_FEATURE_XENPV))
+ return 0;
+
+ /* SYSRET requires RCX == RIP && R11 == RFLAGS */
+ if (regs->ip != regs->cx || regs->flags != regs->r11)
+ return 0;
+
+ /* CS and SS must match SYSRET */
+ if (regs->cs != __USER_CS || regs->ss != __USER_DS)
+ return 0;
+
+ /*
+ * On Intel CPUs, SYSRET with non-canonical RCX/RIP will #GP
+ * in kernel space. This essentially lets the user take over
+ * the kernel, since userspace controls RSP.
+ */
+ if (regs->cx != canonical_address(regs->cx))
+ return 0;
+
+ /*
+ * SYSCALL clears RF when it saves RFLAGS in R11 and SYSRET cannot
+ * restore RF properly. If the slowpath sets it for whatever reason, we
+ * need to restore it correctly.
+ *
+ * SYSRET can restore TF, but unlike IRET, restoring TF results in a
+ * trap from userspace immediately after SYSRET. This would cause an
+ * infinite loop whenever #DB happens with register state that satisfies
+ * the opportunistic SYSRET conditions. For example, single-stepping
+ * this user code:
+ *
+ * movq $stuck_here, %rcx
+ * pushfq
+ * popq %r11
+ * stuck_here:
+ *
+ * would never get past 'stuck_here'.
+ */
+ if (regs->r11 & (X86_EFLAGS_RF | X86_EFLAGS_TF))
+ return 0;
+
+ return 1;
+}
+
+/* Returns 0 to return using IRET or 1 to return using SYSRET. */
+__visible noinstr int do_syscall_64(struct pt_regs *regs, int nr)

nit: Ditto about bool

{
add_random_kstack_offset();
nr = syscall_enter_from_user_mode(regs, nr);
@@ -84,6 +154,7 @@ __visible noinstr void do_syscall_64(struct pt_regs *regs, int nr)
instrumentation_end();
syscall_exit_to_user_mode(regs);
+ return can_sysret(regs);
}
#endif

<snip>