lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160512065040.GC30717@gmail.com>
Date:	Thu, 12 May 2016 08:50:40 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
Cc:	linux-kernel@...r.kernel.org, dave.hansen@...ux.intel.com,
	luto@...capital.net, bp@...en8.de, brgerst@...il.com,
	dvlasenk@...hat.com, hpa@...or.com, torvalds@...ux-foundation.org,
	peterz@...radead.org, tglx@...utronix.de
Subject: Re: [PATCH] [v3] x86/mm/mpx: Work around MPX erratum SKD046


* Dave Hansen <dave@...1.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@...1.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@...ux.intel.com>
> Cc: Andy Lutomirski <luto@...capital.net>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Brian Gerst <brgerst@...il.com>
> Cc: Dave Hansen <dave@...1.net>
> Cc: Denys Vlasenko <dvlasenk@...hat.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Link: http://lkml.kernel.org/r/20160504205359.19DB7812@viggo.jf.intel.com
> Signed-off-by: Ingo Molnar <mingo@...nel.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ