From: Dave Hansen <dave.hansen@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] [RFC] x86: work around MPX Erratum
Date: Tue, 3 May 2016 14:28:18 -0700 [thread overview]
Message-ID: <572917F2.2060302@intel.com> (raw)
In-Reply-To: <20160503211202.GA27604@pd.tnic>
On 05/03/2016 02:12 PM, Borislav Petkov wrote:
> On Tue, May 03, 2016 at 02:04:40PM -0700, Dave Hansen wrote:
>> My concern was not necessarily with folks booting with 'nosmep', but
>
> Btw, does anything speak for even keeping that 'nosmep' thing?
Generally, I'm not sure we need the no$foo options at all. There's
always "clearcpuid=" which does the same thing. It just requires you to
go look up the X86_FEATURE_* bit first.
>> with processors that have MPX present and SMEP fused off (or made
>> unavailable by a hypervisor) and which are unaffected by this issue.
>
> So we won't init MPX on those...
Yes, and as long as such a processor doesn't exist today and never
exists in the future or the folks that buy such a processor truly don't
care about MPX, that's fine to do. I'm just a bit nervous about the
whole "never exists in the future" part.
>> People would have to be very careful to never create a processor which
>> did not have SMEP but did have MPX, since MPX would effectively be
>> unusable on such a processor.
>
> We can disable that combination in qemu too, right?
What do you mean by disable? Have qemu error out if MPX and SMEP aren't
disabled in concert with each other?
next prev parent reply other threads:[~2016-05-03 21:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 22:03 [PATCH] [RFC] x86: work around MPX Erratum Dave Hansen
2016-05-03 6:43 ` Ingo Molnar
2016-05-03 21:04 ` Dave Hansen
2016-05-03 21:12 ` Borislav Petkov
2016-05-03 21:28 ` Dave Hansen [this message]
2016-05-03 21:33 ` Linus Torvalds
2016-05-03 21:45 ` Borislav Petkov
2016-05-03 21:31 ` Andy Lutomirski
2016-05-03 21:39 ` Linus Torvalds
2016-05-03 21:44 ` Andy Lutomirski
2016-05-03 21:43 ` Dave Hansen
2016-05-03 21:53 ` Andy Lutomirski
2016-05-04 6:44 ` Ingo Molnar
2016-05-05 17:14 ` Andy Lutomirski
2016-05-05 18:40 ` Ingo Molnar
2016-05-06 19:01 ` Andy Lutomirski
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=572917F2.2060302@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox