From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux@dominikbrodowski.net>
X-Google-Smtp-Source: AH8x226RPLCKc7M/iNFKFeZyisYv21LUmx9P8Io+fj5GT6JY654DUZ788KKwJMFb9Ym6ynSQZvyq
ARC-Seal: i=1; a=rsa-sha256; t=1516727242; cv=none;
        d=google.com; s=arc-20160816;
        b=TI9/k85N5RrxluDU1n0Mz3fRDwdpPe3VtvamKze80rHluTEyLXH11Eymk+3SeWUp5T
         jgv4BfZ+wj8z30mUnUgS/emZMnzfDZXs9CWHTK2TUZobpJ23pWTUBxgfL03+yI4wSWyb
         xx8MJGjXGvAryFHfprSh2QoClsoE7nXRxgsp5EuumSXvAl1rMGyzk2WI5OoNPJD7wkD+
         zl+1DDRwpFJKyJF7FsfMvLGjwVosILWtMtZG/9d2xPl/NhtNXvxYc70NSp3fA20wpb59
         90k2a35Te8AvKuq4E20dLqXKZXhVJnHsoctVZR1uJ5R6BUIP4yNqY3qQL67WLQy0JkdT
         jE/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :message-id:subject:cc:to:from:date:arc-authentication-results;
        bh=+iRzqr0vfwpJRoVw1ikayiIjTvxlUCEkiGIu/eRZU1c=;
        b=S9NEAdYBFH3CfctNrURMfBWd+LOM4QP+aGd546lIlFtseZgy9aa4+fuCBjyilZChdP
         +JLu8rvL0F+SpzIY/BE0iADSNLEimdRKlUukfmgpqvtBcFonvpW4RtRWsWDdD/gowGqp
         vSWcu+WkzQOlOos4BWBFiJNP3PU5f02dq+NeGGvSqqARdlDq2Lx9jwpl+vHk2Pgti/0g
         HMuCuW8Vefg/vLbZjdQXIUGKQfajRl/Ee0nIQRHulgGGfrWMIpfjFCXpijGK45PV1zDg
         VreqgI+HXjT/ZvHgErVaVEUAilcFIHctJ1Z0aaDHAdqpybLrpjB7XF+/GMveG8Ow425k
         r9fA==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=neutral (google.com: 136.243.71.142 is neither permitted nor denied by best guess record for domain of linux@dominikbrodowski.net) smtp.mailfrom=linux@dominikbrodowski.net
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 136.243.71.142 is neither permitted nor denied by best guess record for domain of linux@dominikbrodowski.net) smtp.mailfrom=linux@dominikbrodowski.net
Date: Tue, 23 Jan 2018 18:07:19 +0100
From: Dominik Brodowski <linux@dominikbrodowski.net>
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	kvm@vger.kernel.org, Heiko Carstens <heiko.carstens@de.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jon Masters <jcm@redhat.com>, Marcus Meissner <meissner@suse.de>,
	Jiri Kosina <jkosina@suse.cz>, w@1wt.eu, keescook@chromium.org
Subject: Re: [PATCH 1/5] prctl: add PR_ISOLATE_BP process control
Message-ID: <20180123170719.GA4154@isilmar-4.linta.de>
References: <1516712825-2917-1-git-send-email-schwidefsky@de.ibm.com>
 <1516712825-2917-2-git-send-email-schwidefsky@de.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1516712825-2917-2-git-send-email-schwidefsky@de.ibm.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: =?utf-8?q?1590388677068788062?=
X-GMAIL-MSGID: =?utf-8?q?1590403784651087615?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On Tue, Jan 23, 2018 at 02:07:01PM +0100, Martin Schwidefsky wrote:
> Add the PR_ISOLATE_BP operation to prctl. The effect of the process
> control is to make all branch prediction entries created by the execution
> of the user space code of this task not applicable to kernel code or the
> code of any other task.

What is the rationale for requiring a per-process *opt-in* for this added
protection?

For KPTI on x86, the exact opposite approach is being discussed (see, e.g.
http://lkml.kernel.org/r/1515612500-14505-1-git-send-email-w@1wt.eu ): By
default, play it safe, with KPTI enabled. But for "trusted" processes, one
may opt out using prctrl.

Thanks,
	Dominik