Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode

[Naveen N. Rao]

Masami, Christophe,
Apologies for pitching in late here...

Masami Hiramatsu wrote:
> On Tue, 18 Feb 2020 12:04:41 +0100
> Christophe Leroy <christophe.leroy@xxxxxx> wrote:
>
> > >> Nevertheless, if one symbol has been forgotten in the blacklist, I think
> > >> it is a problem if it generate Oopses.
> > > 
> > > There is a long history also on x86 to make a blacklist. Anyway, how did
> > > you get this error on PPC32? Somewhere would you like to probe and
> > > it is a real mode function? Or, it happened unexpectedly?
> >
> > The first Oops I got was triggered by a WARN_ON() kind of trap in real 
> > mode. The trap exception handler called kprobe_handler() which tried to 
> > read the instruction at the trap address (which was a real-mode address) 
> > so it triggered a Bad Access Fault.
> >
> > This was initially the purpose of my patch.
>
> OK, then filtering the trap reason in kprobe handler is a bit strange.
> It should be done in the previous stage (maybe in trap.c)
> Can we filter it by exception flag or only by checking the instruction
> which causes the exception, or needs get_kprobe()...?

I think Masami's earlier patch proposal to bail out early from 
kprobe_handler() is appropriate here. We don't support kprobe in real 
mode since we don't have a way to ensure that the pre/post handlers work 
properly.

We will obviously also have to blacklist some of the real mode code from 
being probed to begin with. In addition, we will also have to blacklist 
any location where we can't take a trap (MSR_RI being unset, as an 
example)

Christophe,
See some of the below patch series:
https://patchwork.ozlabs.org/patch/752336/
https://patchwork.ozlabs.org/patch/752333/
https://patchwork.ozlabs.org/patch/782399/


- Naveen