mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Dominik Brodowski <linux@dominikbrodowski.net>,
	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>,
	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
Date: Wed, 24 Jan 2018 09:08:49 +0100	[thread overview]
Message-ID: <57cfefd8-53c1-9928-23fd-05a50350d0dc@de.ibm.com> (raw)
In-Reply-To: <20180123170719.GA4154@isilmar-4.linta.de>



On 01/23/2018 06:07 PM, Dominik Brodowski wrote:
> 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.

FWIW, this is not about KPTI. s390 always has the kernel in a separate address
space. Its only about potential spectre like attacks.
This idea is to be able to isolate in controlled environments, e.g. if you have
only one thread with untrusted code (e.g. jitting remote code). The property of 
the branch prediction mode on s390 is that it protects in two ways - against
being attacked but also against being able to attack via the btb.

  parent reply	other threads:[~2018-01-24  8:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 13:07 [RFC][PATCH 0/5] s390: improve speculative execution handling v2 Martin Schwidefsky
2018-01-23 13:07 ` [PATCH 1/5] prctl: add PR_ISOLATE_BP process control Martin Schwidefsky
2018-01-23 17:07   ` Dominik Brodowski
2018-01-24  6:29     ` Martin Schwidefsky
2018-01-24  8:37       ` Avoiding information leaks between users and between processes by default? [Was: : [PATCH 1/5] prctl: add PR_ISOLATE_BP process control] Dominik Brodowski
2018-01-24  9:24         ` David Woodhouse
2018-01-24 11:15         ` Pavel Machek
2018-01-24 12:48           ` Martin Schwidefsky
2018-01-24 19:01             ` Pavel Machek
2018-01-24 20:46               ` Alan Cox
2018-01-29 13:14                 ` Pavel Machek
2018-01-29 20:12                   ` Alan Cox
2018-01-24 15:42         ` Alan Cox
2018-01-24  8:08     ` Christian Borntraeger [this message]
2018-01-23 13:07 ` [PATCH 2/5] s390/alternative: use a copy of the facility bit mask Martin Schwidefsky
2018-01-23 13:59   ` Cornelia Huck
2018-01-23 14:40     ` Martin Schwidefsky
2018-01-23 15:04       ` Cornelia Huck
2018-01-23 13:07 ` [PATCH 3/5] s390: add options to change branch prediction behaviour for the kernel Martin Schwidefsky
2018-01-23 13:07 ` [PATCH 4/5] s390: define ISOLATE_BP to run tasks with modified branch prediction Martin Schwidefsky
2018-01-23 14:21   ` Christian Borntraeger
2018-01-23 20:32     ` Radim Krčmář
2018-01-24  6:36       ` Martin Schwidefsky
2018-01-24 11:50         ` Radim Krčmář
2018-01-23 13:07 ` [PATCH 5/5] s390: scrub registers on kernel entry and KVM exit Martin Schwidefsky
2018-01-23 13:09   ` Christian Borntraeger
2018-01-23 14:32     ` Martin Schwidefsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57cfefd8-53c1-9928-23fd-05a50350d0dc@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jcm@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=meissner@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®