Re: [PATCH v7 24/26] x86: Enable User-Mode Instruction Prevention

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2017-06-09 at 18:10 +0200, Borislav Petkov wrote:
> On Fri, May 05, 2017 at 11:17:22AM -0700, Ricardo Neri wrote:
> > User_mode Instruction Prevention (UMIP) is enabled by setting/clearing a
> > bit in %cr4.
> > 
> > It makes sense to enable UMIP at some point while booting, before user
> > spaces come up. Like SMAP and SMEP, is not critical to have it enabled
> > very early during boot. This is because UMIP is relevant only when there is
> > a userspace to be protected from. Given the similarities in relevance, it
> > makes sense to enable UMIP along with SMAP and SMEP.
> > 
> > UMIP is enabled by default. It can be disabled by adding clearcpuid=514
> > to the kernel parameters.
> > 
> > Cc: Andy Lutomirski <luto@xxxxxxxxxx>
> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> > Cc: H. Peter Anvin <hpa@xxxxxxxxx>
> > Cc: Borislav Petkov <bp@xxxxxxx>
> > Cc: Brian Gerst <brgerst@xxxxxxxxx>
> > Cc: Chen Yucong <slaoub@xxxxxxxxx>
> > Cc: Chris Metcalf <cmetcalf@xxxxxxxxxxxx>
> > Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
> > Cc: Fenghua Yu <fenghua.yu@xxxxxxxxx>
> > Cc: Huang Rui <ray.huang@xxxxxxx>
> > Cc: Jiri Slaby <jslaby@xxxxxxx>
> > Cc: Jonathan Corbet <corbet@xxxxxxx>
> > Cc: Michael S. Tsirkin <mst@xxxxxxxxxx>
> > Cc: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Cc: Ravi V. Shankar <ravi.v.shankar@xxxxxxxxx>
> > Cc: Shuah Khan <shuah@xxxxxxxxxx>
> > Cc: Vlastimil Babka <vbabka@xxxxxxx>
> > Cc: Tony Luck <tony.luck@xxxxxxxxx>
> > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> > Cc: Liang Z. Li <liang.z.li@xxxxxxxxx>
> > Cc: Alexandre Julliard <julliard@xxxxxxxxxx>
> > Cc: Stas Sergeev <stsp@xxxxxxx>
> > Cc: x86@xxxxxxxxxx
> > Cc: linux-msdos@xxxxxxxxxxxxxxx
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@xxxxxxxxxxxxxxx>
> > ---
> >  arch/x86/Kconfig             | 10 ++++++++++
> >  arch/x86/kernel/cpu/common.c | 16 +++++++++++++++-
> >  2 files changed, 25 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 702002b..1b1bbeb 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1745,6 +1745,16 @@ config X86_SMAP
> >  
> >  	  If unsure, say Y.
> >  
> > +config X86_INTEL_UMIP
> > +	def_bool y
> 
> That's a bit too much. It makes sense on distro kernels but how many
> machines out there actually have UMIP?

So would this become a y when more machines have UMIP?
> 
> > +	depends on CPU_SUP_INTEL
> > +	prompt "Intel User Mode Instruction Prevention" if EXPERT
> > +	---help---
> > +	  The User Mode Instruction Prevention (UMIP) is a security
> > +	  feature in newer Intel processors. If enabled, a general
> > +	  protection fault is issued if the instructions SGDT, SLDT,
> > +	  SIDT, SMSW and STR are executed in user mode.
> > +
> >  config X86_INTEL_MPX
> >  	prompt "Intel MPX (Memory Protection Extensions)"
> >  	def_bool n
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index 8ee3211..66ebded 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -311,6 +311,19 @@ static __always_inline void setup_smap(struct cpuinfo_x86 *c)
> >  	}
> >  }
> >  
> > +static __always_inline void setup_umip(struct cpuinfo_x86 *c)
> > +{
> > +	if (cpu_feature_enabled(X86_FEATURE_UMIP) &&
> > +	    cpu_has(c, X86_FEATURE_UMIP))
> 
> Hmm, so if UMIP is not build-time disabled, the cpu_feature_enabled()
> will call static_cpu_has().
> 
> Looks like you want to call cpu_has() too because alternatives haven't
> run yet and static_cpu_has() will reply wrong. Please state that in a
> comment.

Why would static_cpu_has() reply wrong if alternatives are not in place?
Because it uses the boot CPU data? When it calls _static_cpu_has() it
would do something equivalent to

   testb test_bit, boot_cpu_data.x86_capability[bit].

I am calling cpu_has because cpu_feature_enabled(), via
static_cpu_has(), will use the boot CPU data while cpu_has would use the
local CPU data. Is this what you meant?

I can definitely add a comment with this explanation, if it makes sense.

Thanks and BR,
Ricardo

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Console]     [Linux Audio]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Camping]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Samba]     [Linux Media]     [Fedora Users]

  Powered by Linux