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@kernel.org Cc: Andrew Morton akpm@linux-foundation.org Cc: H. Peter Anvin hpa@zytor.com Cc: Borislav Petkov bp@suse.de Cc: Brian Gerst brgerst@gmail.com Cc: Chen Yucong slaoub@gmail.com Cc: Chris Metcalf cmetcalf@mellanox.com Cc: Dave Hansen dave.hansen@linux.intel.com Cc: Fenghua Yu fenghua.yu@intel.com Cc: Huang Rui ray.huang@amd.com Cc: Jiri Slaby jslaby@suse.cz Cc: Jonathan Corbet corbet@lwn.net Cc: Michael S. Tsirkin mst@redhat.com Cc: Paul Gortmaker paul.gortmaker@windriver.com Cc: Peter Zijlstra peterz@infradead.org Cc: Ravi V. Shankar ravi.v.shankar@intel.com Cc: Shuah Khan shuah@kernel.org Cc: Vlastimil Babka vbabka@suse.cz Cc: Tony Luck tony.luck@intel.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Liang Z. Li liang.z.li@intel.com Cc: Alexandre Julliard julliard@winehq.org Cc: Stas Sergeev stsp@list.ru Cc: x86@kernel.org Cc: linux-msdos@vger.kernel.org Signed-off-by: Ricardo Neri ricardo.neri-calderon@linux.intel.com
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 securityfeature in newer Intel processors. If enabled, a generalprotection 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