On Tue, 7 May 2019 21:50:52 -0700
Linus Torvalds wrote:
> > It's been a bane of mine for some time.
>
> Guys, I have basically a one-liner patch for your hangups.
>
> It's called "rename 'sp' to 'user_sp' on x86-32".
>
> Then we make the 'sp' field on x86-64 be a union, so that you can call
On Tue, May 7, 2019 at 2:24 PM Steven Rostedt wrote:
>
> And there's been several times I forget that regs->sp can not be read
> directly. Especially most of my bug reports are for x86_64 these days.
> But when I had that seldom x86_32 one, and go debugging, I would print
> out "regs->sp" and
On Tue, 7 May 2019 12:21:59 -0500
Josh Poimboeuf wrote:
> regs->sp is *undefined* on x86-32. We're damning our future selves to
> have to always remember to use that darn kernel_stack_pointer() helper
> for eternity just because of x86-32.
And there's been several times I forget that regs->sp
On Tue, May 07, 2019 at 10:08:50AM -0700, Linus Torvalds wrote:
> On Tue, May 7, 2019 at 9:34 AM Peter Zijlstra wrote:
> >
> > Would you consider my approach later on, under the guise of unification?
>
> WHY?
>
> The *only* advantage of your patch is that trivial "look up kernel stack"
>
2019年5月7日(火) 21:54 Steven Rostedt :
>
> On Tue, 7 May 2019 14:41:31 +0200
> Peter Zijlstra wrote:
>
> > > Kprobes sets the FTRACE_OPS_FL_IPMODIFY flag, thus
> > > they can never be put at the same location that is being live patched.
> >
> > OK, so do we want to allow kprobes that also modify
On Tue, May 07, 2019 at 10:08:50AM -0700, Linus Torvalds wrote:
> On Tue, May 7, 2019 at 9:34 AM Peter Zijlstra wrote:
> >
> > Would you consider my approach later on, under the guise of unification?
>
> WHY?
>
> The *only* advantage of your patch is that trivial "look up kernel stack"
>
On Tue, May 7, 2019 at 9:34 AM Peter Zijlstra wrote:
>
> Would you consider my approach later on, under the guise of unification?
WHY?
The *only* advantage of your patch is that trivial "look up kernel stack" macro.
Seriously. There's absolutely nothing else.
Is that macro ugly? Yes. But it's
On Tue, 7 May 2019 23:13:40 +0900
Masami Hiramatsu wrote:
> On Mon, 6 May 2019 17:45:11 -0400
> Steven Rostedt wrote:
>
> > If we go with Peter's patch, I can make this code much more sane, and
> > not have to worry about having >sp be at the top of the stack. I
> > could simply, just push
On Tue, May 07, 2019 at 08:31:14AM -0700, Linus Torvalds wrote:
> The reality is that changing something fundamental like the kernel
> stack at this point for an architecture that will not change in the
> future is silly.
In my eyes it makes sense because i386 is a minority architecture at
this
On Tue, 7 May 2019 11:25:13 -0400
Steven Rostedt wrote:
> Note, if you really are adamant on your solution, I can write them up,
> test them, and get them out for this merge window. I really want a
> solution for the int3 emulate calls, as there is a real bug here that
> they fix.
Thinking
From: Steven Rostedt
> Sent: 07 May 2019 15:57
> On Tue, 7 May 2019 14:50:26 +
> David Laight wrote:
>
> > From: Steven Rostedt
> > > Sent: 07 May 2019 14:14
> > > On Tue, 7 May 2019 12:57:15 +
> > > David Laight wrote:
>
> > The 'user' (ie the kernel code that needs to emulate the
On Tue, 7 May 2019 08:31:14 -0700
Linus Torvalds wrote:
> The reality is that changing something fundamental like the kernel
> stack at this point for an architecture that will not change in the
> future is silly.
x86_32 will no longer have updates, but will x86_64? And we will
constantly be
On Tue, May 7, 2019 at 8:12 AM Steven Rostedt wrote:
>>
> Yes, band-aids are usually simpler than a proper fix.
What? No/.
My fix is the *proper* fix.
PeterZ's is the bandaid.
> We have 28 years
> of hacks built on hacks. There's a lot of hacks in the C code to handle
> the
On Tue, 7 May 2019 11:12:27 -0400
Steven Rostedt wrote:
> I don't look at Peter's patch and think "this is the solution for int3
> emulate calls". I see Peter's patch as "Thanks God, we are finally
> getting rid of the cause of all theses work around hacks all over the
> place! and oh by the
On Tue, 7 May 2019 07:54:53 -0700
Linus Torvalds wrote:
> And honestly, I absolutely despise PeterZ's patch. The notion that we
> should suddenly say that "oh, the i386 kernel stack is odd" after 28
> years of having that standard i386 stack is just crazy. And this:
>
>
On Tue, May 7, 2019 at 7:48 AM Andy Lutomirski wrote:
>
> IOW I think your trick only works if the old and new states are CALL, but we
> don’t know that until we’ve looked up the record, at which point we can just
> use the result of the lookup.
It would indeed only work for call instructions.
On Tue, 7 May 2019 14:50:26 +
David Laight wrote:
> From: Steven Rostedt
> > Sent: 07 May 2019 14:14
> > On Tue, 7 May 2019 12:57:15 +
> > David Laight wrote:
> The 'user' (ie the kernel code that needs to emulate the call) doesn't
> write the data to the stack, just to some per-cpu
Duh.
I woke up this morning, realizing what was wrong with my patch.
On Mon, May 6, 2019 at 8:28 PM Linus Torvalds
wrote:
>
> Yes. But I was looking at the ftrace parts because I didn't see the
> bug in the low-level x86 side, so...
There was nothing wrong in the *low-level* parts. There was
>> On May 6, 2019, at 7:22 PM, Linus Torvalds
>> wrote:
>>
>> On Mon, May 6, 2019 at 6:53 PM Steven Rostedt wrote:
>>
>> Also, I figured just calling ftrace_regs_caller() was simpler then
>> having that int3 handler do the hash look ups to determine what handler
>> it needs to call.
>
>
From: Steven Rostedt
> Sent: 07 May 2019 14:14
> On Tue, 7 May 2019 12:57:15 +
> David Laight wrote:
>
> > > Only the INT3 thing needs 'the gap', but the far bigger change here is
> > > that kernel frames now have a complete pt_regs set and all sorts of
> > > horrible crap can go away.
> >
>
On Tue, May 07, 2019 at 10:57:53AM +0200, Peter Zijlstra wrote:
> So this one boots with all of Steve's self-test code enabled.
The selftests need improvement; I passed the 'ftrace regs test' but that
trampline was buggered.
> Yes, its fairly huge, and it really should be multiple patches. But
On Mon, 6 May 2019 17:45:11 -0400
Steven Rostedt wrote:
> If we go with Peter's patch, I can make this code much more sane, and
> not have to worry about having >sp be at the top of the stack. I
> could simply, just push everything in the order of pt_regs and call the
> handler.
Hi Steve, I
On Tue, May 07, 2019 at 12:57:15PM +, David Laight wrote:
> > Only the INT3 thing needs 'the gap', but the far bigger change here is
> > that kernel frames now have a complete pt_regs set and all sorts of
> > horrible crap can go away.
>
> I'm not doubting that generating the 'five register'
On Tue, 7 May 2019 12:57:15 +
David Laight wrote:
> > Only the INT3 thing needs 'the gap', but the far bigger change here is
> > that kernel frames now have a complete pt_regs set and all sorts of
> > horrible crap can go away.
>
> I'm not doubting that generating the 'five register'
From: Peter Zijlstra
> Sent: 07 May 2019 12:31
> To: David Laight
> On Tue, May 07, 2019 at 09:18:51AM +, David Laight wrote:
> > From: Peter Zijlstra
> > > Sent: 07 May 2019 09:58
> > ...
> > > + /*
> > > + * When we're here from kernel mode; the (exception) stack looks like:
> > > + *
> >
On Tue, 7 May 2019 14:41:31 +0200
Peter Zijlstra wrote:
> > Kprobes sets the FTRACE_OPS_FL_IPMODIFY flag, thus
> > they can never be put at the same location that is being live patched.
>
> OK, so do we want to allow kprobes that also modify regs->sp ? Because
> then we need to change these
On Tue, May 07, 2019 at 08:27:16AM -0400, Steven Rostedt wrote:
> On Tue, 7 May 2019 11:27:31 +0200
> Peter Zijlstra wrote:
>
> > FWIW, both these trampolines assume a kprobe will not
> > int3_emulate_{push/call}(), for both bitnesses.
> >
> > But then; I'm thinking kprobes should be inspection
On Tue, 7 May 2019 11:27:31 +0200
Peter Zijlstra wrote:
> FWIW, both these trampolines assume a kprobe will not
> int3_emulate_{push/call}(), for both bitnesses.
>
> But then; I'm thinking kprobes should be inspection only and not modify
> things. So that might just be good enough.
I believe
On Tue, May 07, 2019 at 09:18:51AM +, David Laight wrote:
> From: Peter Zijlstra
> > Sent: 07 May 2019 09:58
> ...
> > + /*
> > +* When we're here from kernel mode; the (exception) stack looks like:
> > +*
> > +* 4*4(%esp) -
> > +* 3*4(%esp) - flags
> > +* 2*4(%esp) - cs
On Mon, May 06, 2019 at 07:22:06PM -0700, Linus Torvalds wrote:
> We do *not* have very strict guarantees for D$-vs-I$ coherency on x86,
> but we *do* have very strict guarantees for D$-vs-D$ coherency. And so
> we could use the D$ coherency to give us atomicity guarantees for
> loading and
On Tue, May 07, 2019 at 10:57:53AM +0200, Peter Zijlstra wrote:
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 9e4fa2484d10..28d8ba3b9add 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -731,29 +731,27 @@ asm(
>
From: Peter Zijlstra
> Sent: 07 May 2019 09:58
...
> + /*
> + * When we're here from kernel mode; the (exception) stack looks like:
> + *
> + * 4*4(%esp) -
> + * 3*4(%esp) - flags
> + * 2*4(%esp) - cs
> + * 1*4(%esp) - ip
> + * 0*4(%esp) - orig_eax
Am I
On Mon, May 06, 2019 at 10:19:51AM +0200, Peter Zijlstra wrote:
> On Fri, May 03, 2019 at 11:57:22AM -0700, Linus Torvalds wrote:
> > On Fri, May 3, 2019 at 9:21 AM Andy Lutomirski wrote:
> > >
> > > So here’s a somewhat nutty suggestion: how about we tweak the 32-bit
> > > entry code to emulate
On Mon, May 6, 2019 at 8:22 PM Steven Rostedt wrote:
>
> But still, we need to emulate the call, which requires pushing the
> return code back onto the stack. I believe that part is the part we are
> struggling with.
Yes. But I was looking at the ftrace parts because I didn't see the
bug in the
On Mon, 6 May 2019 20:05:24 -0700
Linus Torvalds wrote:
> It would emulate the call that has had its first byte overwritten by
> 'int3'. Without doing any lookups of what it was supposed to change
> the call to, because it simply depends on what the rewriting code is
> doing on another CPU (or
On Mon, May 6, 2019 at 7:58 PM Steven Rostedt wrote:
>
> > Notice? We'd not even have to look up any values. We'd literally just
> > do something like
> >
> > int offset = locked_atomic_read(ip+1);
> > return int3_emulate_call(ip, ip+5+offset);
> >
> > and it would be *atomic*
On Mon, 6 May 2019 19:22:06 -0700
Linus Torvalds wrote:
> Notice? We'd not even have to look up any values. We'd literally just
> do something like
>
> int offset = locked_atomic_read(ip+1);
> return int3_emulate_call(ip, ip+5+offset);
>
> and it would be *atomic* with respect
On Mon, May 6, 2019 at 6:53 PM Steven Rostedt wrote:
>
> Also, I figured just calling ftrace_regs_caller() was simpler then
> having that int3 handler do the hash look ups to determine what handler
> it needs to call.
So what got me looking at this - and the races (that didn't turn out
to be
On Mon, 6 May 2019 18:34:59 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 6:04 PM Steven Rostedt wrote:
> >
> > That iterator does something special for each individual record. All
> > 40,000 of them.
>
> .. yes, but the 'int3' only happens for *one* of them at a time.
>
> Why would
On Mon, May 6, 2019 at 6:04 PM Steven Rostedt wrote:
>
> That iterator does something special for each individual record. All
> 40,000 of them.
.. yes, but the 'int3' only happens for *one* of them at a time.
Why would it bother with the other 39,999 calls?
You could easily just look up the
On Mon, 6 May 2019 21:04:16 -0400
Steven Rostedt wrote:
> static int add_breakpoints(struct dyn_ftrace *rec, int enable)
> {
> unsigned long ftrace_addr;
> int ret;
>
> ftrace_addr = ftrace_get_addr_curr(rec);
>
> ret = ftrace_test_record(rec, enable);
>
> switch
On Mon, May 6, 2019 at 5:10 PM Steven Rostedt wrote:
>
> But the CPU that was rewriting instructions does a run_sync() after
> removing the int3:
>
> static void run_sync(void)
> {
> int enable_irqs;
>
> /* No need to sync if there's only one CPU */
> if (num_online_cpus()
On Mon, 6 May 2019 15:06:57 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 2:45 PM Steven Rostedt wrote:
> >
> > To do that we would need to rewrite the logic to update each of those
> > 40,000 calls one at a time, or group them together to what gets
> > changed.
>
> Stephen, YOU ARE
On Mon, 6 May 2019 15:31:57 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 3:06 PM Linus Torvalds
> wrote:
> >
> > Why are you emulating something different than what you are rewriting?
>
> Side note: I'm also finding another bug on the ftrace side, which is a
> simple race condition.
On Mon, May 6, 2019 at 3:06 PM Linus Torvalds
wrote:
>
> Why are you emulating something different than what you are rewriting?
Side note: I'm also finding another bug on the ftrace side, which is a
simple race condition.
In particular, the logic with 'modifying_ftrace_code' is fundamentally
On Mon, May 6, 2019 at 2:45 PM Steven Rostedt wrote:
>
> To do that we would need to rewrite the logic to update each of those
> 40,000 calls one at a time, or group them together to what gets
> changed.
Stephen, YOU ARE NOT LISTENING.
You are already fixing the value of the call in the
On Mon, 6 May 2019 13:42:12 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 1:29 PM Steven Rostedt wrote:
> >
> > Because that call to ftrace_stub is also dynamic.
>
> You're missing the point.
>
> We are rewriting a single "cal" instruction to point to something.
>
> The "int3"
On Mon, May 6, 2019 at 1:42 PM Linus Torvalds
wrote:
>
> What *can* make sense is "Oh, I'm emulating a call, but I know that
> call will be rewritten, so let me emulate the call and then
> short-circuit the emulation immediately".
That made no sense. The end should have been "and then
On Mon, May 6, 2019 at 1:29 PM Steven Rostedt wrote:
>
> Because that call to ftrace_stub is also dynamic.
You're missing the point.
We are rewriting a single "cal" instruction to point to something.
The "int3" emulation should call THE SAME THING.
Right now it doesn't.
> Part of the code
On Mon, 6 May 2019 12:46:11 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 11:57 AM Steven Rostedt wrote:
> >
> > You should have waited another week to open that merge window ;-)
>
> Hmm. I'm looking at it while the test builds happen, and since I don't
> see what's wrong in the
On Mon, May 6, 2019 at 11:57 AM Steven Rostedt wrote:
>
> You should have waited another week to open that merge window ;-)
Hmm. I'm looking at it while the test builds happen, and since I don't
see what's wrong in the low-level entry code, I'm looking at the
ftrace code instead.
What's going
On Mon, 6 May 2019 11:06:51 -0700
Linus Torvalds wrote:
> On Mon, May 6, 2019 at 10:06 AM Steven Rostedt wrote:
> >
> > Can you try booting with:
> > [ snip snip ]
> >
> > And see if it boots?
>
> No it doesn't.
>
> Dang, I tried to figure out what's up, but now I really have to start
>
On Mon, May 6, 2019 at 10:06 AM Steven Rostedt wrote:
>
> Can you try booting with:
> [ snip snip ]
>
> And see if it boots?
No it doesn't.
Dang, I tried to figure out what's up, but now I really have to start
handling all the puill requests..
I thought it might be an int3 that happens on the
On Mon, 6 May 2019 09:17:19 -0700
Linus Torvalds wrote:
> So what is it that doesn't actually work? I've looked at the patch
> even more, and I can't for the life of me see how it wouldn't work.
>
> Of course, I didn't test any of the actual ftrace parts, since I
> short-circuited them
On Mon, May 6, 2019 at 9:17 AM Linus Torvalds
wrote:
>
> So what is it that doesn't actually work? I've looked at the patch
> even more, and I can't for the life of me see how it wouldn't work.
And I do still react to PeterZ's
arch/x86/entry/entry_32.S| 150
On Mon, May 6, 2019 at 6:56 AM Steven Rostedt wrote:
>
> I can test this too. I was hoping to get this in by this merge window.
> I spent 3 hours yesterday trying to get Linus's version working on
> i386 with no success. Not sure how much time Linus will have to look at
> this, as he just opened
On Thu, May 02, 2019 at 11:02:40AM -0700, Linus Torvalds wrote:
> On Thu, May 2, 2019 at 9:21 AM Peter Zijlstra wrote:
> >
> > TL;DR, on x86_32 kernel->kernel IRET frames are only 3 entries and do
> > not include ESP/SS, so not only wasn't regs->sp setup, if you changed it
> > it wouldn't be
On Mon, May 06, 2019 at 10:19:51AM +0200, Peter Zijlstra wrote:
> +.Lfrom_usermode_no_fixup_\@:
> +.endm
> +
> +.macro IRET_FRAME
> +
> + /* orig_eax is already POP'ed when we're here */
> +
> + testl $CS_FROM_KERNEL, 1*4(%esp)
> + jz .Lfinished_frame_\@
> +
> + pushl %eax
> +
On Mon, 6 May 2019 10:19:51 +0200
Peter Zijlstra wrote:
> On Fri, May 03, 2019 at 11:57:22AM -0700, Linus Torvalds wrote:
> > On Fri, May 3, 2019 at 9:21 AM Andy Lutomirski wrote:
> >
> > >
> > > So here’s a somewhat nutty suggestion: how about we tweak the 32-bit
> > > entry code to emulate
On Fri, May 03, 2019 at 11:57:22AM -0700, Linus Torvalds wrote:
> On Fri, May 3, 2019 at 9:21 AM Andy Lutomirski wrote:
> >
> > So here’s a somewhat nutty suggestion: how about we tweak the 32-bit
> > entry code to emulate the sane 64-bit frame, not just for int3 but
> > always?
>
> What would
On Sat, May 4, 2019 at 1:12 PM Andy Lutomirski wrote:
>
> As an aside, is it even *possible* to get #BP from v8086 mode? On a quick
> SDM read, the INT3 instruction causes #GP if VM=1 and IOPL<3. And, if we
> allow vm86() to have IOPL=3, we should just remove that ability. It’s nuts.
Oh, and
On Sat, May 4, 2019 at 1:12 PM Andy Lutomirski wrote:
>
> As an aside, is it even *possible* to get #BP from v8086 mode? On a quick
> SDM read, the INT3 instruction causes #GP if VM=1 and IOPL<3. And, if we
> allow vm86() to have IOPL=3, we should just remove that ability. It’s nuts.
We've
> On May 4, 2019, at 11:59 AM, Linus Torvalds
> wrote:
>
> On Fri, May 3, 2019 at 10:08 PM Linus Torvalds
> wrote:
>>
>> I'll look at it tomorrow, but I think this actually makes unnecessary
>> changes.
>>
>> In particular, I think we could keep the existing entry code almost
>>
On Fri, May 3, 2019 at 10:08 PM Linus Torvalds
wrote:
>
> I'll look at it tomorrow, but I think this actually makes unnecessary changes.
>
> In particular, I think we could keep the existing entry code almost unchanged
> with this whole approach.
So here's what I *think* should work. Note that
On Fri, 3 May 2019 16:07:59 -0700
Linus Torvalds wrote:
> static struct pt_regs *emulate_call(struct pt_regs *regs, unsigned
> long return, unsigned long target)
> {
> #ifdef CONFIG_X86_32
> /* BIG comment about how we need to move pt_regs to make
> room and to update the
> On May 3, 2019, at 4:16 PM, Linus Torvalds
> wrote:
>
>> On Fri, May 3, 2019 at 3:55 PM Andy Lutomirski wrote:
>>
>> But I think this will end up worse than the version where the entry code
>> fixes it up. This is because, if the C code moves pt_regs, then we need
>> some way to pass
On Fri, May 3, 2019 at 3:55 PM Andy Lutomirski wrote:
>
> But I think this will end up worse than the version where the entry code
> fixes it up. This is because, if the C code moves pt_regs, then we need some
> way to pass the new pointer back to the asm.
What? I already posted that code.
On Fri, May 3, 2019 at 3:49 PM Steven Rostedt wrote:
>
> You are saying that we have a do_int3() for user space int3, and
> do_kernel_int3() for kernel space. That would need to be done in asm
> for both, because having x86_64 call do_int3() for kernel and
> user would be interesting.
The
> On May 3, 2019, at 2:46 PM, Linus Torvalds
> wrote:
>
>> On Fri, May 3, 2019 at 12:24 PM Steven Rostedt wrote:
>>
>> The problem with this approach is that it would require doing the same
>> for x86_64, as the int3 C code is the same for both. And that may be a
>> bit more difficult on
On Fri, 3 May 2019 14:46:11 -0700
Linus Torvalds wrote:
> On Fri, May 3, 2019 at 12:24 PM Steven Rostedt wrote:
> >
> > The problem with this approach is that it would require doing the same
> > for x86_64, as the int3 C code is the same for both. And that may be a
> > bit more difficult on the
On Fri, May 3, 2019 at 12:24 PM Steven Rostedt wrote:
>
> The problem with this approach is that it would require doing the same
> for x86_64, as the int3 C code is the same for both. And that may be a
> bit more difficult on the x86_64 side because it's all done with a
> simple flag in the
On Thu, 2 May 2019 13:49:29 -0700
Linus Torvalds wrote:
> On Thu, May 2, 2019 at 1:22 PM Peter Zijlstra wrote:
> >
> > Something like so; it boots; but I could've made some horrible mistake
> > (again).
>
> This actually looks much better to me.
>
> Maybe it's more lines (I didn't check),
On Fri, May 3, 2019 at 9:21 AM Andy Lutomirski wrote:
>
> So here’s a somewhat nutty suggestion: how about we tweak the 32-bit entry
> code to emulate the sane 64-bit frame, not just for int3 but always?
What would the code actually end up looking like? I don't necessarily
object, since that
On Fri, 3 May 2019 09:44:35 -0700
Andy Lutomirski wrote:
> On Fri, May 3, 2019 at 9:35 AM Peter Zijlstra wrote:
> >
> > On Fri, May 03, 2019 at 12:31:26PM -0400, Steven Rostedt wrote:
> > > I guess the real question is, what's the performance impact of doing
> > > that?
> >
> > Is there
On Fri, May 3, 2019 at 9:35 AM Peter Zijlstra wrote:
>
> On Fri, May 03, 2019 at 12:31:26PM -0400, Steven Rostedt wrote:
> > I guess the real question is, what's the performance impact of doing
> > that?
>
> Is there anyone that considers i386 a performance platform?
Not me. As far as I'm
On Fri, May 03, 2019 at 12:31:26PM -0400, Steven Rostedt wrote:
> I guess the real question is, what's the performance impact of doing
> that?
Is there anyone that considers i386 a performance platform?
On Fri, May 03, 2019 at 09:20:55AM -0700, Andy Lutomirski wrote:
> > On May 3, 2019, at 6:22 AM, Steven Rostedt wrote:
> >
> > On Fri, 3 May 2019 11:29:59 +0200
> > Peter Zijlstra wrote:
> >
> >
> >> OMG, WTF, ARGH... That code is fsck'ing horrible. I'd almost argue to
> >> always do the INT3
On Fri, 3 May 2019 09:20:55 -0700
Andy Lutomirski wrote:
> So here’s a somewhat nutty suggestion: how about we tweak the 32-bit entry
> code to emulate the sane 64-bit frame, not just for int3 but always?
> Basically, the entry asm for entries from kernel mode would do, roughly:
>
> push $0
> On May 3, 2019, at 6:22 AM, Steven Rostedt wrote:
>
> On Fri, 3 May 2019 11:29:59 +0200
> Peter Zijlstra wrote:
>
>
>> OMG, WTF, ARGH... That code is fsck'ing horrible. I'd almost argue to
>> always do the INT3 thing, just to avoid games like that.
>
> Hehe, that's almost the exact same
On Fri, 3 May 2019 11:29:59 +0200
Peter Zijlstra wrote:
> OMG, WTF, ARGH... That code is fsck'ing horrible. I'd almost argue to
> always do the INT3 thing, just to avoid games like that.
Hehe, that's almost the exact same thoughts I had when seeing this
code ;-)
>
> That said; for normal
On Thu, May 02, 2019 at 07:50:52PM -0400, Steven Rostedt wrote:
> On Thu, 2 May 2019 19:31:29 -0400
> Steven Rostedt wrote:
>
> > Digging a little further, I pinpointed it out to being kretprobes. The
> > problem I believe is the use of kernel_stack_pointer() which does some
> > magic on x86_32.
On Thu, 2 May 2019 19:31:29 -0400
Steven Rostedt wrote:
> Digging a little further, I pinpointed it out to being kretprobes. The
> problem I believe is the use of kernel_stack_pointer() which does some
> magic on x86_32. kretprobes uses this to hijack the return address of
> the function (much
On Thu, 2 May 2019 18:52:25 -0400
Steven Rostedt wrote:
> On Thu, 2 May 2019 22:21:46 +0200
> Peter Zijlstra wrote:
>
> > On Thu, May 02, 2019 at 11:43:37AM -0700, Linus Torvalds wrote:
> > > What would it look like with the "int3-from-kernel is special"
> > > modification?
> >
> >
On Thu, 2 May 2019 22:21:46 +0200
Peter Zijlstra wrote:
> On Thu, May 02, 2019 at 11:43:37AM -0700, Linus Torvalds wrote:
> > What would it look like with the "int3-from-kernel is special"
> > modification?
>
> Something like so; it boots; but I could've made some horrible mistake
> (again).
On Thu, May 02, 2019 at 01:49:29PM -0700, Linus Torvalds wrote:
> We *could* also make this kernel-mode-only do_int3() be a special
> function, and do something like
I think I prefer the variant we have now. The int3_emulate_*() things
work uniformly and as expected on 32 and 64 bit (it would
On Thu, May 2, 2019 at 1:22 PM Peter Zijlstra wrote:
>
> Something like so; it boots; but I could've made some horrible mistake
> (again).
This actually looks much better to me.
Maybe it's more lines (I didn't check), but it's a lot simpler in that
now the magic of the int3 stack doesn't get
On Thu, 2 May 2019 11:02:40 -0700
Linus Torvalds wrote:
> Indeed, the 32-bit case for same-RPL exceptions/iret is entirely
> different, and I'd forgotten about that.
>
> And honestly, this makes the 32-bit case much worse. Now the entry
> stack modifications of int3 suddenly affect not just the
> On May 2, 2019, at 12:28 PM, Jiri Kosina wrote:
>
>> On Thu, 2 May 2019, Linus Torvalds wrote:
>>
>> I forget: is #BP _only_ for the "int3" instruction?
>
> Hmm, according to 17.3.2 in vol 3 of SDM (and table 6-1 there), that
> indeed seems to be the case, so we should be fine.
I’m
On Thu, May 02, 2019 at 11:43:37AM -0700, Linus Torvalds wrote:
> What would it look like with the "int3-from-kernel is special" modification?
Something like so; it boots; but I could've made some horrible mistake
(again).
---
diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
On Thu, 2 May 2019, Linus Torvalds wrote:
> I forget: is #BP _only_ for the "int3" instruction?
Hmm, according to 17.3.2 in vol 3 of SDM (and table 6-1 there), that
indeed seems to be the case, so we should be fine.
> But if "int3 from kernel space" _only_ happens on actual "int3"
>
On Thu, May 2, 2019 at 11:18 AM Peter Zijlstra wrote:
>
> We could fix this by not using the common exit path on int3; not sure we
> want to go there, but that is an option.
I don't think it's an option in general, because *some* int3
invocations will need all the usual error return.
But I
On Thu, May 02, 2019 at 08:18:11PM +0200, Peter Zijlstra wrote:
> ARGH; I knew it was too pretty :/ Yes, something like what you suggest
> will be needed, I'll go look at that once my brain recovers a bit from
> staring at entry code all day.
I forgot I can just run the thing, and it works!
On Thu, May 02, 2019 at 11:02:40AM -0700, Linus Torvalds wrote:
> On Thu, May 2, 2019 at 9:21 AM Peter Zijlstra wrote:
> >
> > TL;DR, on x86_32 kernel->kernel IRET frames are only 3 entries and do
> > not include ESP/SS, so not only wasn't regs->sp setup, if you changed it
> > it wouldn't be
On Thu, May 2, 2019 at 9:21 AM Peter Zijlstra wrote:
>
> TL;DR, on x86_32 kernel->kernel IRET frames are only 3 entries and do
> not include ESP/SS, so not only wasn't regs->sp setup, if you changed it
> it wouldn't be effective and corrupt random stack state.
Indeed, the 32-bit case for
On Thu, May 02, 2019 at 06:21:33PM +0200, Peter Zijlstra wrote:
> Much thanks to Joerg Roedel for talking entry_32.S with me.
>
> TL;DR, on x86_32 kernel->kernel IRET frames are only 3 entries and do
> not include ESP/SS, so not only wasn't regs->sp setup, if you changed it
> it wouldn't be
On Wed, May 01, 2019 at 11:24:12PM -0400, Steven Rostedt wrote:
> On Wed, 01 May 2019 16:28:31 -0400
> Steven Rostedt wrote:
>
> > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
> > index d309f30cf7af..50bbf4035baf 100644
> > --- a/arch/x86/entry/entry_32.S
> > +++
On Wed, 01 May 2019 16:28:31 -0400
Steven Rostedt wrote:
> diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
> index d309f30cf7af..50bbf4035baf 100644
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -1478,6 +1478,17 @@ ENTRY(int3)
> ASM_CLAC
>
From: Peter Zijlstra
In order to allow breakpoints to emulate call functions, they need to push
the return address onto the stack. But because the breakpoint exception
frame is added to the stack when the breakpoint is hit, there's no room to
add the address onto the stack and return to the
98 matches
Mail list logo
