From: rostedt at goodmis.org (Steven Rostedt) Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Date: Fri, 3 May 2019 09:22:47 -0400 [thread overview] Message-ID: <20190503092247.20cc1ff0@gandalf.local.home> (raw) In-Reply-To: <20190503092959.GB2623@hirez.programming.kicks-ass.net> On Fri, 3 May 2019 11:29:59 +0200 Peter Zijlstra <peterz at infradead.org> 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 traps ®s->sp is indeed the previous context -- > if it doesn't fall off the stack. Your hack detects the regular INT3 > frame. Howver if regs->sp has been modified (int3_emulate_push, for > example) your detectoring comes unstuck. Yep. I realized the issue as well. But wanted to make sure this did work when sp wasn't changed. > > Now, it is rather unlikely these two code paths interact, but just to be > safe, something like so might be more reliable: > > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c > index 4b8ee05dd6ad..aceaad0cc9a9 100644 > --- a/arch/x86/kernel/ptrace.c > +++ b/arch/x86/kernel/ptrace.c > @@ -163,6 +163,9 @@ static inline bool invalid_selector(u16 value) > * stack pointer we fall back to regs as stack if no previous stack > * exists. > * > + * There is a special case for INT3, there we construct a full pt_regs > + * environment. We can detect this case by a high bit in regs->cs > + * > * This is valid only for kernel mode traps. > */ > unsigned long kernel_stack_pointer(struct pt_regs *regs) > @@ -171,6 +174,9 @@ unsigned long kernel_stack_pointer(struct pt_regs *regs) > unsigned long sp = (unsigned long)®s->sp; > u32 *prev_esp; > > + if (regs->__csh & (1 << 13)) /* test CS_FROM_INT3 */ > + return regs->sp; > + Thanks, I was looking into doing something like this (setting a flag in the int3 code), but didn't have the time to see the best way to do this. I'll add this version of the code and run it through my tests. -- Steve > if (context == (sp & ~(THREAD_SIZE - 1))) > return sp; > > --- a/arch/x86/entry/entry_32.S > +++ b/arch/x86/entry/entry_32.S > @@ -388,6 +388,7 @@ > > #define CS_FROM_ENTRY_STACK (1 << 31) > #define CS_FROM_USER_CR3 (1 << 30) > +#define CS_FROM_INT3 (1 << 29) > > .macro SWITCH_TO_KERNEL_STACK > > @@ -1515,6 +1516,9 @@ ENTRY(int3) > > add $16, 12(%esp) # point sp back at the previous context > > + andl $0x0000ffff, 4(%esp) > + orl $CS_FROM_INT3, 4(%esp) > + > pushl $-1 # orig_eax; mark as interrupt > > SAVE_ALL
WARNING: multiple messages have this Message-ID (diff)
From: rostedt@goodmis.org (Steven Rostedt) Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Date: Fri, 3 May 2019 09:22:47 -0400 [thread overview] Message-ID: <20190503092247.20cc1ff0@gandalf.local.home> (raw) Message-ID: <20190503132247.YzZdnPDyyNApgskNb8FnJxqecS6_zD4X6hIiXnGP7gI@z> (raw) In-Reply-To: <20190503092959.GB2623@hirez.programming.kicks-ass.net> On Fri, 3 May 2019 11:29:59 +0200 Peter Zijlstra <peterz@infradead.org> 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 traps ®s->sp is indeed the previous context -- > if it doesn't fall off the stack. Your hack detects the regular INT3 > frame. Howver if regs->sp has been modified (int3_emulate_push, for > example) your detectoring comes unstuck. Yep. I realized the issue as well. But wanted to make sure this did work when sp wasn't changed. > > Now, it is rather unlikely these two code paths interact, but just to be > safe, something like so might be more reliable: > > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c > index 4b8ee05dd6ad..aceaad0cc9a9 100644 > --- a/arch/x86/kernel/ptrace.c > +++ b/arch/x86/kernel/ptrace.c > @@ -163,6 +163,9 @@ static inline bool invalid_selector(u16 value) > * stack pointer we fall back to regs as stack if no previous stack > * exists. > * > + * There is a special case for INT3, there we construct a full pt_regs > + * environment. We can detect this case by a high bit in regs->cs > + * > * This is valid only for kernel mode traps. > */ > unsigned long kernel_stack_pointer(struct pt_regs *regs) > @@ -171,6 +174,9 @@ unsigned long kernel_stack_pointer(struct pt_regs *regs) > unsigned long sp = (unsigned long)®s->sp; > u32 *prev_esp; > > + if (regs->__csh & (1 << 13)) /* test CS_FROM_INT3 */ > + return regs->sp; > + Thanks, I was looking into doing something like this (setting a flag in the int3 code), but didn't have the time to see the best way to do this. I'll add this version of the code and run it through my tests. -- Steve > if (context == (sp & ~(THREAD_SIZE - 1))) > return sp; > > --- a/arch/x86/entry/entry_32.S > +++ b/arch/x86/entry/entry_32.S > @@ -388,6 +388,7 @@ > > #define CS_FROM_ENTRY_STACK (1 << 31) > #define CS_FROM_USER_CR3 (1 << 30) > +#define CS_FROM_INT3 (1 << 29) > > .macro SWITCH_TO_KERNEL_STACK > > @@ -1515,6 +1516,9 @@ ENTRY(int3) > > add $16, 12(%esp) # point sp back at the previous context > > + andl $0x0000ffff, 4(%esp) > + orl $CS_FROM_INT3, 4(%esp) > + > pushl $-1 # orig_eax; mark as interrupt > > SAVE_ALL
next prev parent reply other threads:[~2019-05-03 13:22 UTC|newest] Thread overview: 204+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20190501202830.347656894@goodmis.org> 2019-05-01 20:28 ` [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions rostedt 2019-05-01 20:28 ` Steven Rostedt 2019-05-02 3:24 ` rostedt 2019-05-02 3:24 ` Steven Rostedt 2019-05-02 16:21 ` peterz 2019-05-02 16:21 ` Peter Zijlstra 2019-05-02 16:29 ` peterz 2019-05-02 16:29 ` Peter Zijlstra 2019-05-02 18:02 ` torvalds 2019-05-02 18:02 ` Linus Torvalds 2019-05-02 18:18 ` peterz 2019-05-02 18:18 ` Peter Zijlstra 2019-05-02 18:30 ` peterz 2019-05-02 18:30 ` Peter Zijlstra 2019-05-02 18:43 ` torvalds 2019-05-02 18:43 ` Linus Torvalds 2019-05-02 19:28 ` jikos 2019-05-02 19:28 ` Jiri Kosina 2019-05-02 20:25 ` luto 2019-05-02 20:25 ` Andy Lutomirski 2019-05-02 20:21 ` peterz 2019-05-02 20:21 ` Peter Zijlstra 2019-05-02 20:49 ` torvalds 2019-05-02 20:49 ` Linus Torvalds 2019-05-02 21:32 ` peterz 2019-05-02 21:32 ` Peter Zijlstra 2019-05-03 19:24 ` rostedt 2019-05-03 19:24 ` Steven Rostedt 2019-05-03 21:46 ` torvalds 2019-05-03 21:46 ` Linus Torvalds 2019-05-03 22:49 ` rostedt 2019-05-03 22:49 ` Steven Rostedt 2019-05-03 23:07 ` torvalds 2019-05-03 23:07 ` Linus Torvalds 2019-05-04 4:17 ` rostedt 2019-05-04 4:17 ` Steven Rostedt [not found] ` <CAHk-=wiuSFbv_rELND-BLWcP0GSZ0yF=xOAEcf61GE3bU9d=yg@mail.gmail.com> 2019-05-04 18:59 ` torvalds 2019-05-04 18:59 ` Linus Torvalds 2019-05-04 20:12 ` luto 2019-05-04 20:12 ` Andy Lutomirski 2019-05-04 20:28 ` torvalds 2019-05-04 20:28 ` Linus Torvalds 2019-05-04 20:36 ` torvalds 2019-05-04 20:36 ` Linus Torvalds 2019-05-03 22:55 ` luto 2019-05-03 22:55 ` Andy Lutomirski 2019-05-03 23:16 ` torvalds 2019-05-03 23:16 ` Linus Torvalds 2019-05-03 23:32 ` luto 2019-05-03 23:32 ` Andy Lutomirski 2019-05-02 22:52 ` rostedt 2019-05-02 22:52 ` Steven Rostedt 2019-05-02 23:31 ` rostedt 2019-05-02 23:31 ` Steven Rostedt 2019-05-02 23:50 ` rostedt 2019-05-02 23:50 ` Steven Rostedt 2019-05-03 1:51 ` [RFC][PATCH 1/2 v2] " rostedt 2019-05-03 1:51 ` Steven Rostedt 2019-05-03 9:29 ` [RFC][PATCH 1/2] " peterz 2019-05-03 9:29 ` Peter Zijlstra 2019-05-03 13:22 ` rostedt [this message] 2019-05-03 13:22 ` Steven Rostedt 2019-05-03 16:20 ` luto 2019-05-03 16:20 ` Andy Lutomirski 2019-05-03 16:31 ` rostedt 2019-05-03 16:31 ` Steven Rostedt 2019-05-03 16:35 ` peterz 2019-05-03 16:35 ` Peter Zijlstra 2019-05-03 16:44 ` luto 2019-05-03 16:44 ` Andy Lutomirski 2019-05-03 16:49 ` rostedt 2019-05-03 16:49 ` Steven Rostedt 2019-05-03 16:32 ` peterz 2019-05-03 16:32 ` Peter Zijlstra 2019-05-03 18:57 ` torvalds 2019-05-03 18:57 ` Linus Torvalds 2019-05-06 8:19 ` peterz 2019-05-06 8:19 ` Peter Zijlstra 2019-05-06 13:56 ` rostedt 2019-05-06 13:56 ` Steven Rostedt 2019-05-06 16:17 ` torvalds 2019-05-06 16:17 ` Linus Torvalds 2019-05-06 16:19 ` torvalds 2019-05-06 16:19 ` Linus Torvalds 2019-05-06 17:06 ` rostedt 2019-05-06 17:06 ` Steven Rostedt 2019-05-06 18:06 ` torvalds 2019-05-06 18:06 ` Linus Torvalds 2019-05-06 18:57 ` rostedt 2019-05-06 18:57 ` Steven Rostedt 2019-05-06 19:46 ` torvalds 2019-05-06 19:46 ` Linus Torvalds 2019-05-06 20:29 ` rostedt 2019-05-06 20:29 ` Steven Rostedt 2019-05-06 20:42 ` torvalds 2019-05-06 20:42 ` Linus Torvalds 2019-05-06 20:44 ` torvalds 2019-05-06 20:44 ` Linus Torvalds 2019-05-06 21:45 ` rostedt 2019-05-06 21:45 ` Steven Rostedt 2019-05-06 22:06 ` torvalds 2019-05-06 22:06 ` Linus Torvalds 2019-05-06 22:31 ` torvalds 2019-05-06 22:31 ` Linus Torvalds 2019-05-07 0:10 ` rostedt 2019-05-07 0:10 ` Steven Rostedt 2019-05-07 1:06 ` torvalds 2019-05-07 1:06 ` Linus Torvalds 2019-05-07 1:04 ` rostedt 2019-05-07 1:04 ` Steven Rostedt 2019-05-07 1:34 ` rostedt 2019-05-07 1:34 ` Steven Rostedt 2019-05-07 1:34 ` torvalds 2019-05-07 1:34 ` Linus Torvalds 2019-05-07 1:53 ` rostedt 2019-05-07 1:53 ` Steven Rostedt 2019-05-07 2:22 ` torvalds 2019-05-07 2:22 ` Linus Torvalds 2019-05-07 2:58 ` rostedt 2019-05-07 2:58 ` Steven Rostedt 2019-05-07 3:05 ` torvalds 2019-05-07 3:05 ` Linus Torvalds 2019-05-07 3:21 ` rostedt 2019-05-07 3:21 ` Steven Rostedt 2019-05-07 3:28 ` torvalds 2019-05-07 3:28 ` Linus Torvalds 2019-05-07 14:54 ` torvalds 2019-05-07 14:54 ` Linus Torvalds 2019-05-07 15:12 ` rostedt 2019-05-07 15:12 ` Steven Rostedt 2019-05-07 15:25 ` rostedt 2019-05-07 15:25 ` Steven Rostedt 2019-05-07 16:25 ` rostedt 2019-05-07 16:25 ` Steven Rostedt 2019-05-07 15:31 ` torvalds 2019-05-07 15:31 ` Linus Torvalds 2019-05-07 15:45 ` rostedt 2019-05-07 15:45 ` Steven Rostedt 2019-05-07 16:34 ` peterz 2019-05-07 16:34 ` Peter Zijlstra 2019-05-07 17:08 ` torvalds 2019-05-07 17:08 ` Linus Torvalds 2019-05-07 17:21 ` jpoimboe 2019-05-07 17:21 ` Josh Poimboeuf 2019-05-07 21:24 ` rostedt 2019-05-07 21:24 ` Steven Rostedt 2019-05-08 4:50 ` torvalds 2019-05-08 4:50 ` Linus Torvalds 2019-05-08 16:37 ` rostedt 2019-05-08 16:37 ` Steven Rostedt 2019-05-07 17:38 ` peterz 2019-05-07 17:38 ` Peter Zijlstra 2019-05-07 9:51 ` peterz 2019-05-07 9:51 ` Peter Zijlstra 2019-05-07 14:48 ` luto 2019-05-07 14:48 ` Andy Lutomirski 2019-05-07 14:57 ` torvalds 2019-05-07 14:57 ` Linus Torvalds 2019-05-07 14:13 ` mhiramat 2019-05-07 14:13 ` Masami Hiramatsu 2019-05-07 17:15 ` mhiramat 2019-05-07 17:15 ` Masami Hiramatsu 2019-05-06 14:22 ` peterz 2019-05-06 14:22 ` Peter Zijlstra 2019-05-07 8:57 ` peterz 2019-05-07 8:57 ` Peter Zijlstra 2019-05-07 9:18 ` David.Laight 2019-05-07 9:18 ` David Laight 2019-05-07 11:30 ` peterz 2019-05-07 11:30 ` Peter Zijlstra 2019-05-07 12:57 ` David.Laight 2019-05-07 12:57 ` David Laight 2019-05-07 13:14 ` rostedt 2019-05-07 13:14 ` Steven Rostedt 2019-05-07 14:50 ` David.Laight 2019-05-07 14:50 ` David Laight 2019-05-07 14:57 ` rostedt 2019-05-07 14:57 ` Steven Rostedt 2019-05-07 15:46 ` David.Laight 2019-05-07 15:46 ` David Laight 2019-05-07 13:32 ` peterz 2019-05-07 13:32 ` Peter Zijlstra 2019-05-07 9:27 ` peterz 2019-05-07 9:27 ` Peter Zijlstra 2019-05-07 12:27 ` rostedt 2019-05-07 12:27 ` Steven Rostedt 2019-05-07 12:41 ` peterz 2019-05-07 12:41 ` Peter Zijlstra 2019-05-07 12:54 ` rostedt 2019-05-07 12:54 ` Steven Rostedt 2019-05-07 17:22 ` masami.hiramatsu 2019-05-07 17:22 ` Masami Hiramatsu 2019-05-07 14:28 ` peterz 2019-05-07 14:28 ` Peter Zijlstra 2019-05-02 20:48 ` rostedt 2019-05-02 20:48 ` Steven Rostedt 2019-05-06 15:14 ` jpoimboe 2019-05-06 15:14 ` Josh Poimboeuf 2019-05-01 20:28 ` [RFC][PATCH 2/2] ftrace/x86: Emulate call function while updating in breakpoint handler rostedt 2019-05-01 20:28 ` Steven Rostedt 2019-05-03 10:22 ` [RFC][PATCH 1.5/2] x86: Add int3_emulate_call() selftest peterz 2019-05-03 10:22 ` Peter Zijlstra 2019-05-03 18:46 ` rostedt 2019-05-03 18:46 ` Steven Rostedt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190503092247.20cc1ff0@gandalf.local.home \ --to=linux-kselftest@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).