Re: [PATCH v7 24/26] x86: Enable User-Mode Instruction Prevention
On Tue, Jul 25, 2017 at 05:44:08PM -0700, Ricardo Neri wrote: > 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. ... > So would this become a y when more machines have UMIP? I guess. Stuff which proves reliable and widespread gets automatically enabled with time, in most cases. IMHO, of course. > 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 Nevermind - I forgot that static_cpu_has() now drops to dynamic check before alternatives application. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 24/26] x86: Enable User-Mode Instruction Prevention
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> > Cc: Andrew Morton > > Cc: H. Peter Anvin > > Cc: Borislav Petkov > > Cc: Brian Gerst > > Cc: Chen Yucong > > Cc: Chris Metcalf > > Cc: Dave Hansen > > Cc: Fenghua Yu > > Cc: Huang Rui > > Cc: Jiri Slaby > > Cc: Jonathan Corbet > > Cc: Michael S. Tsirkin > > Cc: Paul Gortmaker > > Cc: Peter Zijlstra > > Cc: Ravi V. Shankar > > Cc: Shuah Khan > > Cc: Vlastimil Babka > > Cc: Tony Luck > > Cc: Paolo Bonzini > > Cc: Liang Z. Li > > Cc: Alexandre Julliard > > Cc: Stas Sergeev > > Cc: x...@kernel.org > > Cc: linux-msdos@vger.kernel.org > > Signed-off-by: Ricardo Neri > > --- > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 24/26] x86: Enable User-Mode Instruction Prevention
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> Cc: Andrew Morton > Cc: H. Peter Anvin > Cc: Borislav Petkov > Cc: Brian Gerst > Cc: Chen Yucong > Cc: Chris Metcalf > Cc: Dave Hansen > Cc: Fenghua Yu > Cc: Huang Rui > Cc: Jiri Slaby > Cc: Jonathan Corbet > Cc: Michael S. Tsirkin > Cc: Paul Gortmaker > Cc: Peter Zijlstra > Cc: Ravi V. Shankar > Cc: Shuah Khan > Cc: Vlastimil Babka > Cc: Tony Luck > Cc: Paolo Bonzini > Cc: Liang Z. Li > Cc: Alexandre Julliard > Cc: Stas Sergeev > Cc: x...@kernel.org > Cc: linux-msdos@vger.kernel.org > Signed-off-by: Ricardo Neri > --- > 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? > + 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. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- -- To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html