From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
Paul Mackerras <paulus@samba.org>,
stable@kernel.vger.org,
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>,
Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
Date: Tue, 18 Feb 2020 12:04:41 +0100 [thread overview]
Message-ID: <2b3f664e-d4ad-edd3-5bed-a4492f4ed213@c-s.fr> (raw)
In-Reply-To: <20200218192905.a3ed969e8565901c4f69fa22@kernel.org>
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
next prev parent reply other threads:[~2020-02-18 11:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 12:47 [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode Christophe Leroy
2020-02-14 13:54 ` Masami Hiramatsu
2020-02-15 10:28 ` Christophe Leroy
2020-02-16 12:34 ` Masami Hiramatsu
2020-02-17 9:03 ` Christophe Leroy
2020-02-17 10:27 ` Masami Hiramatsu
2020-02-17 15:38 ` Christophe Leroy
2020-02-17 17:41 ` Christophe Leroy
2020-02-18 0:44 ` Masami Hiramatsu
2020-02-18 5:58 ` Christophe Leroy
2020-02-18 10:29 ` Masami Hiramatsu
2020-02-18 11:04 ` Christophe Leroy [this message]
2020-02-18 12:33 ` Masami Hiramatsu
2020-02-18 13:58 ` Christophe Leroy
2020-02-18 14:06 ` Naveen N. Rao
2020-02-15 10:19 ` Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b3f664e-d4ad-edd3-5bed-a4492f4ed213@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=Larry.Finger@lwfinger.net \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhiramat@kernel.org \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=stable@kernel.vger.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).