From: Sean Christopherson <sean.j.christopherson@intel.com>
To: "Moger, Babu" <Babu.Moger@amd.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>, "hpa@zytor.com" <hpa@zytor.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"rkrcmar@redhat.com" <rkrcmar@redhat.com>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"wanpengli@tencent.com" <wanpengli@tencent.com>,
"jmattson@google.com" <jmattson@google.com>,
"x86@kernel.org" <x86@kernel.org>,
"joro@8bytes.org" <joro@8bytes.org>,
"luto@kernel.org" <luto@kernel.org>,
"zohar@linux.ibm.com" <zohar@linux.ibm.com>,
"yamada.masahiro@socionext.com" <yamada.masahiro@socionext.com>,
"nayna@linux.ibm.com" <nayna@linux.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH v2] x86/Kconfig: Rename UMIP config parameter
Date: Mon, 4 Nov 2019 13:48:51 -0800 [thread overview]
Message-ID: <20191104214851.GD5960@linux.intel.com> (raw)
In-Reply-To: <157290058655.2477.5193340480187879024.stgit@naples-babu.amd.com>
On Mon, Nov 04, 2019 at 08:50:51PM +0000, Moger, Babu wrote:
> AMD 2nd generation EPYC processors support the UMIP (User-Mode
> Instruction Prevention) feature. So, rename X86_INTEL_UMIP to
> generic X86_UMIP and modify the text to cover both Intel and AMD.
There's a similar comment in the umip.c documentation that needs to be
updated, and a grammatical error that can be opportunistically fixed, i.e.
* The feature User-Mode Instruction Prevention present in recent Intel
* processor
to
* The feature User-Mode Instruction Prevention present in recent x86
* processors
IMO, the whole opening paragraph of the umip.c docs is weirdly worded and
could be rewritten to something similar to the Kconfig help text, e.g.
* User-Mode Instruction Prevention is a security feature present in recent x86
* processors that, when enabled, prevents a group of instructions (SGDT, SIDT,
* SLDT, SMSW and STR) from being run in user mode by issuing a general
* protection fault if the instruction is executed with CPL > 0.
>
> Signed-off-by: Babu Moger <babu.moger@amd.com>
> ---
> v2:
> Learned that for the hardware that support UMIP, we dont need to
> emulate. Removed the emulation related code and just submitting
> the config changes.
>
> arch/x86/Kconfig | 8 ++++----
> arch/x86/include/asm/disabled-features.h | 2 +-
> arch/x86/include/asm/umip.h | 4 ++--
> arch/x86/kernel/Makefile | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index d6e1faa28c58..821b7cebff31 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1880,13 +1880,13 @@ config X86_SMAP
>
> If unsure, say Y.
>
> -config X86_INTEL_UMIP
> +config X86_UMIP
> def_bool y
> - depends on CPU_SUP_INTEL
> - prompt "Intel User Mode Instruction Prevention" if EXPERT
> + depends on X86 && (CPU_SUP_INTEL || CPU_SUP_AMD)
> + prompt "User Mode Instruction Prevention" if EXPERT
> ---help---
> The User Mode Instruction Prevention (UMIP) is a security
Maybe opportunistically drop "The"?
> - feature in newer Intel processors. If enabled, a general
> + feature in newer x86 processors. If enabled, a general
> protection fault is issued if the SGDT, SLDT, SIDT, SMSW
> or STR instructions are executed in user mode. These instructions
> unnecessarily expose information about the hardware state.
> diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h
> index a5ea841cc6d2..8e1d0bb46361 100644
> --- a/arch/x86/include/asm/disabled-features.h
> +++ b/arch/x86/include/asm/disabled-features.h
> @@ -22,7 +22,7 @@
> # define DISABLE_SMAP (1<<(X86_FEATURE_SMAP & 31))
> #endif
>
> -#ifdef CONFIG_X86_INTEL_UMIP
> +#ifdef CONFIG_X86_UMIP
> # define DISABLE_UMIP 0
> #else
> # define DISABLE_UMIP (1<<(X86_FEATURE_UMIP & 31))
> diff --git a/arch/x86/include/asm/umip.h b/arch/x86/include/asm/umip.h
> index db43f2a0d92c..aeed98c3c9e1 100644
> --- a/arch/x86/include/asm/umip.h
> +++ b/arch/x86/include/asm/umip.h
> @@ -4,9 +4,9 @@
> #include <linux/types.h>
> #include <asm/ptrace.h>
>
> -#ifdef CONFIG_X86_INTEL_UMIP
> +#ifdef CONFIG_X86_UMIP
> bool fixup_umip_exception(struct pt_regs *regs);
> #else
> static inline bool fixup_umip_exception(struct pt_regs *regs) { return false; }
> -#endif /* CONFIG_X86_INTEL_UMIP */
> +#endif /* CONFIG_X86_UMIP */
> #endif /* _ASM_X86_UMIP_H */
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 3578ad248bc9..52ce1e239525 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -134,7 +134,7 @@ obj-$(CONFIG_EFI) += sysfb_efi.o
> obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
> obj-$(CONFIG_TRACING) += tracepoint.o
> obj-$(CONFIG_SCHED_MC_PRIO) += itmt.o
> -obj-$(CONFIG_X86_INTEL_UMIP) += umip.o
> +obj-$(CONFIG_X86_UMIP) += umip.o
>
> obj-$(CONFIG_UNWINDER_ORC) += unwind_orc.o
> obj-$(CONFIG_UNWINDER_FRAME_POINTER) += unwind_frame.o
>
next prev parent reply other threads:[~2019-11-04 22:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 20:50 [PATCH v2] x86/Kconfig: Rename UMIP config parameter Moger, Babu
2019-11-04 21:47 ` Borislav Petkov
2019-11-05 1:43 ` Moger, Babu
2019-11-04 21:48 ` Sean Christopherson [this message]
2019-11-05 1:47 ` Moger, Babu
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=20191104214851.GD5960@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=Babu.Moger@amd.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nayna@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=zohar@linux.ibm.com \
/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