Messages in this thread | | | Subject | Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode | From | Christophe Leroy <> | Date | Tue, 18 Feb 2020 12:04:41 +0100 |
| |
Le 18/02/2020 à 11:29, Masami Hiramatsu a écrit : > On Tue, 18 Feb 2020 06:58:06 +0100 > Christophe Leroy <christophe.leroy@c-s.fr> wrote: > >>>>>> >>>>>> 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. >>>>> >>>>>> 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. > >> 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.
> >> >>> 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
> > >>>> 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;
> >> >> 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
| |