From: Ingo Molnar <mingo@kernel.org>
To: Dave Hansen <dave@sr71.net>
Cc: linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com,
luto@amacapital.net, bp@alien8.de, brgerst@gmail.com,
dvlasenk@redhat.com, hpa@zytor.com,
torvalds@linux-foundation.org, peterz@infradead.org,
tglx@linutronix.de
Subject: Re: [PATCH] [v3] x86/mm/mpx: Work around MPX erratum SKD046
Date: Thu, 12 May 2016 08:50:40 +0200 [thread overview]
Message-ID: <20160512065040.GC30717@gmail.com> (raw)
In-Reply-To: <20160511211654.11D611C6@viggo.jf.intel.com>
* Dave Hansen <dave@sr71.net> wrote:
>
> Changes from v1:
> * Unconditionally enable workaround on all CPUs with MPX despite
> whether we know it to be affected or not
> * Add a pr_warn() when the workaround is active
>
> Changes from v2:
> * fix build breakage from #ifdefs in bug.h
>
> --
>
> From: Dave Hansen <dave@sr71.net>
>
> This erratum essentially causes the CPU to forget which privilege
> level it is operating on (kernel vs. user) for the purposes of MPX.
>
> This erratum can only be triggered when a system is not using
> Supervisor Mode Execution Prevention (SMEP). Our workaround for
> the erratum is to ensure that MPX can only be used in cases where
> SMEP is present in the processor and is enabled.
>
> This erratum only affects Core processors. Atom is unaffected.
> But, there is no architectural way to determine Atom vs. Core.
> So, we just apply this workaround to all processors. It's
> possible that it will mistakenly disable MPX on some Atom
> processsors or future unaffected Core processors. There are
> currently no processors that have MPX and not SMEP. It would
> take something akin to a hypervisor masking SMEP out on an Atom
> processor for this to present itself on current hardware.
>
> More details can be found at:
>
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf
>
> "
> SKD046 Branch Instructions May Initialize MPX Bound Registers Incorrectly
>
> Problem:
>
> Depending on the current Intel MPX (Memory Protection
> Extensions) configuration, execution of certain branch
> instructions (near CALL, near RET, near JMP, and Jcc
> instructions) without a BND prefix (F2H) initialize the MPX bound
> registers. Due to this erratum, such a branch instruction that is
> executed both with CPL = 3 and with CPL < 3 may not use the
> correct MPX configuration register (BNDCFGU or BNDCFGS,
> respectively) for determining whether to initialize the bound
> registers; it may thus initialize the bound registers when it
> should not, or fail to initialize them when it should.
>
> Implication:
>
> A branch instruction that has executed both in user mode and in
> supervisor mode (from the same linear address) may cause a #BR
> (bound range fault) when it should not have or may not cause a
> #BR when it should have. Workaround An operating system can
> avoid this erratum by setting CR4.SMEP[bit 20] to enable
> supervisor-mode execution prevention (SMEP). When SMEP is
> enabled, no code can be executed both with CPL = 3 and with CPL < 3.
> "
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Brian Gerst <brgerst@gmail.com>
> Cc: Dave Hansen <dave@sr71.net>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Link: http://lkml.kernel.org/r/20160504205359.19DB7812@viggo.jf.intel.com
> Signed-off-by: Ingo Molnar <mingo@kernel.org>
> ---
>
> b/arch/x86/include/asm/bugs.h | 6 ++++++
> b/arch/x86/kernel/cpu/common.c | 3 +++
> b/arch/x86/kernel/cpu/intel.c | 37 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 46 insertions(+)
>
> diff -puN arch/x86/include/asm/bugs.h~x86-mm-mpx-Work-around-MPX-erratum-SKD046 arch/x86/include/asm/bugs.h
> --- a/arch/x86/include/asm/bugs.h~x86-mm-mpx-Work-around-MPX-erratum-SKD046 2016-05-11 12:54:09.926505090 -0700
> +++ b/arch/x86/include/asm/bugs.h 2016-05-11 12:55:41.213689895 -0700
> @@ -3,6 +3,12 @@
>
> extern void check_bugs(void);
>
> +#if defined(CONFIG_CPU_SUP_INTEL)
> +void check_mpx_erratum(struct cpuinfo_x86 *c);
> +#else
> +static inline void check_mpx_erratum(struct cpuinfo_x86 *c) {}
> +#endif
> +
> #if defined(CONFIG_CPU_SUP_INTEL) && defined(CONFIG_X86_32)
> int ppro_with_ram_bug(void);
> #else
> diff -puN arch/x86/kernel/cpu/common.c~x86-mm-mpx-Work-around-MPX-erratum-SKD046 arch/x86/kernel/cpu/common.c
> --- a/arch/x86/kernel/cpu/common.c~x86-mm-mpx-Work-around-MPX-erratum-SKD046 2016-05-11 12:54:09.928505181 -0700
> +++ b/arch/x86/kernel/cpu/common.c 2016-05-11 12:54:09.933505411 -0700
> @@ -37,6 +37,7 @@
> #include <asm/mtrr.h>
> #include <linux/numa.h>
> #include <asm/asm.h>
> +#include <asm/bugs.h>
> #include <asm/cpu.h>
> #include <asm/mce.h>
> #include <asm/msr.h>
> @@ -270,6 +271,8 @@ static inline void squash_the_stupid_ser
> static __init int setup_disable_smep(char *arg)
> {
> setup_clear_cpu_cap(X86_FEATURE_SMEP);
> + /* Check for things that depend on SMEP being enabled: */
> + check_mpx_erratum(&boot_cpu_data);
> return 1;
> }
> __setup("nosmep", setup_disable_smep);
> diff -puN arch/x86/kernel/cpu/intel.c~x86-mm-mpx-Work-around-MPX-erratum-SKD046 arch/x86/kernel/cpu/intel.c
> --- a/arch/x86/kernel/cpu/intel.c~x86-mm-mpx-Work-around-MPX-erratum-SKD046 2016-05-11 12:54:09.930505273 -0700
> +++ b/arch/x86/kernel/cpu/intel.c 2016-05-11 12:54:09.934505457 -0700
> @@ -25,6 +25,41 @@
> #include <asm/apic.h>
> #endif
>
> +/*
> + * Just in case our CPU detection goes bad, or you have a weird system,
> + * allow a way to override the automatic disabling of MPX.
> + */
> +static int forcempx;
> +
> +static int __init forcempx_setup(char *__unused)
> +{
> + forcempx = 1;
> +
> + return 1;
> +}
> +__setup("intel-skd-046-workaround=disable", forcempx_setup);
I've done a s/forcempx/force_mpx/ (readable variable names are cheap!), but
otherwise this patch is looking good to me and I'll try to get it to Linus later
today.
Thanks,
Ingo
next prev parent reply other threads:[~2016-05-12 6:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-11 21:16 [PATCH] [v3] x86/mm/mpx: Work around MPX erratum SKD046 Dave Hansen
2016-05-12 6:50 ` Ingo Molnar [this message]
2016-05-12 7:16 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2016-05-04 20:53 [PATCH] [v2] x86, mpx: Workaround for MPX erratum Dave Hansen
2016-05-05 7:01 ` [PATCH v3] x86/mm/mpx: Work around MPX erratum SKD046 Ingo Molnar
2016-05-05 7:26 ` Ingo Molnar
2016-05-05 17:03 ` Dave Hansen
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=20160512065040.GC30717@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@sr71.net \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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