From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Dominik Brodowski <linux@dominikbrodowski.net>
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
Date: Wed, 24 Jan 2018 07:29:53 +0100 [thread overview]
Message-ID: <20180124072953.50851fec@mschwideX1> (raw)
In-Reply-To: <20180123170719.GA4154@isilmar-4.linta.de>
On Tue, 23 Jan 2018 18:07:19 +0100
Dominik Brodowski <linux@dominikbrodowski.net> 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.
The rationale is that there are cases where you got code from *somewhere*
and want to run it in an isolated context. Think: a docker container that
runs under KVM. But with spectre this is still not really safe. So you
include a wrapper program in the docker container to use the trap door
prctl to start the potential malicious program. Now you should be good, no?
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2018-01-24 6:29 UTC|newest]
Thread overview: 28+ 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 [this message]
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 ` [PATCH 1/5] prctl: add PR_ISOLATE_BP process control Christian Borntraeger
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 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=20180124072953.50851fec@mschwideX1 \
--to=schwidefsky@de.ibm.com \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.