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 then
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 c
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"
> macro.
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 regs
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"
> macro.
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 ®s->sp be at the top of the stack. I
> > could simply, just push e
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 po
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 about
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 call
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 add
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 differe
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 way,
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:
>
> arch/x86/entry/entry_32.
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 loc
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.
>
> So
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 it
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 ®s->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 n
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' inter
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 tr
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 th
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 storing
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 righ
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 t
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 l
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 o
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* wit
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 race
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 i
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 rec
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 NO
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 rac
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 instruct
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" emulat
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 short-circu
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 wil
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 low-le
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
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
> hand
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 e
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 intention
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 t
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 effec
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
> +
>Fro
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 th
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 de
> 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
>> unchange
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 I
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 t
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. Let
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 clean/s
> 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 th
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 idtent
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), bu
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 ker
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 anyo
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 concer
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 trap
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 li
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?
> >
> > Some
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 eve
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 exp
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 reas
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
ind
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"
> instructio
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 guess
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 effec
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 same-RPL
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 effect
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
> > +++ b/arch/x86/
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
>
97 matches
Mail list logo
