From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Tim Chen <tim.c.chen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <gregkh@linuxfoundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Andi Kleen <ak@linux.intel.com>,
Arjan Van De Ven <arjan.van.de.ven@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts
Date: Fri, 5 Jan 2018 12:27:28 +0000 [thread overview]
Message-ID: <20180105122727.GD2491@work-vm> (raw)
> Dave Hansen <dave.hansen@intel.com> wrote:
>> On 01/04/2018 08:51 PM, Andy Lutomirski wrote:
>> > Do we need an arch_prctl() to enable IBRS for user mode?
>>
>> Eventually, once the dust settles. I think there's a spectrum of
>> paranoia here, that is roughly (with increasing paranoia):
>>
>> 1. do nothing
>> 2. do retpoline
>> 3. do IBRS in kernel
>> 4. do IBRS always
>>
>> I think you're asking for ~3.5.
>>
>> Patches for 1-3 are out there and 4 is pretty straightforward. Doing a
>> arch_prctl() is still straightforward, but will be a much more niche
>> thing than any of the other choices. Plus, with a user interface, we
>> have to argue over the ABI for at least a month or two. ;)
I was chatting to Andrea about this, and we came to the conclusion one
use might be for qemu; I was worried about (theoretically) whether
userspace in a guest could read privileged data from the guest kernel by
attacking the qemu process rather than by attacking the kernels.
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next reply other threads:[~2018-01-05 12:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-05 12:27 Dr. David Alan Gilbert [this message]
2018-01-05 18:00 ` [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts Dave Hansen
-- strict thread matches above, loose matches on Subject: below --
2018-01-04 17:56 [PATCH 0/7] IBRS patch series Tim Chen
2018-01-04 17:56 ` [PATCH 3/7] x86/enter: Use IBRS on syscall and interrupts Tim Chen
2018-01-04 20:00 ` Greg KH
2018-01-04 20:26 ` Tim Chen
2018-01-04 20:45 ` Dave Hansen
2018-01-04 22:33 ` Peter Zijlstra
2018-01-04 23:12 ` Andrea Arcangeli
2018-01-05 0:08 ` Dave Hansen
2018-01-05 4:51 ` Andy Lutomirski
2018-01-05 5:11 ` Dave Hansen
2018-01-05 12:01 ` Alan Cox
2018-01-05 13:35 ` Thomas Gleixner
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=20180105122727.GD2491@work-vm \
--to=dgilbert@redhat.com \
--cc=84a6f2f2-d5fe-6b42-0590-33723c1b4960@intel.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=dave.hansen@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.org \
/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