From: David Woodhouse <dwmw2@infradead.org>
To: Tom Lendacky <thomas.lendacky@amd.com>,
tglx@linutronix.de, karahmed@amazon.de, x86@kernel.org,
kvm@vger.kernel.org, torvalds@linux-foundation.org,
pbonzini@redhat.com, linux-kernel@vger.kernel.org, bp@alien8.de,
peterz@infradead.org, jmattson@google.com, rkrcmar@redhat.com,
arjan.van.de.ven@intel.com, dave.hansen@intel.com,
mingo@kernel.org
Subject: Re: [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware
Date: Wed, 14 Feb 2018 16:11:17 +0000 [thread overview]
Message-ID: <1518624677.12890.143.camel@infradead.org> (raw)
In-Reply-To: <6e3610be-cdcb-5c5c-fecc-7c41f2ebda73@amd.com>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
On Wed, 2018-02-14 at 10:07 -0600, Tom Lendacky wrote:
> Shouldn't these writes to the MSR be just for the IBRS bit? The spec
> also defines the STIBP bit for this MSR, and if that bit had been set by
> BIOS for example, these writes will clear it. And who knows what future
> bits may be defined and how they'll be used.
We don't use STIBP. If one day we do decide to set it in userspace for
"sensitive" processes, if we're done having the debate about what those
are, then that seems unlikely to conflict what what this code is doing
anyway, as we would presumably *clear* it again on the way back into
the kernel.
I certainly don't want to add a read/modify/write cycle here just to
cope with some hypothetical future use case for STIBP, when there would
be better ways to cope.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]
next prev parent reply other threads:[~2018-02-14 16:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 13:44 [PATCH 0/4] Speculation control improvements David Woodhouse
2018-02-14 13:44 ` [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware David Woodhouse
2018-02-14 16:07 ` Tom Lendacky
2018-02-14 16:11 ` David Woodhouse [this message]
2018-02-14 16:36 ` Tom Lendacky
2018-02-14 16:53 ` David Woodhouse
2018-02-14 13:44 ` [PATCH 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs David Woodhouse
2018-02-14 13:44 ` [PATCH 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()" David Woodhouse
2018-02-14 13:44 ` [PATCH 4/4] x86/retpoline: Support retpoline build with Clang David Woodhouse
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=1518624677.12890.143.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=arjan.van.de.ven@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=jmattson@google.com \
--cc=karahmed@amazon.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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 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.