linux-kernel - Getting rid of invalid SYSCALL RSP under Xen?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVJNZVLBHsMeYi6G9eaV5N_O8YssY+L7qwYnih3x9KC9w@mail.gmail.com>
Date:	Thu, 23 Jul 2015 09:49:23 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	X86 ML <x86@...nel.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Getting rid of invalid SYSCALL RSP under Xen?

Hi-

In entry_64.S, we have:

ENTRY(entry_SYSCALL_64)
    /*
     * Interrupts are off on entry.
     * We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON,
     * it is too small to ever cause noticeable irq latency.
     */
    SWAPGS_UNSAFE_STACK
    /*
     * A hypervisor implementation might want to use a label
     * after the swapgs, so that it can do the swapgs
     * for the guest and jump here on syscall.
     */
GLOBAL(entry_SYSCALL_64_after_swapgs)

    movq    %rsp, PER_CPU_VAR(rsp_scratch)
    movq    PER_CPU_VAR(cpu_current_top_of_stack), %rsp

It would be really, really nice if Xen entered the SYSCALL path
*after* the mov to %rsp.

Similarly, we have:

    movq    RSP(%rsp), %rsp
    /* big comment */
    USERGS_SYSRET64

It would be really nice if we could just mov to %rsp, swapgs, and
sysret, without worrying that the sysret is actually a jump on Xen.

I suspect that making Xen stop using these code paths would actually
be a simplification.  On SYSCALL entry, Xen lands in
xen_syscall_target (AFAICT) and clearly has rsp pointing somewhere
valid.  Xen obligingly shoves the user RSP into the hardware RSP
register and jumps into the entry code.

Is that stuff running on the normal kernel stack?  If so, can we just
enter later on:

    pushq    %r11                /* pt_regs->flags */
    pushq    $__USER_CS            /* pt_regs->cs */
    pushq    %rcx                /* pt_regs->ip */

<-- Xen enters here

    pushq    %rax                /* pt_regs->orig_ax */
    pushq    %rdi                /* pt_regs->di */
    pushq    %rsi                /* pt_regs->si */
    pushq    %rdx                /* pt_regs->dx */

For SYSRET, I think the way to go is to force Xen to always use the
syscall slow path.  Instead, Xen could hook into
syscall_return_via_sysret or even right before the opportunistic
sysret stuff.  Then we could remove the USERGS_SYSRET hooks entirely.

Would this work?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/