Received: by 10.223.164.202 with SMTP id h10csp3354372wrb; Sat, 25 Nov 2017 07:01:48 -0800 (PST) X-Google-Smtp-Source: AGs4zMa9p/XEDUqzEjt4V2hwLec1TO+Vuhf5CEhJOCJT58NDv3rb5BP/wZ4uzVFgMCTnXqaky6/V X-Received: by 10.84.132.9 with SMTP id 9mr33075202ple.77.1511622108485; Sat, 25 Nov 2017 07:01:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511622108; cv=none; d=google.com; s=arc-20160816; b=T4zj4gN0jGkSvHlCr7voN/LDSeMkI+dD4WVDex0lEb6APRlf7x39JdTt7anpyNRfrj qLzXhiIB0Sk1pQrLQQxY1tmgBHjvXhwDW6N3UZE6TkIoet9xDHMasulMuvCKQa8rRF6/ g9qJUr6IWkzboXp67mXwdl3qIAFJcgnNYH08cFFNmbJIouKw5Q7hG7OEIEvPQS3POpnm 37Td4vvzuG6/GDfniAHr1eJ5TI6JN8nZvaiq6NBRHwIAuPQ7ksuHxQ5nXxzmqngUcurR xiPG/Ca5DQidY/W9uptjrfLZAO5ypmvzzjxxADZ+OsRAnE8hk69n0neUezjnbY441tiU t6pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=FIH3dp/RbMwDcaO6FFwDrbIClr2zbGU02qTFd7OH4M8=; b=YeY27aYzAx3Jeh1+NY/22FQ6wRx68e3sq4VU3A84D/9VeMWQffu6ljwt0/uKSRHBh7 MKhn/8ci5u4SmNGE2GW+sA/5YDpBgH+YKeZPI0ljdG54B8CjXtfH+naEyD5oBm3fM7Se z/fWQEZvArAlX2bWb9nraUUyWy3eLz9NVZWmiWSswRjbXbYLysNpg/8EFPRT/xBI42Vx UEKfIlJa5jWqNnwTKkWJZRVEebLNiLiRbTuXIud2uByzmir7r1x1sVr8tDRqLYMjBbRs syxxH0OxGHnCIt+NrCxXwQiEp8cM3dTkjVVZ+74X/8jJq2/l01aelmaPfqJ+CEPJ6kpf f2dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=byfwvTLS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 68si21821654pfx.6.2017.11.25.07.01.36; Sat, 25 Nov 2017 07:01:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=byfwvTLS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751776AbdKYPA7 (ORCPT + 79 others); Sat, 25 Nov 2017 10:00:59 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:43322 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751674AbdKYPA6 (ORCPT ); Sat, 25 Nov 2017 10:00:58 -0500 Received: by mail-io0-f194.google.com with SMTP id s37so21154412ioe.10 for ; Sat, 25 Nov 2017 07:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FIH3dp/RbMwDcaO6FFwDrbIClr2zbGU02qTFd7OH4M8=; b=byfwvTLSsf0fDd1XITFQaJUtCfmgvjBUmOb+joFAO86UqxeP1kftyZRhD5yqRcSa/b iCUzeD2bMCN7gUm1sSTg8MYl6CLvgDyX9MhBJJCpBfxbnR0lkU4Hk2RCY2nt6s+6d7vK zdcKmaX6hjslp3gTARQVBPPEJXDeI0GaRry+E3SUGjCdibNYZzOGEMkrog1bvE0eXtMx FJMy1WSkNLxoh+tQOgVpF3p/NRTWyVAhWbJIoJZvxsZXrlLa8QunNY75RtdCeb0P3v0d 5Vr+drcfdX+LRW1ojGawq+RCETtWA2M/6RqKlLdodHfktrZfRXM6EN0c6Nrgh/1l3FMq 7n/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FIH3dp/RbMwDcaO6FFwDrbIClr2zbGU02qTFd7OH4M8=; b=rCILj/aubY/iG1QfXJQONzTspVygmmgQt2Ju15vGGIi5qywZlHWHCcxQi1RaRh4uRh eB+AIrUGgmX+DZzFKWtWuIj/fbauffE3WmR9HwrDyQjkGSloZhloTNgGM69IMT91+uMb UG39l5Y7ZiGRRvqSAlbhTD69XQ4e8USENV9WYovxgcnlT/Im7MFLRlyyL/3+lbj88RzU uUpXFIuwFnx+fRulD7WvHCIgsR+dFenFUKuAnRMcBXeSjNzYNXwkOqVWv4FGYrXK5fnu Y/B6w/AwXzfl4NebSt+oyKm0rxx+Yl/IgBXSW92yTqzgt/2XyKiga3B9RxJNz29z0qNg 302w== X-Gm-Message-State: AJaThX79SSjby2FAdaWg8d4Xvpvk4VOTKV4QoAyWLBNnwZVsXop+oLOa HYil6NodOrgq4tMeV3EqGUvQtSj1E62L6OKaQUwvAA== X-Received: by 10.107.183.1 with SMTP id h1mr3541184iof.183.1511622057221; Sat, 25 Nov 2017 07:00:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.133.35 with HTTP; Sat, 25 Nov 2017 07:00:36 -0800 (PST) In-Reply-To: <20171125114043.f72547iiowbzyjvd@pd.tnic> References: <20171124172411.19476-1-mingo@kernel.org> <20171124172411.19476-16-mingo@kernel.org> <20171125114043.f72547iiowbzyjvd@pd.tnic> From: Andy Lutomirski Date: Sat, 25 Nov 2017 07:00:36 -0800 Message-ID: Subject: Re: [PATCH 15/43] x86/entry/64: Create a percpu SYSCALL entry trampoline To: Borislav Petkov Cc: Ingo Molnar , "linux-kernel@vger.kernel.org" , Dave Hansen , Thomas Gleixner , "H . Peter Anvin" , Peter Zijlstra , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 25, 2017 at 3:40 AM, Borislav Petkov wrote: > On Fri, Nov 24, 2017 at 06:23:43PM +0100, Ingo Molnar wrote: >> From: Andy Lutomirski >> >> Handling SYSCALL is tricky: the SYSCALL handler is entered with every >> single register (except FLAGS), including RSP, live. It somehow needs >> to set RSP to point to a valid stack, which means it needs to save the >> user RSP somewhere and find its own stack pointer. The canonical way >> to do this is with SWAPGS, which lets us access percpu data using the >> %gs prefix. >> >> With KAISER-like pagetable switching, this is problematic. Without a >> scratch register, switching CR3 is impossible, so %gs-based percpu >> memory would need to be mapped in the user pagetables. Doing that >> without information leaks is difficult or impossible. >> >> Instead, use a different sneaky trick. Map a copy of the first part >> of the SYSCALL asm at a different address for each CPU. Now RIP >> varies depending on the CPU, so we can use RIP-relative memory access >> to access percpu memory. By putting the relevant information (one >> scratch slot and the stack address) at a constant offset relative to >> RIP, we can make SYSCALL work without relying on %gs. >> >> A nice thing about this approach is that we can easily switch it on >> and off if we want pagetable switching to be configurable. >> >> The compat variant of SYSCALL doesn't have this problem in the first >> place -- there are plenty of scratch registers, since we don't care >> about preserving r8-r15. This patch therefore doesn't touch SYSCALL32 >> at all. >> >> XXX: Whenever we settle how KAISER gets turned on and off, we should do >> the same to this. >> >> Signed-off-by: Andy Lutomirski >> Signed-off-by: Thomas Gleixner >> Cc: Borislav Petkov >> Cc: Brian Gerst >> Cc: Dave Hansen >> Cc: Josh Poimboeuf >> Cc: Linus Torvalds >> Cc: Peter Zijlstra >> Link: https://lkml.kernel.org/r/b95ccae0a5a2f090c901e49fce7c9e8ff6acd40d.1511497875.git.luto@kernel.org >> Signed-off-by: Ingo Molnar >> --- >> arch/x86/entry/entry_64.S | 48 +++++++++++++++++++++++++++++++++++++++++++ >> arch/x86/include/asm/fixmap.h | 2 ++ >> arch/x86/kernel/asm-offsets.c | 1 + >> arch/x86/kernel/cpu/common.c | 12 ++++++++++- >> arch/x86/kernel/vmlinux.lds.S | 10 +++++++++ >> 5 files changed, 72 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S >> index 426b8c669d6a..0cde243b7542 100644 >> --- a/arch/x86/entry/entry_64.S >> +++ b/arch/x86/entry/entry_64.S >> @@ -140,6 +140,54 @@ END(native_usergs_sysret64) >> * with them due to bugs in both AMD and Intel CPUs. >> */ >> >> + .pushsection .entry_trampoline, "ax" >> + >> +/* >> + * The code in here gets remapped into cpu_entry_area's trampoline. This means >> + * that the assembler and linker have the wrong idea as to where this code >> + * lives (and, in fact, it's mapped more than once, so it's not even at a >> + * fixed address). So we can't reference any symbols outside the entry >> + * trampoline and expect it to work. >> + * >> + * Instead, we carefully abuse %rip-relative addressing. >> + * .Lentry_trampoline(%rip) refers to the start of the remapped) entry > > _entry_trampoline(%rip) I'd guess. Indeed. It used to be .L, but then I put it in the linker script the obvious way and it wasn't any more. > >> + * trampoline. We can thus find cpu_entry_area with this macro: > > Uuh, fun. :) That's what I thought! > >> + */ >> + >> +#define CPU_ENTRY_AREA \ >> + _entry_trampoline - CPU_ENTRY_AREA_entry_trampoline(%rip) > > So this generates > > _entry_trampoline - 16384(%rip) > > here. IINM, the layout looks like this > > [ GDT | TSS | TSS | TSS | trampoline ] > > where each section is a page, and we have 4 pages per CPU. Just for my > own understanding... Indeed. > >> + >> +/* The top word of the SYSENTER stack is hot and is usable as scratch space. */ >> +#define RSP_SCRATCH CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + \ >> + SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA > > I'm wondering if it would be easier to make SYSENTER_stack part of > struct cpu_entry_area and thus simplify that wild offset math here :) It's like that with the last patch that I haven't send out applied, actually :) > > Also, pls align: > > #define RSP_SCRATCH CPU_ENTRY_AREA_tss + CPU_TSS_SYSENTER_stack + \ > SIZEOF_SYSENTER_stack - 8 + CPU_ENTRY_AREA Done. > >> + >> +ENTRY(entry_SYSCALL_64_trampoline) >> + UNWIND_HINT_EMPTY >> + swapgs >> + >> + /* Stash the user RSP. */ >> + movq %rsp, RSP_SCRATCH >> + >> + /* Load the top of the task stack into RSP */ >> + movq CPU_ENTRY_AREA_tss + TSS_sp1 + CPU_ENTRY_AREA, %rsp > > Yeah, let's put CPU_ENTRY_AREA first because then it reads easier: > > movq CPU_ENTRY_AREA + CPU_ENTRY_AREA_tss + TSS_sp1, %rsp Nope, it won't build. That would expand like 0x1(%rip) + 0x2, which isn't valid. > > i.e., pointer to cpu_entry_area, offset to tss within said > cpu_entry_area and then inside that, sp1. > > Ditto for above. > > ... > >> @@ -1417,10 +1424,13 @@ static DEFINE_PER_CPU_PAGE_ALIGNED(char, exception_stacks >> /* May not be marked __init: used by software suspend */ >> void syscall_init(void) >> { >> + extern char _entry_trampoline[]; >> + extern char entry_SYSCALL_64_trampoline[]; >> + >> int cpu = smp_processor_id(); >> >> wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS); >> - wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64); >> + wrmsrl(MSR_LSTAR, (unsigned long)get_cpu_entry_area(cpu)->entry_trampoline + (entry_SYSCALL_64_trampoline - _entry_trampoline)); > > Definitely a local var. Done. > >> #ifdef CONFIG_IA32_EMULATION >> wrmsrl(MSR_CSTAR, (unsigned long)entry_SYSCALL_compat); >> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S >> index a4009fb9be87..2738cfb6c8c8 100644 >> --- a/arch/x86/kernel/vmlinux.lds.S >> +++ b/arch/x86/kernel/vmlinux.lds.S >> @@ -107,6 +107,16 @@ SECTIONS >> SOFTIRQENTRY_TEXT >> *(.fixup) >> *(.gnu.warning) >> + >> +#ifdef CONFIG_X86_64 >> + /* Entry trampoline */ > > No need for that comment - variable and section names are enough. :) > From 1585038077193889281@xxx Sat Nov 25 11:41:44 +0000 2017 X-GM-THRID: 1584969640732079338 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread