From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
Heiko Carstens <heiko.carstens@de.ibm.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>
Subject: Re: [PATCH 4/5] s390: define ISOLATE_BP to run tasks with modified branch prediction
Date: Tue, 23 Jan 2018 21:32:24 +0100 [thread overview]
Message-ID: <20180123203223.GA648@flask> (raw)
In-Reply-To: <ac891f07-cd8d-83a6-0a16-cb99b69080e0@de.ibm.com>
2018-01-23 15:21+0100, Christian Borntraeger:
> Paolo, Radim,
>
> this patch not only allows to isolate a userspace process, it also allows us
> to add a new interface for KVM that would allow us to isolate a KVM guest CPU
> to no longer being able to inject branches in any host or other guests. (while
> at the same time QEMU and host kernel can run with full power).
> We just have to set the TIF bit TIF_ISOLATE_BP_GUEST for the thread that runs a
> given CPU. This would certainly be an addon patch on top of this patch at a later
> point in time.
I think that the default should be secure, so userspace will be
breaking the isolation instead of setting it up and having just one
place to screw up would be better -- the prctl could decide which
isolation mode to pick.
Maybe we can change the conditions and break logical connection between
TIF_ISOLATE_BP and TIF_ISOLATE_BP_GUEST, to make a separate KVM
interface useful.
> Do you think something similar would be useful for other architectures as well?
It goes against my idea of virtualization, but there probably are users
that don't care about isolation and still use virtual machines ...
I expect most architectures to have a fairly similar resolution of
branch prediction leaks, so the idea should be easily abstractable on
all levels. (At least x86 is.)
> In that case we should try to come up with a cross-architecture interface to enable
> that.
Makes me think of a generic VM control "prefer performance over
security", which would also take care of future problems and let arches
decide what is worth the code.
A main drawback is that this will introduce dynamic branches to the
code, which are going to slow down the common case to speed up a niche.
next prev parent reply other threads:[~2018-01-23 20:32 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 ` [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 20:32 ` Radim Krčmář [this message]
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=20180123203223.GA648@flask \
--to=rkrcmar@redhat.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=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=meissner@suse.de \
--cc=pbonzini@redhat.com \
--cc=schwidefsky@de.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).