Received: by 10.223.176.5 with SMTP id f5csp2450202wra; Thu, 1 Feb 2018 00:26:33 -0800 (PST) X-Google-Smtp-Source: AH8x227XcvCBBkvF2yvNsPmhiHT1rnEmPTguvUafqraiFPP5+oEx5KVbpeS1HgqnS5KfgyFwDp3s X-Received: by 2002:a17:902:a983:: with SMTP id bh3-v6mr15427997plb.237.1517473593281; Thu, 01 Feb 2018 00:26:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517473593; cv=none; d=google.com; s=arc-20160816; b=0jI1K6oAM4muNPCfbPVVwKFmW4jtqlowoiE0POWbcDeJAhVnnEHxhA36ZKzmUY2eaw cpjkMiU3PqIJ5JOlUqQ+WLFBdL38HvGdyg/ChdutnpHEZo/f0NbI/mduExFYifvGJ1x0 Y5mOuWJJlKWvDmZRdVGSBm2op1uTCWWt2kKWMfOw7aOF9IZ3DWIA2BrrlNc8HMgBNkPZ d3Ws94xCzmpsAxMD1qOPxYz2ybD+8MMpDDCB4WAVuQ68NmjnZXxXAVmaEYlVMImebo6E aHdazBzBLm61rB7926Vr3xN2rI76f6KkDH97QrWFrrtjjQLSLfT72zVQj226a2pDr2Gh smNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=tX3xkdMoGCvb9nm80U/BmB6XhZe5GEyql8Mf5y6EFbU=; b=UGytsVqDfCNbV07kfyXi14uj9mE9fkiq7/+fIb1oDQ/jfIQCj95YsCUWw1ceLBV12a bp8S/iwfP8hpfHom+dd8WLsIsnXG5zuKn8wSW48fmGoTbb57YZvlyTKQZYL3b//0IHrH lhEyxtQvfP62KlBji9DNGiYINUW6wqiEWLVy29D2/9eIoNRFFDLaqTwYfha7s/685Tkr ivOUBkBvaQqBKsjKA046rEyVPff5QKxHEtov0YJbLUmyN/EAeSG0oo7MTZatYzazHgOx 7dkSo10ZCD1V8BXD+YfZRwkWP6lY9k4cFnsPjG2cOj9hriu1HajGhJjtrLDSul9WlpJj bTww== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q21si1123970pgn.250.2018.02.01.00.26.18; Thu, 01 Feb 2018 00:26:33 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751936AbeBAIZ0 (ORCPT + 99 others); Thu, 1 Feb 2018 03:25:26 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:35144 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeBAIZX (ORCPT ); Thu, 1 Feb 2018 03:25:23 -0500 Received: from mail-wm0-f72.google.com ([74.125.82.72]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ehABO-0004nE-Md for linux-kernel@vger.kernel.org; Thu, 01 Feb 2018 08:25:22 +0000 Received: by mail-wm0-f72.google.com with SMTP id t14so1403677wmc.5 for ; Thu, 01 Feb 2018 00:25:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tX3xkdMoGCvb9nm80U/BmB6XhZe5GEyql8Mf5y6EFbU=; b=a7Lads9qvzmjlAzsjCCzl9LRdTIyA85jtRanFEVa8Nw6QD3TxURDeytgkxIWpjR0ZH qSDcP7rCwFRgU3KfIsDQc1bmkKTryAbVeofPZxI1YQEMAmsu2C7c3ASSOaS6jzCynJqq wF4ls9LjqRMs9kDY65wT+LeCZc9e6++4/UiMQS8bYLNgvicd8kYlB1mTJ2PLWmDUmHpt YPxvC8Tk4gWy4lQWD16AnX40CvF6xcYLr/LRAl085zEkL/PusiiSW2wi4GaBGtdzfnLW aQVNIIJ5QwF9aq95alnm6lbQJrGXIlybU3edIISyq96so3WwzdaaLhSxkbnQpaWOEP5m 5fZw== X-Gm-Message-State: AKwxytd3KW4MuMd354+he0Wrqxk4aBrmQ6ajqtrl8usZr6/JgjEoNaQS YAtecsWYXxbajdIo9n6ALC02niGVSbtLb9ofdwnXgvFH+sef+ABj3Je0/bRPOHe8om+z0IrGHdM 3X7cjosiFqtQK/0cGG43eRVKsnQZERGr1dPOKJByU4w== X-Received: by 10.80.139.2 with SMTP id l2mr61083056edl.14.1517473522202; Thu, 01 Feb 2018 00:25:22 -0800 (PST) X-Received: by 10.80.139.2 with SMTP id l2mr61083044edl.14.1517473521982; Thu, 01 Feb 2018 00:25:21 -0800 (PST) Received: from gmail.com (84-199-88-155.iFiber.telenet-ops.be. [84.199.88.155]) by smtp.gmail.com with ESMTPSA id d21sm10041005edb.13.2018.02.01.00.25.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 01 Feb 2018 00:25:21 -0800 (PST) Date: Thu, 1 Feb 2018 09:25:20 +0100 From: Christian Brauner To: Dominik Brodowski Cc: mingo@kernel.org, hpa@zytor.com, tim.c.chen@linux.intel.com, dwmw@amazon.co.uk, linux-kernel@vger.kernel.org, tglx@linutronix.de, jpoimboe@redhat.com Subject: Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch Message-ID: <20180201082518.w3bk5udvzdre7zc2@gmail.com> References: <1517263487-3708-1-git-send-email-dwmw@amazon.co.uk> <20180131070300.GA28206@light.dominikbrodowski.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180131070300.GA28206@light.dominikbrodowski.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 31, 2018 at 08:03:00AM +0100, Dominik Brodowski wrote: > On Tue, Jan 30, 2018 at 02:39:45PM -0800, tip-bot for Tim Chen wrote: > > Commit-ID: 18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 > > Gitweb: https://git.kernel.org/tip/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7 > > Author: Tim Chen > > AuthorDate: Mon, 29 Jan 2018 22:04:47 +0000 > > Committer: Thomas Gleixner > > CommitDate: Tue, 30 Jan 2018 23:09:21 +0100 > > > > x86/speculation: Use Indirect Branch Prediction Barrier in context switch > > > > 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. > > For the record, I am still opposed to limit this to non-dumpable processes. > Whether a process needs protection by IBPB on context switches is a > different question to whether a process should be allowed to be dumped, This is especially true since you can get into a non-dumpable state implicitly due to setuid() in a new user namespace. So avoiding the performance hit due to IBPD is not necessary a concious decision taken by calling prctl(), that is to say even if you care about performance and don't want to take the IBPB hit you might accidently have to take it when doing a setuid(). Also there are definitely workloads where you want to be able to ptrace a task while at the same time having it do IBPB. So let's not limit this to non-dumpable taks! Thanks Dominik! > though the former may be a superset of the latter. In my opinion, IBPB > should be enabled on all context switches to userspace processes, until we > have a clear mitigation strategy for userspace against Spectre-v2 designed > and implemented. > > Thanks, > Dominik > > -------------------------- > From: Dominik Brodowski > Date: Wed, 31 Jan 2018 07:43:12 +0100 > Subject: [PATCH] x86/speculation: Do not limit Indirect Branch Prediction Barrier to non-dumpable processes > > Whether a process needs protection by IBPB on context switches is a > different question to whether a process should be allowed to be dumped, > though the former may be a superset of the latter. Enable IBPB on all > context switches to a different userspace process, until we have a clear > mitigation strategy for userspace against Spectre-v2 designed and > implemented. Thanks Dominik. That makes a lot more sense! > > Signed-off-by: Dominik Brodowski > > diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c > index 012d02624848..f54897b68b16 100644 > --- a/arch/x86/mm/tlb.c > +++ b/arch/x86/mm/tlb.c > @@ -255,19 +255,13 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next, > * 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 > - * protects high value processes like gpg, without having > - * too high performance overhead. IBPB is *expensive*! > - * > * This will not flush branches when switching into kernel > * threads. It will also not flush if we switch to idle > * thread and back to the same process. It will flush if we > - * switch to a different non-dumpable process. > + * switch to a different user process. > */ > if (tsk && tsk->mm && > - tsk->mm->context.ctx_id != last_ctx_id && > - get_dumpable(tsk->mm) != SUID_DUMP_USER) > + tsk->mm->context.ctx_id != last_ctx_id) > indirect_branch_prediction_barrier(); > > if (IS_ENABLED(CONFIG_VMAP_STACK)) {