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

Groups > linux.kernel > #1191334 > unrolled thread

Re: Dealing with the NMI mess

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

  Re: Dealing with the NMI mess Steven Rostedt <rostedt@goodmis.org> - 2015-07-23 23:40 +0200
    Re: Dealing with the NMI mess Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-23 23:50 +0200
      Re: Dealing with the NMI mess Andy Lutomirski <luto@amacapital.net> - 2015-07-24 00:00 +0200
        Re: Dealing with the NMI mess Linus Torvalds <torvalds@linux-foundation.org> - 2015-07-24 00:10 +0200
          Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 10:20 +0200
            Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-24 11:10 +0200
            Re: Dealing with the NMI mess Steven Rostedt <rostedt@goodmis.org> - 2015-07-24 14:00 +0200
              Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 14:50 +0200
                Re: Dealing with the NMI mess Steven Rostedt <rostedt@goodmis.org> - 2015-07-24 15:10 +0200
                  Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-24 15:30 +0200
                    Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 15:40 +0200
                      Re: Dealing with the NMI mess Peter Zijlstra <peterz@infradead.org> - 2015-07-24 15:40 +0200
                    Re: Dealing with the NMI mess Paolo Bonzini <pbonzini@redhat.com> - 2015-07-30 17:50 +0200
                      Re: Dealing with the NMI mess Borislav Petkov <bp@alien8.de> - 2015-07-31 06:30 +0200
            Re: Dealing with the NMI mess Paolo Bonzini <pbonzini@redhat.com> - 2015-07-30 18:00 +0200
    Re: Dealing with the NMI mess Andy Lutomirski <luto@amacapital.net> - 2015-07-23 23:50 +0200
      Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-24 00:00 +0200
    Re: Dealing with the NMI mess Willy Tarreau <w@1wt.eu> - 2015-07-23 23:50 +0200

#1191334 — Re: Dealing with the NMI mess

On Thu, 23 Jul 2015 14:08:59 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Jul 23, 2015 at 1:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > Issue A: to return with RF clear, we need to disarm the breakpoint.
> > If it's limited to the duration of the NMI, that's easy.  If not, when
> > do we re-arm?  New prepare_exit_to_usermode hook?  Hmm, setting ti
> > flags during context switch may target the wrong task.
> 
> We don't re-arm it.
> 

Let me get this straight. The idea is in the #DB handler to detect that
it was triggered in NMI context, and if so, simply disarm that
breakpoint permanently, right?

Nothing should be adding hw breakpoints to NMI code anyway. Sounds
perfectly reasonable to me. Of course, how we tell we are in NMI
brings back all the races as we had in the nesting code. We can check
the per-cpu variable that is set with nmi_enter() and cleared at
nmi_exit() but what happens if the breakpoint is outside those calls.
We can check the stack pointer, but then we are back to userspace
fooling us. Maybe add the DF trick again?

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1191336

On Thu, Jul 23, 2015 at 2:31 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Let me get this straight. The idea is in the #DB handler to detect that
> it was triggered in NMI context, and if so, simply disarm that
> breakpoint permanently, right?

No, for simplicity, I'd make it cover not just NMI code, but any
"kernel code with interrupts disabled".

Because that's the test we'd use for "use ret instead of iret".

And that wider test is exactly because it's so damn hard to get the
exact instruction boundaries right. Let's *not* go down the path
(again) of having to get the whole %rip range and "magic stack pointer
values" etc.

Make it simple and completely unambiguous. The rule really would be:

 - if we return to kernel space and interrupts are disabled, we will
use "ret" rather than "iret"

   Hard rule. Simple. Straightforward. No random %rip values. No
random %rsp values. NO CRAP.

 - but because we use "ret" rather than "iret" we can't get RF
semantics, it means that #DB is special. RF is supposed to make us
make forward progress

   So for that reason, #DB just says "if the breakpoint happened
during that interrupts-ff reghion, I will clear %dr7 to guarantee
forward progress"

So those would be the two main rules. Very simple, and avoiding all nasty cases.

Now, I'd be willing to then hide the "oops, we clear dr7 very
agrressively" issue by having a few additional _heuristics_. But I
call them "heuristics" because unlike the current NMI nesting games,
they aren't about core stability. They are about "ok, maybe somebody
wants to trigger those faults, and we'll be _nice_ and try to make it
easy for them", but nothing more.

So for example, if that "#DB clears %dr7" happened, it sounds easy to
set _TIF_USER_WORK_MASK, and just force %dr7 to be re-loaded from a
cached value, so that if we disabled things because of some user stack
trace access, it will be re-enabled by the time we return to user
space. I think that sounds reasonable, but it's not something the core
low-level entry x86 assembly code needs to even care about. It's not
that level of "core", it's just being polite.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191343

On Thu, Jul 23, 2015 at 2:48 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jul 23, 2015 at 2:31 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>> Let me get this straight. The idea is in the #DB handler to detect that
>> it was triggered in NMI context, and if so, simply disarm that
>> breakpoint permanently, right?
>
> No, for simplicity, I'd make it cover not just NMI code, but any
> "kernel code with interrupts disabled".
>
> Because that's the test we'd use for "use ret instead of iret".
>
> And that wider test is exactly because it's so damn hard to get the
> exact instruction boundaries right. Let's *not* go down the path
> (again) of having to get the whole %rip range and "magic stack pointer
> values" etc.
>
> Make it simple and completely unambiguous. The rule really would be:
>
>  - if we return to kernel space and interrupts are disabled, we will
> use "ret" rather than "iret"
>
>    Hard rule. Simple. Straightforward. No random %rip values. No
> random %rsp values. NO CRAP.
>
>  - but because we use "ret" rather than "iret" we can't get RF
> semantics, it means that #DB is special. RF is supposed to make us
> make forward progress
>
>    So for that reason, #DB just says "if the breakpoint happened
> during that interrupts-ff reghion, I will clear %dr7 to guarantee
> forward progress"

What if we relax it slightly: "if the breakpoint happened during that
interrupts-off region, I will clear all *kernel breakpoints* in %dr7
to guarantee forward progress"?

Watchpoints don't need RF to make forward progress, and, by leaving
watchpoints alone, we avoid breaking gdb.

>
> So those would be the two main rules. Very simple, and avoiding all nasty cases.
>
> Now, I'd be willing to then hide the "oops, we clear dr7 very
> agrressively" issue by having a few additional _heuristics_. But I
> call them "heuristics" because unlike the current NMI nesting games,
> they aren't about core stability. They are about "ok, maybe somebody
> wants to trigger those faults, and we'll be _nice_ and try to make it
> easy for them", but nothing more.
>
> So for example, if that "#DB clears %dr7" happened, it sounds easy to
> set _TIF_USER_WORK_MASK, and just force %dr7 to be re-loaded from a
> cached value, so that if we disabled things because of some user stack
> trace access, it will be re-enabled by the time we return to user
> space. I think that sounds reasonable, but it's not something the core
> low-level entry x86 assembly code needs to even care about. It's not
> that level of "core", it's just being polite.

Once we limit it to instruction breakpoints, I don't think re-enabling
before returning to userspace matters.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191360

On Thu, Jul 23, 2015 at 2:50 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>
> What if we relax it slightly: "if the breakpoint happened during that
> interrupts-off region, I will clear all *kernel breakpoints* in %dr7
> to guarantee forward progress"?
>
> Watchpoints don't need RF to make forward progress, and, by leaving
> watchpoints alone, we avoid breaking gdb.

Hmmm. I thought watchpoints were "before the instruction" too, but
that's just because I haven't used them in ages, and I didn't remember
the details. I just looked it up.

You're right - the memory watchpoints trigger after the instruction
has executed, so RF isn't an issue. So yes, the only issue is
instruction breakpoints, and those are the only ones we need to clear.

And that makes it really easy.

So yes, I agree. We only need to clear all kernel breakpoints.

So we don't even need that _TIF_USER_WORK_MASK thing, because user
space isn't setting kernel code breakpoints, it's just kgdb.

Sounds good to me.

                Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191588

On Thu, Jul 23, 2015 at 02:59:56PM -0700, Linus Torvalds wrote:
> Hmmm. I thought watchpoints were "before the instruction" too, but
> that's just because I haven't used them in ages, and I didn't remember
> the details. I just looked it up.
> 
> You're right - the memory watchpoints trigger after the instruction
> has executed, so RF isn't an issue. So yes, the only issue is
> instruction breakpoints, and those are the only ones we need to clear.
> 
> And that makes it really easy.
> 
> So yes, I agree. We only need to clear all kernel breakpoints.

But but but, we can access userspace with !IF, imagine someone doing:

  local_irq_disable();
  copy_from_user_inatomic();

and as luck would have it, there's a breakpoint on the user memory we
just touched. And we go and disable a user breakpoint.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191621

On Fri, Jul 24, 2015 at 10:13:26AM +0200, Peter Zijlstra wrote:
> On Thu, Jul 23, 2015 at 02:59:56PM -0700, Linus Torvalds wrote:
> > Hmmm. I thought watchpoints were "before the instruction" too, but
> > that's just because I haven't used them in ages, and I didn't remember
> > the details. I just looked it up.
> > 
> > You're right - the memory watchpoints trigger after the instruction
> > has executed, so RF isn't an issue. So yes, the only issue is
> > instruction breakpoints, and those are the only ones we need to clear.
> > 
> > And that makes it really easy.
> > 
> > So yes, I agree. We only need to clear all kernel breakpoints.
> 
> But but but, we can access userspace with !IF, imagine someone doing:
> 
>   local_irq_disable();
>   copy_from_user_inatomic();
> 
> and as luck would have it, there's a breakpoint on the user memory we
> just touched. And we go and disable a user breakpoint.

Then shouldn't we use !IF && RSP matches NMI's stack ?
User-space cannot control the two at once.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191770

On Fri, 24 Jul 2015 10:13:26 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Jul 23, 2015 at 02:59:56PM -0700, Linus Torvalds wrote:
> > Hmmm. I thought watchpoints were "before the instruction" too, but
> > that's just because I haven't used them in ages, and I didn't remember
> > the details. I just looked it up.
> > 
> > You're right - the memory watchpoints trigger after the instruction
> > has executed, so RF isn't an issue. So yes, the only issue is
> > instruction breakpoints, and those are the only ones we need to clear.
> > 
> > And that makes it really easy.
> > 
> > So yes, I agree. We only need to clear all kernel breakpoints.
> 
> But but but, we can access userspace with !IF, imagine someone doing:
> 
>   local_irq_disable();
>   copy_from_user_inatomic();
> 
> and as luck would have it, there's a breakpoint on the user memory we
> just touched. And we go and disable a user breakpoint.

Where does the kernel do that to user text? I would think that user
data would only have watchpoints, and Andy and Linus said that those
would not be disabled (I'm guessing because they don't have the RF flag
set, and forward progress can proceed). If the kernel does the above to
user code and there's a breakpoint there, would it even trigger?

I'm not too familiar with how to use hw breakpoints, but I'm guessing
(correct me if I'm wrong) that breakpoints on code that trigger when
executed, but watchpoints on data trigger when accessed. Then
copy_from_user_inatomic() would only trigger on watchpoints (it's not
executing that code, at least I hope it isn't!), and those wont bother
us.

Or am I totally off base here?

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191794

On Fri, Jul 24, 2015 at 07:58:41AM -0400, Steven Rostedt wrote:
> On Fri, 24 Jul 2015 10:13:26 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, Jul 23, 2015 at 02:59:56PM -0700, Linus Torvalds wrote:
> > > Hmmm. I thought watchpoints were "before the instruction" too, but
> > > that's just because I haven't used them in ages, and I didn't remember
> > > the details. I just looked it up.
> > > 
> > > You're right - the memory watchpoints trigger after the instruction
> > > has executed, so RF isn't an issue. So yes, the only issue is
> > > instruction breakpoints, and those are the only ones we need to clear.
> > > 
> > > And that makes it really easy.
> > > 
> > > So yes, I agree. We only need to clear all kernel breakpoints.
> > 
> > But but but, we can access userspace with !IF, imagine someone doing:
> > 
> >   local_irq_disable();
> >   copy_from_user_inatomic();
> > 
> > and as luck would have it, there's a breakpoint on the user memory we
> > just touched. And we go and disable a user breakpoint.
> 
> Where does the kernel do that to user text? I would think that user
> data would only have watchpoints, and Andy and Linus said that those
> would not be disabled (I'm guessing because they don't have the RF flag
> set, and forward progress can proceed). If the kernel does the above to
> user code and there's a breakpoint there, would it even trigger?
> 
> I'm not too familiar with how to use hw breakpoints, but I'm guessing
> (correct me if I'm wrong) that breakpoints on code that trigger when
> executed, but watchpoints on data trigger when accessed. Then
> copy_from_user_inatomic() would only trigger on watchpoints (it's not
> executing that code, at least I hope it isn't!), and those wont bother
> us.

These things can be: RW, W, X.

Sure, hitting a user X watchpoint is going to be 'interesting', but its
fairly easy to hit a RW one.

Just watch an on-stack variable and get perf to copy a huge chunk of
stack (like it does for the dwarf stuff).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191804

On Fri, 24 Jul 2015 14:43:04 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

 
> > I'm not too familiar with how to use hw breakpoints, but I'm guessing
> > (correct me if I'm wrong) that breakpoints on code that trigger when
> > executed, but watchpoints on data trigger when accessed. Then
> > copy_from_user_inatomic() would only trigger on watchpoints (it's not
> > executing that code, at least I hope it isn't!), and those wont bother
> > us.
> 
> These things can be: RW, W, X.
> 
> Sure, hitting a user X watchpoint is going to be 'interesting', but its
> fairly easy to hit a RW one.

But do we care if we do hit one? The return from the #DB handler can
use a RET. Right?

-- Steve


> 
> Just watch an on-stack variable and get perf to copy a huge chunk of
> stack (like it does for the dwarf stuff).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191835

On Fri, Jul 24, 2015 at 09:03:42AM -0400, Steven Rostedt wrote:
> On Fri, 24 Jul 2015 14:43:04 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
>  
> > > I'm not too familiar with how to use hw breakpoints, but I'm guessing
> > > (correct me if I'm wrong) that breakpoints on code that trigger when
> > > executed, but watchpoints on data trigger when accessed. Then
> > > copy_from_user_inatomic() would only trigger on watchpoints (it's not
> > > executing that code, at least I hope it isn't!), and those wont bother
> > > us.
> > 
> > These things can be: RW, W, X.
> > 
> > Sure, hitting a user X watchpoint is going to be 'interesting', but its
> > fairly easy to hit a RW one.
> 
> But do we care if we do hit one? The return from the #DB handler can
> use a RET. Right?

My understanding is that by using RET we can't set the RF flag and #DB
will immediately strike again when the operation is attempted again. Thus
we have to completely disable the breakpoints on leaving after the first
one strikes, resulting in some userland breakpoints being missed. Maybe
it can be accepted as a limitation when perf is running. I don't know if
the output of perf is that relevant when a debugger is present BTW.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191841

On Fri, Jul 24, 2015 at 03:21:28PM +0200, Willy Tarreau wrote:
> On Fri, Jul 24, 2015 at 09:03:42AM -0400, Steven Rostedt wrote:
> > On Fri, 24 Jul 2015 14:43:04 +0200
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> >  
> > > > I'm not too familiar with how to use hw breakpoints, but I'm guessing
> > > > (correct me if I'm wrong) that breakpoints on code that trigger when
> > > > executed, but watchpoints on data trigger when accessed. Then
> > > > copy_from_user_inatomic() would only trigger on watchpoints (it's not
> > > > executing that code, at least I hope it isn't!), and those wont bother
> > > > us.
> > > 
> > > These things can be: RW, W, X.
> > > 
> > > Sure, hitting a user X watchpoint is going to be 'interesting', but its
> > > fairly easy to hit a RW one.
> > 
> > But do we care if we do hit one? The return from the #DB handler can
> > use a RET. Right?

Look at do_debug(), it has lovely bits like:

	preempt_conditional_sti();

in it, we do _NOT_ want to be re-enabling interrupts if we're called
from an !IF context, that'd be _bad_.

> My understanding is that by using RET we can't set the RF flag and #DB
> will immediately strike again when the operation is attempted again. Thus
> we have to completely disable the breakpoints on leaving after the first
> one strikes, resulting in some userland breakpoints being missed. Maybe
> it can be accepted as a limitation when perf is running. I don't know if
> the output of perf is that relevant when a debugger is present BTW.

The patch I posted will re-enable the breakpoints before returning to
userspace. So userspace will only 'miss' events generated by the kernel.

Missing reads from the kernel is not a problem -- and maybe even
expected, but certainly unavoidable.

Missing updates from the kernel might be a problem, you'd get a variable
change content even though you have a W watchpoint on it, that'd be
surprising.

Then again, I suppose we can argue the variable changed through another
mapping and watchpoints work on the virtual address, so tough cookies or
somesuch -- the kernel could in fact do this on highmem kernel anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191842

On Fri, Jul 24, 2015 at 03:30:13PM +0200, Peter Zijlstra wrote:
> > > But do we care if we do hit one? The return from the #DB handler can
> > > use a RET. Right?
> 
> Look at do_debug(), it has lovely bits like:
> 
> 	preempt_conditional_sti();
> 
> in it, we do _NOT_ want to be re-enabling interrupts if we're called
> from an !IF context, that'd be _bad_.

Ah, I forgot the conditional thing was the STI depending on regs->flags
& IF..

In any case, better safe than sorry and simply not do #DB ever if !IF.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1196147

On 24/07/2015 23:08, Andy Lutomirski wrote:
> user_icebp is set if int $0x01 happens, except it isn't because user
> code can't actually do that -- it'll cause #GP instead.
> 
> user_icebp is also set if the user has a bloody in-circuit emulator,
> given the name.  But who on Earth has one of those on a system new
> enough to run Linux and, even if they have one, why on Earth are they
> using it to send SIGTRAP.

You do not need either "int $0x01" or an ICE to set user_icebp = 1.  You
can use the 0xf1 opcode, which is kinda like 0xcc but generates #DB
instead of #BP.

The historical name is ICEBP because in-circuit emulators used it for
software breakpoints, just like your usual debugger used 0xcc aka int3.
 And just like 0xcc it's unprivileged, so you can actually get a SIGTRAP
with asm(".byte 0xf1").

So...

> In any event, user_icebp is only set if user_mode(regs), so it's safe
> locking-wise.  But please let's delete it.

... it's safe, but it has some use (!).

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1196577

On Thu, Jul 30, 2015 at 02:22:06PM -0700, Andy Lutomirski wrote:
> Great.  There's an opcode that invokes an interrupt gate that's not
> marked as allowing unprivileged access, and that opcode doesn't appear
> in the SDM.  It appears in the APM opcode map with no explanation at
> all.
> 
> Thanks, CPU vendors.

Here's something better:

http://www.rcollins.org/secrets/opcodes/ICEBP.html

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1196155

On 24/07/2015 19:20, Andy Lutomirski wrote:
> > Andy, section 5.8 of the SDM makes me think we could possibly abuse SYSRET
> > to emulate IRET, and then possibly simplify the flags processing. It says
> > that it takes the CPL3 code segment but nowhere it says that the target is
> > validated for effectively being userland, and further it suggests that it
> > doesn't validate anything :
> >
> >   "It is the responsibility of the OS to ensure the descriptors in
> >    the GDT/LDT correspond to the selectors loaded by SYSCALL/SYSRET
> >    (consistent with the base, limit, and attribute values forced by
> >    the instructions)."
> You are an evil bastard.  I seriously doubt that this will work.
> SYSRET goes to CPL3 no matter what.  Also, I don't think you want to
> start poking at MSRs to return.

On Intel the bottom two bits of the selector are forced to 11.  The
pseudocode of SYSRET in the SDM has an explicit

	CS.Selector ← (IA32_STAR[63:48]+ either 0 or 16) OR 3;
	...
	SS.Selector ← (IA32_STAR[63:48]+8) OR 3;

On AMD it's even worse, because you get a weird state with
CS.DPL=CS.RPL=SS.DPL=SS.RPL=0 but still the CPL is 3.  This is seriously
messed up because the CPL is always SS.DPL except in this case.  AMD
even had to add a separate field for the CPL to their VM control block,
just to account for this case.  Intel more sanely uses SS.DPL.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191337

On Thu, Jul 23, 2015 at 2:46 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Thu, Jul 23, 2015 at 05:31:05PM -0400, Steven Rostedt wrote:
>> On Thu, 23 Jul 2015 14:08:59 -0700
>> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>
>> > On Thu, Jul 23, 2015 at 1:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> > >
>> > > Issue A: to return with RF clear, we need to disarm the breakpoint.
>> > > If it's limited to the duration of the NMI, that's easy.  If not, when
>> > > do we re-arm?  New prepare_exit_to_usermode hook?  Hmm, setting ti
>> > > flags during context switch may target the wrong task.
>> >
>> > We don't re-arm it.
>> >
>>
>> Let me get this straight. The idea is in the #DB handler to detect that
>> it was triggered in NMI context, and if so, simply disarm that
>> breakpoint permanently, right?
>>
>> Nothing should be adding hw breakpoints to NMI code anyway. Sounds
>> perfectly reasonable to me. Of course, how we tell we are in NMI
>> brings back all the races as we had in the nesting code. We can check
>> the per-cpu variable that is set with nmi_enter() and cleared at
>> nmi_exit() but what happens if the breakpoint is outside those calls.
>> We can check the stack pointer, but then we are back to userspace
>> fooling us. Maybe add the DF trick again?
>
> Can't the back link of the TSS tell us where we come from ? At least
> it should not be manipulable from user-space.

Not on 64-bit -- there are no tasks :)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191348

On Thu, Jul 23, 2015 at 02:46:49PM -0700, Andy Lutomirski wrote:
> On Thu, Jul 23, 2015 at 2:46 PM, Willy Tarreau <w@1wt.eu> wrote:
> > Can't the back link of the TSS tell us where we come from ? At least
> > it should not be manipulable from user-space.
> 
> Not on 64-bit -- there are no tasks :)

Ah crap, sorry for the noise then!

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1191339

On Thu, Jul 23, 2015 at 05:31:05PM -0400, Steven Rostedt wrote:
> On Thu, 23 Jul 2015 14:08:59 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Thu, Jul 23, 2015 at 1:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > >
> > > Issue A: to return with RF clear, we need to disarm the breakpoint.
> > > If it's limited to the duration of the NMI, that's easy.  If not, when
> > > do we re-arm?  New prepare_exit_to_usermode hook?  Hmm, setting ti
> > > flags during context switch may target the wrong task.
> > 
> > We don't re-arm it.
> > 
> 
> Let me get this straight. The idea is in the #DB handler to detect that
> it was triggered in NMI context, and if so, simply disarm that
> breakpoint permanently, right?
> 
> Nothing should be adding hw breakpoints to NMI code anyway. Sounds
> perfectly reasonable to me. Of course, how we tell we are in NMI
> brings back all the races as we had in the nesting code. We can check
> the per-cpu variable that is set with nmi_enter() and cleared at
> nmi_exit() but what happens if the breakpoint is outside those calls.
> We can check the stack pointer, but then we are back to userspace
> fooling us. Maybe add the DF trick again?

Can't the back link of the TSS tell us where we come from ? At least
it should not be manipulable from user-space.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web