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

From: Naveen N. Rao
Date: Tue Feb 18 2020 - 09:07:04 EST

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)

See some of the below patch series:

- Naveen