Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1586686 > unrolled thread

[PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-02-23 07:50 +0100
    Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults  caused by UMIP Peter Zijlstra <peterz@infradead.org> - 2017-02-23 10:30 +0100
      Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults  caused by UMIP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-02-23 23:20 +0100
        Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults  caused by UMIP Andy Lutomirski <luto@amacapital.net> - 2017-02-24 20:30 +0100
          Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults  caused by UMIP Ricardo Neri <ricardo.neri-calderon@linux.intel.com> - 2017-02-24 20:40 +0100
            Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP "H. Peter Anvin" <hpa@zytor.com> - 2017-02-24 20:50 +0100

#1586686 — [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

If the User-Mode Instruction Prevention CPU feature is available and
enabled, a general protection fault will be issued if the instructions
sgdt, sldt, sidt, str or smsw are executed from user-mode context
(CPL > 0). If the fault was caused by any of the instructions protected
by UMIP, fixup_umip_exception will emulate dummy results for these
instructions. If emulation is successful, the result is passed to the
user space program and no SIGSEGV signal is emitted.

Please note that fixup_umip_exception also caters for the case when
the fault originated while running in virtual-8086 mode.

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/kernel/traps.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 948443e..39614ef 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -65,6 +65,7 @@
 #include <asm/trace/mpx.h>
 #include <asm/mpx.h>
 #include <asm/vm86.h>
+#include <asm/umip.h>
 
 #ifdef CONFIG_X86_64
 #include <asm/x86_init.h>
@@ -492,6 +493,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
 	cond_local_irq_enable(regs);
 
+	if (user_mode(regs) && (fixup_umip_exception(regs) == true))
+		return;
+
 	if (v8086_mode(regs)) {
 		local_irq_enable();
 		handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
-- 
2.9.3

[toc] | [next] | [standalone]

#1586779 — Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

On Wed, Feb 22, 2017 at 10:37:04PM -0800, Ricardo Neri wrote:
> @@ -492,6 +493,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
>  	RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
>  	cond_local_irq_enable(regs);
>  
> +	if (user_mode(regs) && (fixup_umip_exception(regs) == true))
> +		return;

I'm thinking

	if (user_mode(regs) && fixup_umip_exception(regs))
		return;

is actually easier to read.

[toc] | [prev] | [next] | [standalone]

#1587138 — Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

On Thu, 2017-02-23 at 10:27 +0100, Peter Zijlstra wrote:
> On Wed, Feb 22, 2017 at 10:37:04PM -0800, Ricardo Neri wrote:
> > @@ -492,6 +493,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
> >  	RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> >  	cond_local_irq_enable(regs);
> >  
> > +	if (user_mode(regs) && (fixup_umip_exception(regs) == true))
> > +		return;
> 
> I'm thinking
> 
> 	if (user_mode(regs) && fixup_umip_exception(regs))
> 		return;
> 
> is actually easier to read.

In a previous version Andy Lutomirsky suggested that 
	if (user_mode(regs) && (fixup_umip_exception(regs) == 0))

was easier to read :). Although at the time fixup_umip_exception
returned a numeric value. Now it only returns true/false for
successful/failed emulation. If with true/false not comparing to true
makes it easier to read, I will make the change.

Thanks and BR,
Ricardo

[toc] | [prev] | [next] | [standalone]

#1587880 — Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

On Thu, Feb 23, 2017 at 2:15 PM, Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> wrote:
> On Thu, 2017-02-23 at 10:27 +0100, Peter Zijlstra wrote:
>> On Wed, Feb 22, 2017 at 10:37:04PM -0800, Ricardo Neri wrote:
>> > @@ -492,6 +493,9 @@ do_general_protection(struct pt_regs *regs, long error_code)
>> >     RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
>> >     cond_local_irq_enable(regs);
>> >
>> > +   if (user_mode(regs) && (fixup_umip_exception(regs) == true))
>> > +           return;
>>
>> I'm thinking
>>
>>       if (user_mode(regs) && fixup_umip_exception(regs))
>>               return;
>>
>> is actually easier to read.
>
> In a previous version Andy Lutomirsky suggested that
>         if (user_mode(regs) && (fixup_umip_exception(regs) == 0))
>
> was easier to read :). Although at the time fixup_umip_exception
> returned a numeric value. Now it only returns true/false for
> successful/failed emulation. If with true/false not comparing to true
> makes it easier to read, I will make the change.

I think == true is silly :)

--Andy

[toc] | [prev] | [next] | [standalone]

#1587892 — Re: [PATCH v4 15/17] x86/traps: Fixup general protection faults caused by UMIP

On Fri, 2017-02-24 at 11:11 -0800, Andy Lutomirski wrote:
> > In a previous version Andy Lutomirsky suggested that
> >         if (user_mode(regs) && (fixup_umip_exception(regs) == 0))
> >
> > was easier to read :). Although at the time fixup_umip_exception
> > returned a numeric value. Now it only returns true/false for
> > successful/failed emulation. If with true/false not comparing to
> true
> > makes it easier to read, I will make the change.
> 
> I think == true is silly :)

Then I'll make the change.

Thanks and BR,
Ricardo

[toc] | [prev] | [next] | [standalone]

#1587896

Luck <tony.luck@intel.com>
From: hpa@zytor.com
Message-ID: <C4474E45-EAE0-45D3-8DB1-78AA1C2548A8@zytor.com>

On February 24, 2017 11:36:19 AM PST, Ricardo Neri <ricardo.neri-calderon@linux.intel.com> wrote:
>On Fri, 2017-02-24 at 11:11 -0800, Andy Lutomirski wrote:
>> > In a previous version Andy Lutomirsky suggested that
>> >         if (user_mode(regs) && (fixup_umip_exception(regs) == 0))
>> >
>> > was easier to read :). Although at the time fixup_umip_exception
>> > returned a numeric value. Now it only returns true/false for
>> > successful/failed emulation. If with true/false not comparing to
>> true
>> > makes it easier to read, I will make the change.
>> 
>> I think == true is silly :)
>
>Then I'll make the change.
>
>Thanks and BR,
>Ricardo

It's worse than silly, it is potentially toxic.

true is a macro which it's defined as 1.  Thus

     foo == true

... doesn't actually mean what people *think* it does, which is roughly the same thing as

    !!foo

However, if foo is not a boolean, this is *very* different; consider if foo is 2.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web