Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5006174imm; Sun, 22 Jul 2018 10:47:20 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdlhUKN8Q75Sd3xFop79ppRN56aEsv6pJJVmMoWODQfsI6ux/6H7xFeyfQyG/zxGOtjxQdx X-Received: by 2002:a17:902:4381:: with SMTP id j1-v6mr9882176pld.104.1532281640013; Sun, 22 Jul 2018 10:47:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532281639; cv=none; d=google.com; s=arc-20160816; b=gbUMAQUt9dDt4SQ+0C7PPPMFYPz2qYC1YC+EBTPuxmBSI4Ca8NvrUCXkEy4fbd7Dom 1wMJonwOWnyIDuA1NjKaDoCwhd0+Hl0k0S8OkIB/YfB1dEaBk++9P9BoOfXGOnBk3+Bx 3tkz89QjCWlum9BX6Ml/jaIZeSICw/lZcHtRCCSdn873D+guMyBNfeWTHBQUQbbqe5P4 S18l8W3O1ui7WF+fRMvA/Tp2L9vsRvP/4t/popk9XUIuESTXv5Gd7S/g2hnQkGT3D18p +go02hASdhNAvttkKs7Z/IiNtocEmkR3dxWHttt7G3nCZ+oz5YUWaCU1b7tTTSXtNoC6 Wh1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=SP8rpi86XbN7TGNprYb/iCoHTK+ZLeYBxTziZ1wpC9w=; b=oRuVcLgnP2vx5IIOMS0e7YQjxqbWpERZpfl5/Q6n7q4k/aAT310XHIH8QT29arzVhv Y+lyIx3GpzF84dhAZM//DJE+MkyZbwLD02pNFlJZxtZWzbzHjfoFvPCULgVNPPhkMr0g fK7wMQfFDs2m9cmpFfcCnHt4Zlwrk08YnRh35rk9OfUF2DLl7piw+wesNn568UnIw2wL rvOEoaioJ1O5YogKt1zh2B0IsbZikthXHxGDL3YBh52jocjtGN+spZZ61ky/k8L4x5fG 3YHHkkActXxSOWvUrrgldMw6mX5szmqTeVic3/Snedd+Ld1E28pvzd9FIgNS/aBFDyUr zSGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=nmGTz6Ix; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d124-v6si6444695pfg.366.2018.07.22.10.47.05; Sun, 22 Jul 2018 10:47:19 -0700 (PDT) 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=@kernel.org header.s=default header.b=nmGTz6Ix; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730144AbeGVSnB (ORCPT + 99 others); Sun, 22 Jul 2018 14:43:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:56188 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729890AbeGVSnB (ORCPT ); Sun, 22 Jul 2018 14:43:01 -0400 Received: from localhost (c-71-202-137-17.hsd1.ca.comcast.net [71.202.137.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1A26720854; Sun, 22 Jul 2018 17:45:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1532281535; bh=bd9EEdys5rQAjVLXugcrnTezGdh8ABa5hs8bMUe7Dmo=; h=From:To:Cc:Subject:Date:From; b=nmGTz6IxZk0SZMZCFYUFD1UcRQvxkuplMe6OZ6Vq9qsTlixIjSGttuovRI7BEEjSz p5zOomYtmgerCl/A41sx7mtZsKJY03u5YspPHjEHeUO2aKERJS9j6BpooCfAjZ/o39 K8WF/gCfEMyDlxH0fSztZHlEXrKNvlDJd/lNZPA0= From: Andy Lutomirski To: x86@kernel.org, LKML Cc: Borislav Petkov , Linus Torvalds , Dave Hansen , Andy Lutomirski Subject: [RFC 0/2] Get rid of the entry trampoline Date: Sun, 22 Jul 2018 10:45:25 -0700 Message-Id: X-Mailer: git-send-email 2.17.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all- I think there's general agreement that the current entry trampoline sucks, mainly because it's dog-slow. Thanks, Spectre. There are three possible fixes I know of: a) Linus' hack: use R11 for scratch space. This doesn't actually speed it up, but it improves the addressing situation a bit. I don't like it, though: it causes the SYSCALL64 path to forget the arithmetic flags and all of the MSR_SYCALL_MASK flags. The latter may be a showstopper, given that we've seen some evidence of nasty Wine use cases that expect setting EFLAGS.NT and doing a system call to actually do something intelligent. Similarly, there could easily be user programs out there that set AC because they want alignment checking and expect AC to remain set across system calls. b) Move the trampoline within 2G of the entry text and copy it for each CPU. This is certainly possible, but it's a bit gross, and it uses num_possible_cpus() * 64 bytes of memory (rounded up to a page). It will also result in more complicated code. c) This series. Just make %gs work in the entry trampoline. It's actually a net code deletion. I suspect that (b) would be faster in code that does a lot of system calls and doesn't totally blow away the cache or the TLB between system calls. I suspect that (c) is faster in code that does cache-cold system calls. Andy Lutomirski (2): x86/entry/64: Use the TSS sp2 slot for rsp_scratch x86/pti/64: Remove the SYSCALL64 entry trampoline arch/x86/entry/entry_64.S | 66 +----------------------------- arch/x86/include/asm/processor.h | 5 +++ arch/x86/include/asm/thread_info.h | 1 + arch/x86/kernel/asm-offsets_64.c | 1 + arch/x86/kernel/cpu/common.c | 11 +---- arch/x86/kernel/kprobes/core.c | 10 +---- arch/x86/kernel/process_64.c | 2 - arch/x86/kernel/vmlinux.lds.S | 10 ----- arch/x86/mm/cpu_entry_area.c | 5 --- arch/x86/mm/pti.c | 24 ++++++++++- 10 files changed, 33 insertions(+), 102 deletions(-) -- 2.17.1