[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180123170719.GA4154@isilmar-4.linta.de>
Date: Tue, 23 Jan 2018 18:07:19 +0100
From: Dominik Brodowski <linux@...inikbrodowski.net>
To: Martin Schwidefsky <schwidefsky@...ibm.com>
Cc: linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
kvm@...r.kernel.org, Heiko Carstens <heiko.carstens@...ibm.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Cornelia Huck <cohuck@...hat.com>,
David Hildenbrand <david@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jon Masters <jcm@...hat.com>,
Marcus Meissner <meissner@...e.de>,
Jiri Kosina <jkosina@...e.cz>, w@....eu, keescook@...omium.org
Subject: Re: [PATCH 1/5] prctl: add PR_ISOLATE_BP process control
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
Powered by blists - more mailing lists