Messages in this thread |  | | Date | Tue, 14 Jul 2020 20:52:04 +0900 | From | Masami Hiramatsu <> | Subject | Re: [PATCH RFC] kprobes: Remove MODULES dependency |
| |
On Mon, 13 Jul 2020 08:05:49 +0300 Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> On Fri, Jul 10, 2020 at 12:49:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jul 10, 2020 at 01:36:38PM +0300, Jarkko Sakkinen wrote: > > > Just so that I know (and learn), what did exactly disable optprobes? > > > > So regular, old-skool style kprobe is: > > > > - copy original instruction out > > - replace instruction with breakpoint (int3 on x86) > > - have exception handler return to the copied instruction with > > single-step on > > - have single step exception handler return to the original > > instruction stream > > > > which is 2 exceptions. > > Out of pure interest, how does it handle a jump (as the original > opcode), given that it single steps a copy?
Yes, the jump will be executed with a single-step on the copy buffer and kprobes (on x86) fixes up the result, this means we modifies the regs->ip. Also, there are some architectures which emulate the jump instead of single-stepping.
> > > optprobes avoid the single-step by not only writing a single > > instruction, but additionally placing a JMP instruction behind it such > > that it will automagically continue in the original instruction stream. > > > > This brings the requirement that the copied instruction is placed > > within the JMP displacement of the regular kernel text (s32 on x86). > > > > module_alloc() ensures the memory provided is within that range. > > Right, a relative jump is placed instead of 0xcc to the breakpoint?
Yes, a relative (far) jump is used. So the target address (copied buffer) must be in +-2GB range from the jump.
Thank you,
-- Masami Hiramatsu <mhiramat@kernel.org>
|  |