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

Le 18/02/2020 à 11:29, Masami Hiramatsu a écrit :

On Tue, 18 Feb 2020 06:58:06 +0100
Christophe Leroy [off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

What do you mean by 'there' ? At the entry of kprobe_handler() ?

That's what my patch does, it checks whether MMU is disabled or not. If
it is, it converts the address to a virtual address.

Do you mean kprobe_handler() should bail out early as it does when the
trap happens in user mode ?

Yes, that is what I meant.

quoted

Of course we can do that, I don't know
enough about kprobe to know if kprobe_handler() should manage events
that happened in real-mode or just ignore them. But I tested adding an
event on a function that runs in real-mode, and it (now) works.

So, what should we do really ?

I'm not sure how the powerpc kernel runs in real mode.
But clearly, at least kprobe event can not handle that case because
it tries to access memory by probe_kernel_read(). Unless that function
correctly handles the address translation, I want to prohibit kprobes
on such address.

So what I would like to see is, something like below.

diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 2d27ec4feee4..4771be152416 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c

@@ -261,7 +261,7 @@ int kprobe_handler(struct pt_regs *regs)
           unsigned int *addr = (unsigned int *)regs->nip;
           struct kprobe_ctlblk *kcb;
    
-       if (user_mode(regs))
+       if (user_mode(regs) || !(regs->msr & MSR_IR))
                   return 0;
    
           /*

With this instead change of my patch, I get an Oops everytime a kprobe
event occurs in real-mode.

This is because kprobe_handler() is now saying 'this trap doesn't belong
to me' for a trap that has been installed by it.

Hmm, on powerpc, kprobes is allowed to probe on the code which runs
in the real mode? I think we should also prohibit it by blacklisting.
(It is easy to add blacklist by NOKPROBE_SYMBOL(func))

Yes, I see a lot of them tagged with _ASM_NOKPROBE_SYMBOL() on PPC64,
but none on PPC32. I suppose that's missing and have to be added.

Ah, you are using PPC32.

quoted

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.

After discussion with you, I started looking at what would be the effect 
of setting a kprobe event in a function which runs in real mode.

quoted

quoted

Or, some parts are possble to run under both real mode and kernel mode?

I don't think so, at least on PPC32

OK, that's a good news. Also, are there any independent section where such
real mode functions are stored? (I can see start_real_trampolines in
sections.h) If that kind of sections are defined, it is easy to make
a blacklist in arch_populate_kprobe_blacklist(). See arch/arm64/kernel/probes/kprobes.c.

Part of them are in .head.text, and this section is already blacklisted 
throught function arch_within_kprobe_blacklist()

But there are several other functions which are not there. For instance, 
many things within entry_32.S, and also things in hash_low.S
On PPC64 (ie in entry_64.S) they were explicitely blacklisted with 
_ASM_NOKPROBE_SYMBOL(). We have to do the same on PPC64

quoted

quoted

quoted

So the 'program check' exception handler doesn't find the owner of the
trap hence generate an Oops.

Even if we don't want kprobe() to proceed with the event entirely
(allthough it works at least for simple events), I'd expect it to fail
gracefully.

Agreed. I thought it was easy to identify real mode code. But if it is
hard, we should apply your first patch and also skip user handlers
if we are in the real mode (and increment missed count).

user handlers are already skipped.

Yes, if you don't put a kprobes on real mode code. However, if user
(accidentally) puts a probe on real mode code, it might call a
user handler?

Are we talking about the same thing ?

Only kernel code can run in real mode, so the following code at the 
beginning of kprobe_handler() does the job ?

	if (user_mode(regs))
		return 0;

quoted

What do you think about my latest proposal below ? If a trap is
encoutered in real mode, if checks if the matching virtual address
corresponds to a valid kprobe. If it is, it skips it. If not, it returns
0 to tell "it's no me". You are also talking about incrementing the
missed count. Who do we do that ?

I rather like your first patch. If there is a kprobes, we can not skip
the instruction, because there is an instruction which must be executed.
(or single-skipped, but I'm not sure the emulator works correctly on
real mode)

Oops, yes of course.

Christophe