Received: by 10.223.176.46 with SMTP id f43csp1125394wra; Sat, 20 Jan 2018 11:25:32 -0800 (PST) X-Google-Smtp-Source: AH8x22400KsJopHJwsLXVOpSkIGL5BRWXgD6i4+5AU+ny54HfQ+yHoFAhzpP70V5kzH1ngQhkdOa X-Received: by 10.101.86.73 with SMTP id m9mr2802603pgs.70.1516476332600; Sat, 20 Jan 2018 11:25:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516476332; cv=none; d=google.com; s=arc-20160816; b=OSBH/iUJy3XSU5GjrX//aObXA6Y/BOzzuXnfTLDCJfcxjl0e68GuJpwxHnrpYHgWs0 wSTrHnfo31UCu3Et3iJussWxRvS6Yw4evyjwYRNtXLY/HSja3i9WKUPJCLd94FEIDMG6 bB0hN9TMj1xAH+Qxwvbtpp4wNO46cHN0tj4Iaq08PUeAarSWL6RyFjcKvk3rMbCdh/gO Tc+sB6c9jUAMB3RQ9qmzaCgIwQbcvXF0DmQkiRUJs9PhVSh88FaU3wedO04GsHoox+JK jW7ypX7/bRB/9iPziqicgTZR9VFqvnla5ov2q7k0e0QGdmX2i829hVgJBMCgkUZBfCIR VtUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=Nh0LhbQAsIBx3+xi207zOuNvtxGWBmmxqbbZv5pqXks=; b=dVfJp8VYkRFR2FZ3ToYw/L12Ue4pweLlNEULnap3XhSbVMObgvzwlcRqePdawbj/Od ccpSxomla+7og0KZHXzhQnPE3/7mUKQue4CXfJihw04dxkZmn7tW0pcoYAPsql98xoOF Q1s2xU2OpdN4s13TDR2cGl0QBAUiPGLxGcjNFclWE0rHh3vIU1GZsmkoGGTST40q11GT LEfArJHyii5eROhgJjG0JII/TlEQWQhvZ/ai7bvlBiSZgC2aO0J2Or4CF/9HXNxtVS57 QmIrk+T2/3HTponRuaV1A4NNDT+vS7Z4XAjHOUB13SOyo18ivTG2CkBU4aOpmVJXOwNF ldaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.de header.s=amazon201209 header.b=XUgQNNHJ; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k187si10748546pge.377.2018.01.20.11.25.11; Sat, 20 Jan 2018 11:25:32 -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=@amazon.de header.s=amazon201209 header.b=XUgQNNHJ; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932777AbeATTYO (ORCPT + 99 others); Sat, 20 Jan 2018 14:24:14 -0500 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:1106 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932246AbeATTXj (ORCPT ); Sat, 20 Jan 2018 14:23:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1516476219; x=1548012219; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=Nh0LhbQAsIBx3+xi207zOuNvtxGWBmmxqbbZv5pqXks=; b=XUgQNNHJWaZcw9TCJ9OAQc7cp7yUlEAjBGzIHcCmGH0kB5qeVUgSfXVx bSQ61pQid3kK0dBXHq87qg6ylytGgvgY6CvgpcH7o8+s3j2mLyL9RiQpD 2yqLORa1yzf0HVguK+wDj26oElNwfW7U42CYJBigtn/ymY7KSL95LoGRv 0=; X-IronPort-AV: E=Sophos;i="5.46,387,1511827200"; d="scan'208";a="588403210" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2018 19:23:38 +0000 Received: from u54e1ad5160425a4b64ea.ant.amazon.com (pdx2-ws-svc-lb17-vlan2.amazon.com [10.247.140.66]) by email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w0KJNUSV020637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Jan 2018 19:23:32 GMT Received: from u54e1ad5160425a4b64ea.ant.amazon.com (localhost [127.0.0.1]) by u54e1ad5160425a4b64ea.ant.amazon.com (8.15.2/8.15.2/Debian-3) with ESMTP id w0KJNSjJ005262; Sat, 20 Jan 2018 20:23:28 +0100 Received: (from karahmed@localhost) by u54e1ad5160425a4b64ea.ant.amazon.com (8.15.2/8.15.2/Submit) id w0KJNR1p005259; Sat, 20 Jan 2018 20:23:27 +0100 From: KarimAllah Ahmed To: linux-kernel@vger.kernel.org Cc: KarimAllah Ahmed , Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , David Woodhouse , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm@vger.kernel.org, x86@kernel.org Subject: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process Date: Sat, 20 Jan 2018 20:22:55 +0100 Message-Id: <1516476182-5153-5-git-send-email-karahmed@amazon.de> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1516476182-5153-1-git-send-email-karahmed@amazon.de> References: <1516476182-5153-1-git-send-email-karahmed@amazon.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Tim Chen Flush indirect branches when switching into a process that marked itself non dumpable. This protects high value processes like gpg better, without having too high performance overhead. Signed-off-by: Andi Kleen Signed-off-by: David Woodhouse Signed-off-by: KarimAllah Ahmed --- arch/x86/mm/tlb.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 304de7d..f64e80c 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -225,8 +225,19 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, * Avoid user/user BTB poisoning by flushing the branch predictor * when switching between processes. This stops one process from * doing Spectre-v2 attacks on another. + * + * As an optimization: Flush indirect branches only when + * switching into processes that disable dumping. + * + * This will not flush when switching into kernel threads. + * But it would flush when switching into idle and back + * + * It might be useful to have a one-off cache here + * to also not flush the idle case, but we would need some + * kind of stable sequence number to remember the previous mm. */ - indirect_branch_prediction_barrier(); + if (tsk && tsk->mm && get_dumpable(tsk->mm) != SUID_DUMP_USER) + indirect_branch_prediction_barrier(); if (IS_ENABLED(CONFIG_VMAP_STACK)) { /* -- 2.7.4