From: David.Laight at ACULAB.COM (David Laight) Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Date: Tue, 7 May 2019 14:50:26 +0000 [thread overview] Message-ID: <b4a24fbe906a438798870c5112cde8b2@AcuMS.aculab.com> (raw) In-Reply-To: <20190507091403.556daba7@gandalf.local.home> From: Steven Rostedt > Sent: 07 May 2019 14:14 > On Tue, 7 May 2019 12:57:15 +0000 > David Laight <David.Laight at ACULAB.COM> 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' interrupt stack frame > > for faults in kernel space makes life simpler just suggesting that the > > 'emulated call' can be done by emulating the 'iret' rather than generating > > a gap in the stack. > > But how would the user put something on the stack? I don't see how > emulating an iret helps here. Can you write some pseudo code to explain > what you mean. I also believe the gap is only added for kernel->kernel > entries. 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 location. (Actually it could be on the stack at the other end of pt-regs.) So you get to the 'register restore and iret' code with the stack unaltered. It is then a SMOP to replace the %flags saved by the int3 with the %ip saved by the int3, the %ip with the address of the function to call, restore the flags (push and popf) and issue a ret.f to remove the %ip and %cs. (Actually you need to add 4 to the callers %ip address to allow for the difference between the size of int3 (hopefully 0xcc, not 0xcd 0x3).) > > > For 32bit 'the gap' happens naturally when building a 5 entry frame. Yes > > > it is possible to build a 5 entry frame on top of the old 3 entry one, > > > but why bother... > > > > Presumably there is 'horrid' code to generate the gap in 64bit mode? > > (less horrid than 32bit, but still horrid?) > > Or does it copy the entire pt_regs into a local stack frame and use > > that for the iret? > > On x86_64, the gap is only done for int3 and nothing else, thus it is > much less horrid. That's because x86_64 has a sane pt_regs storage for > all exceptions. Well, in particular, it always loads %sp as part of the iret. So you can create a gap and the cpu will remove it for you. In 64bit mode you could overwrite the %ss with the return address to the caller restore %eax and %flags, push the function address and use ret.n to jump to the function subtracting the right amount from %esp. Actually that means you can do the following in both modes: if not emulated_call_address then pop %ax; iret else # assume kernel<->kernel return push emulated_call_address; push flags_saved_by_int3 load %ax, return_address_from_iret add %ax,#4 store %ax, first_stack_location_written_by_int3 load %ax, value_saved_by_int3_entry popf ret.n The ret.n discards everything from the %ax to the required return address. So 'n' is the size of the int3 frame, so 12 for i386 and 40 for amd64. If the register restore (done just before this code) finished with 'add %sp, sizeof *pt_regs' then the emulated_call_address can be loaded in %ax from the other end of pt_regs. This all reminds me of fixing up the in-kernel faults that happen when loading the user segment registers during 'return to user' fault in kernel space. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David.Laight@ACULAB.COM (David Laight) Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Date: Tue, 7 May 2019 14:50:26 +0000 [thread overview] Message-ID: <b4a24fbe906a438798870c5112cde8b2@AcuMS.aculab.com> (raw) Message-ID: <20190507145026.6FV6n3RtklBkVFo98xz-SLELu0LbQdAvB9JmFH3rWv4@z> (raw) In-Reply-To: <20190507091403.556daba7@gandalf.local.home> From: Steven Rostedt > Sent: 07 May 2019 14:14 > On Tue, 7 May 2019 12:57:15 +0000 > David Laight <David.Laight@ACULAB.COM> 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' interrupt stack frame > > for faults in kernel space makes life simpler just suggesting that the > > 'emulated call' can be done by emulating the 'iret' rather than generating > > a gap in the stack. > > But how would the user put something on the stack? I don't see how > emulating an iret helps here. Can you write some pseudo code to explain > what you mean. I also believe the gap is only added for kernel->kernel > entries. 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 location. (Actually it could be on the stack at the other end of pt-regs.) So you get to the 'register restore and iret' code with the stack unaltered. It is then a SMOP to replace the %flags saved by the int3 with the %ip saved by the int3, the %ip with the address of the function to call, restore the flags (push and popf) and issue a ret.f to remove the %ip and %cs. (Actually you need to add 4 to the callers %ip address to allow for the difference between the size of int3 (hopefully 0xcc, not 0xcd 0x3).) > > > For 32bit 'the gap' happens naturally when building a 5 entry frame. Yes > > > it is possible to build a 5 entry frame on top of the old 3 entry one, > > > but why bother... > > > > Presumably there is 'horrid' code to generate the gap in 64bit mode? > > (less horrid than 32bit, but still horrid?) > > Or does it copy the entire pt_regs into a local stack frame and use > > that for the iret? > > On x86_64, the gap is only done for int3 and nothing else, thus it is > much less horrid. That's because x86_64 has a sane pt_regs storage for > all exceptions. Well, in particular, it always loads %sp as part of the iret. So you can create a gap and the cpu will remove it for you. In 64bit mode you could overwrite the %ss with the return address to the caller restore %eax and %flags, push the function address and use ret.n to jump to the function subtracting the right amount from %esp. Actually that means you can do the following in both modes: if not emulated_call_address then pop %ax; iret else # assume kernel<->kernel return push emulated_call_address; push flags_saved_by_int3 load %ax, return_address_from_iret add %ax,#4 store %ax, first_stack_location_written_by_int3 load %ax, value_saved_by_int3_entry popf ret.n The ret.n discards everything from the %ax to the required return address. So 'n' is the size of the int3 frame, so 12 for i386 and 40 for amd64. If the register restore (done just before this code) finished with 'add %sp, sizeof *pt_regs' then the emulated_call_address can be loaded in %ax from the other end of pt_regs. This all reminds me of fixing up the in-kernel faults that happen when loading the user segment registers during 'return to user' fault in kernel space. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2019-05-07 14:50 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 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 [this message] 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=b4a24fbe906a438798870c5112cde8b2@AcuMS.aculab.com \ --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).