Re: [PATCH RFC] kprobes: Remove MODULES dependency

[Masami Hiramatsu]

On Mon, 13 Jul 2020 08:05:49 +0300
Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx>