Re: [PATCH 2/2] x86/retpoline,kprobes: Avoid treating rethunk as an indirect jump

[Google]

On Wed, 5 Jul 2023 10:58:57 +0200
Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Wed, Jul 05, 2023 at 10:15:47AM +0200, Petr Pavlu wrote:
> > Functions can_optimize() and insn_is_indirect_jump() consider jumps to
> > the range [__indirect_thunk_start, __indirect_thunk_end] as indirect
> > jumps and prevent use of optprobes in functions containing them.
> 
> Why ?!? I mean, doing an opt-probe of an indirect jump/call instruction
> itself doesn't really make sense and I can see why you'd want to not do
> that. But why disallow an opt-probe if there's one in the function as a
> whole, but not the probe target?

Here we need to clarify the reason why functions which have indirect jumps
are not allowed to use opt-probe. Since optprobe can replace multiple 
instructions with a jump, if any jmp (is used for jump inside same function)
jumps to the second and subsequent instructions replaced by optprobe's jump,
that target instruction can not be optimized.

The problem of indirect jump (which jumps to the same function) is that
we don't know which addresses will be the target of the indirect jump.
So, for safety, I disallow optprobe for such function. In that case, normal
kprobe is used because it replaces only one instruction.

If I understand correctly, all indirect jump will be replaced with JMP_NOSPEC.
If you read the insn_jump_into_range, I onlu jecks the jump code, not call.
So the functions only have indirect call still allow optprobe.

Thank you,

-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>