Re: [PATCH v2 24/36] x86/entry/compat: Implement opportunistic SYSRETL for compat syscalls

From: Borislav Petkov
Date: Mon Oct 12 2015 - 12:15:37 EST


On Mon, Oct 05, 2015 at 05:48:12PM -0700, Andy Lutomirski wrote:
> If CS, SS and IP are as expected and FLAGS is compatible with SYSRETL,
> then return from fast compat syscalls (both SYSCALL and SYSENTER) using
> SYSRETL.
>
> Unlike native 64-bit opportunistic SYSRET, this is not invisible to
> user code: RCX and R8-R15 end up in a different state than shown
> saved in pt_regs. To compensate, we only do this when returning to
> the vDSO fast syscall return path. This won't interfere with
> syscall restart, as we won't use SYSRETL when returning to the INT80
> restart instruction.
>
> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
> ---
> arch/x86/entry/common.c | 23 +++++++++++++++++++---
> arch/x86/entry/entry_64_compat.S | 42 ++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 60 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> index 1b2606edc621..88dc5ba14d47 100644
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -363,7 +363,8 @@ __visible void do_int80_syscall_32(struct pt_regs *regs)
> syscall_return_slowpath(regs);
> }
>
> -__visible void do_fast_syscall_32(struct pt_regs *regs)
> +/* Returns 0 to return using IRET or 1 to return using SYSRETL. */
> +__visible long do_fast_syscall_32(struct pt_regs *regs)
> {
> /*
> * Called using the internal vDSO SYSENTER/SYSCALL32 calling
> @@ -395,12 +396,28 @@ __visible void do_fast_syscall_32(struct pt_regs *regs)
> enter_from_user_mode();
> #endif
> prepare_exit_to_usermode(regs);
> - return;
> + return 0; /* Keep it simple: use IRET. */
> }
> local_irq_disable();
>
> /* Now this is just like a normal syscall. */
> do_int80_syscall_32(regs);
> - return;
> +
> +#ifdef CONFIG_X86_64
> + /*
> + * Opportunistic SYSRETL: if possible, try to return using SYSRETL.
> + * SYSRETL is available on all 64-bit CPUs, so we don't need to
> + * bother with SYSEXIT.
> + *
> + * Unlike 64-bit opportunistic SYSRET, we can't check that CX == IP,
> + * because the ECX fixup above will ensure that this is essentially
> + * never the case.
> + */
> + return regs->cs == __USER32_CS && regs->ss == __USER_DS &&
> + regs->ip == landing_pad &&
> + (regs->flags & (X86_EFLAGS_RF | X86_EFLAGS_TF)) == 0;

This could've used some readability massaging:

return regs->cs == __USER32_CS &&
regs->ss == __USER_DS &&
regs->ip == landing_pad &&
!(regs->flags & (X86_EFLAGS_RF | X86_EFLAGS_TF));

Although I'm not crazy about that one either. This expression is simply not
parseable at a glance.

Why not write it like the 64-bit opportunistic SYSRET:

if (regs->cs != __USER32_CS)
return 0;

if (regs->ss != __USER_DS)
return 0;

and so on...

asm is almost the same, except in the "after" case, the CALL to
syscall_trace_enter is after the last JMP.

before:

.L270:
xorl %eax, %eax # D.34060
cmpq $35, 136(%rbx) #, regs_12(D)->cs
je .L296 #,
.L263:
movq -32(%rbp), %rbx #,
movq -24(%rbp), %r12 #,
movq -16(%rbp), %r13 #,
movq -8(%rbp), %r14 #,
leave
ret
.L291:
movq %rbx, %rdi # regs,
call syscall_trace_enter #
jmp .L265 #
.L296:
cmpq $43, 160(%rbx) #, regs_12(D)->ss
jne .L263 #,
cmpq 128(%rbx), %r12 # regs_12(D)->ip, landing_pad
jne .L263 #,
xorl %eax, %eax # D.34060
testq $65792, 144(%rbx) #, regs_12(D)->flags
sete %al #, D.34060
jmp .L263 #


after:


.L271:
cmpq $35, 136(%rbx) #, regs_11(D)->cs
je .L293 #,
.L286:
xorl %eax, %eax # D.34060
.L264:
movq -32(%rbp), %rbx #,
movq -24(%rbp), %r12 #,
movq -16(%rbp), %r13 #,
movq -8(%rbp), %r14 #,
leave
ret
.L293:
cmpq $43, 160(%rbx) #, regs_11(D)->ss
jne .L286 #,
cmpq 128(%rbx), %r12 # regs_11(D)->ip, landing_pad
jne .L286 #,
xorl %eax, %eax # D.34060
testq $65792, 144(%rbx) #, regs_11(D)->flags
sete %al #, D.34060
jmp .L264 #

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/