LinuxPPC-Dev Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
@ 2020-02-14 12:47 Christophe Leroy
  2020-02-14 13:54 ` Masami Hiramatsu
  2020-02-15 10:19 ` Christophe Leroy
  0 siblings, 2 replies; 9+ messages in thread
From: Christophe Leroy @ 2020-02-14 12:47 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Larry Finger, Naveen N. Rao
  Cc: linux-kernel, Anil S Keshavamurthy, stable, Masami Hiramatsu,
	linuxppc-dev, David S. Miller

When a program check exception happens while MMU translation is
disabled, following Oops happens in kprobe_handler() in the following
test:

		} else if (*addr != BREAKPOINT_INSTRUCTION) {

[   33.098554] BUG: Unable to handle kernel data access on read at 0x0000e268
[   33.105091] Faulting instruction address: 0xc000ec34
[   33.110010] Oops: Kernel access of bad area, sig: 11 [#1]
[   33.115348] BE PAGE_SIZE=16K PREEMPT CMPC885
[   33.119540] Modules linked in:
[   33.122591] CPU: 0 PID: 429 Comm: cat Not tainted 5.6.0-rc1-s3k-dev-00824-g84195dc6c58a #3267
[   33.131005] NIP:  c000ec34 LR: c000ecd8 CTR: c019cab8
[   33.136002] REGS: ca4d3b58 TRAP: 0300   Not tainted  (5.6.0-rc1-s3k-dev-00824-g84195dc6c58a)
[   33.144324] MSR:  00001032 <ME,IR,DR,RI>  CR: 2a4d3c52  XER: 00000000
[   33.150699] DAR: 0000e268 DSISR: c0000000
[   33.150699] GPR00: c000b09c ca4d3c10 c66d0620 00000000 ca4d3c60 00000000 00009032 00000000
[   33.150699] GPR08: 00020000 00000000 c087de44 c000afe0 c66d0ad0 100d3dd6 fffffff3 00000000
[   33.150699] GPR16: 00000000 00000041 00000000 ca4d3d70 00000000 00000000 0000416d 00000000
[   33.150699] GPR24: 00000004 c53b6128 00000000 0000e268 00000000 c07c0000 c07bb6fc ca4d3c60
[   33.188015] NIP [c000ec34] kprobe_handler+0x128/0x290
[   33.192989] LR [c000ecd8] kprobe_handler+0x1cc/0x290
[   33.197854] Call Trace:
[   33.200340] [ca4d3c30] [c000b09c] program_check_exception+0xbc/0x6fc
[   33.206590] [ca4d3c50] [c000e43c] ret_from_except_full+0x0/0x4
[   33.212392] --- interrupt: 700 at 0xe268
[   33.270401] Instruction dump:
[   33.273335] 913e0008 81220000 38600001 3929ffff 91220000 80010024 bb410008 7c0803a6
[   33.280992] 38210020 4e800020 38600000 4e800020 <813b0000> 6d2a7fe0 2f8a0008 419e0154
[   33.288841] ---[ end trace 5b9152d4cdadd06d ]---

Check MSR and convert regs->nip to virtual address if the trap
happened with MSR_IR cleared.

Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Fixes: 6cc89bad60a6 ("powerpc/kprobes: Invoke handlers directly")
Cc: stable@kernel.vger.org
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>

---
The bug might have existed even before that commit from Naveen.

Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
 arch/powerpc/kernel/kprobes.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
index 2d27ec4feee4..f8b848aa65bd 100644
--- a/arch/powerpc/kernel/kprobes.c
+++ b/arch/powerpc/kernel/kprobes.c
@@ -23,6 +23,7 @@
 #include <asm/cacheflush.h>
 #include <asm/sstep.h>
 #include <asm/sections.h>
+#include <asm/io.h>
 #include <linux/uaccess.h>
 
 DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
@@ -264,6 +265,9 @@ int kprobe_handler(struct pt_regs *regs)
 	if (user_mode(regs))
 		return 0;
 
+	if (!(regs->msr & MSR_IR))
+		addr = phys_to_virt(regs->nip);
+
 	/*
 	 * We don't want to be preempted for the entire
 	 * duration of kprobe processing
-- 
2.25.0


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  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-15 10:19 ` Christophe Leroy
  1 sibling, 1 reply; 9+ messages in thread
From: Masami Hiramatsu @ 2020-02-14 13:54 UTC (permalink / raw)
  To: Christophe Leroy
  Cc: linux-kernel, Anil S Keshavamurthy, Paul Mackerras,
	Masami Hiramatsu, stable, Naveen N. Rao, linuxppc-dev,
	David S. Miller, Larry Finger

Hi,

On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
Christophe Leroy <christophe.leroy@c-s.fr> wrote:

> When a program check exception happens while MMU translation is
> disabled, following Oops happens in kprobe_handler() in the following
> test:
> 
> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {

Thanks for the report and patch. I'm not so sure about powerpc implementation
but at where the MMU translation is disabled, can the handler work correctly?
(And where did you put the probe on?)

Your fix may fix this Oops, but if the handler needs special care, it is an
option to blacklist such place (if possible).

Anyway, Naveen, can you review it?

Thank you,

> 
> [   33.098554] BUG: Unable to handle kernel data access on read at 0x0000e268
> [   33.105091] Faulting instruction address: 0xc000ec34
> [   33.110010] Oops: Kernel access of bad area, sig: 11 [#1]
> [   33.115348] BE PAGE_SIZE=16K PREEMPT CMPC885
> [   33.119540] Modules linked in:
> [   33.122591] CPU: 0 PID: 429 Comm: cat Not tainted 5.6.0-rc1-s3k-dev-00824-g84195dc6c58a #3267
> [   33.131005] NIP:  c000ec34 LR: c000ecd8 CTR: c019cab8
> [   33.136002] REGS: ca4d3b58 TRAP: 0300   Not tainted  (5.6.0-rc1-s3k-dev-00824-g84195dc6c58a)
> [   33.144324] MSR:  00001032 <ME,IR,DR,RI>  CR: 2a4d3c52  XER: 00000000
> [   33.150699] DAR: 0000e268 DSISR: c0000000
> [   33.150699] GPR00: c000b09c ca4d3c10 c66d0620 00000000 ca4d3c60 00000000 00009032 00000000
> [   33.150699] GPR08: 00020000 00000000 c087de44 c000afe0 c66d0ad0 100d3dd6 fffffff3 00000000
> [   33.150699] GPR16: 00000000 00000041 00000000 ca4d3d70 00000000 00000000 0000416d 00000000
> [   33.150699] GPR24: 00000004 c53b6128 00000000 0000e268 00000000 c07c0000 c07bb6fc ca4d3c60
> [   33.188015] NIP [c000ec34] kprobe_handler+0x128/0x290
> [   33.192989] LR [c000ecd8] kprobe_handler+0x1cc/0x290
> [   33.197854] Call Trace:
> [   33.200340] [ca4d3c30] [c000b09c] program_check_exception+0xbc/0x6fc
> [   33.206590] [ca4d3c50] [c000e43c] ret_from_except_full+0x0/0x4
> [   33.212392] --- interrupt: 700 at 0xe268
> [   33.270401] Instruction dump:
> [   33.273335] 913e0008 81220000 38600001 3929ffff 91220000 80010024 bb410008 7c0803a6
> [   33.280992] 38210020 4e800020 38600000 4e800020 <813b0000> 6d2a7fe0 2f8a0008 419e0154
> [   33.288841] ---[ end trace 5b9152d4cdadd06d ]---
> 
> Check MSR and convert regs->nip to virtual address if the trap
> happened with MSR_IR cleared.
> 
> Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
> Fixes: 6cc89bad60a6 ("powerpc/kprobes: Invoke handlers directly")
> Cc: stable@kernel.vger.org
> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> 
> ---
> The bug might have existed even before that commit from Naveen.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
>  arch/powerpc/kernel/kprobes.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 2d27ec4feee4..f8b848aa65bd 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -23,6 +23,7 @@
>  #include <asm/cacheflush.h>
>  #include <asm/sstep.h>
>  #include <asm/sections.h>
> +#include <asm/io.h>
>  #include <linux/uaccess.h>
>  
>  DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> @@ -264,6 +265,9 @@ int kprobe_handler(struct pt_regs *regs)
>  	if (user_mode(regs))
>  		return 0;
>  
> +	if (!(regs->msr & MSR_IR))
> +		addr = phys_to_virt(regs->nip);
> +
>  	/*
>  	 * We don't want to be preempted for the entire
>  	 * duration of kprobe processing
> -- 
> 2.25.0
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  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:19 ` Christophe Leroy
  1 sibling, 0 replies; 9+ messages in thread
From: Christophe Leroy @ 2020-02-15 10:19 UTC (permalink / raw)
  To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
	Larry Finger, Naveen N. Rao
  Cc: linux-kernel, Anil S Keshavamurthy, stable, Masami Hiramatsu,
	linuxppc-dev, David S. Miller



Le 14/02/2020 à 13:47, Christophe Leroy a écrit :
> When a program check exception happens while MMU translation is
> disabled, following Oops happens in kprobe_handler() in the following
> test:
> 
> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {
> 
> [   33.098554] BUG: Unable to handle kernel data access on read at 0x0000e268
> [   33.105091] Faulting instruction address: 0xc000ec34
> [   33.110010] Oops: Kernel access of bad area, sig: 11 [#1]
> [   33.115348] BE PAGE_SIZE=16K PREEMPT CMPC885
> [   33.119540] Modules linked in:
> [   33.122591] CPU: 0 PID: 429 Comm: cat Not tainted 5.6.0-rc1-s3k-dev-00824-g84195dc6c58a #3267
> [   33.131005] NIP:  c000ec34 LR: c000ecd8 CTR: c019cab8
> [   33.136002] REGS: ca4d3b58 TRAP: 0300   Not tainted  (5.6.0-rc1-s3k-dev-00824-g84195dc6c58a)
> [   33.144324] MSR:  00001032 <ME,IR,DR,RI>  CR: 2a4d3c52  XER: 00000000
> [   33.150699] DAR: 0000e268 DSISR: c0000000
> [   33.150699] GPR00: c000b09c ca4d3c10 c66d0620 00000000 ca4d3c60 00000000 00009032 00000000
> [   33.150699] GPR08: 00020000 00000000 c087de44 c000afe0 c66d0ad0 100d3dd6 fffffff3 00000000
> [   33.150699] GPR16: 00000000 00000041 00000000 ca4d3d70 00000000 00000000 0000416d 00000000
> [   33.150699] GPR24: 00000004 c53b6128 00000000 0000e268 00000000 c07c0000 c07bb6fc ca4d3c60
> [   33.188015] NIP [c000ec34] kprobe_handler+0x128/0x290
> [   33.192989] LR [c000ecd8] kprobe_handler+0x1cc/0x290
> [   33.197854] Call Trace:
> [   33.200340] [ca4d3c30] [c000b09c] program_check_exception+0xbc/0x6fc
> [   33.206590] [ca4d3c50] [c000e43c] ret_from_except_full+0x0/0x4
> [   33.212392] --- interrupt: 700 at 0xe268
> [   33.270401] Instruction dump:
> [   33.273335] 913e0008 81220000 38600001 3929ffff 91220000 80010024 bb410008 7c0803a6
> [   33.280992] 38210020 4e800020 38600000 4e800020 <813b0000> 6d2a7fe0 2f8a0008 419e0154
> [   33.288841] ---[ end trace 5b9152d4cdadd06d ]---
> 
> Check MSR and convert regs->nip to virtual address if the trap
> happened with MSR_IR cleared.
> 
> Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
> Fixes: 6cc89bad60a6 ("powerpc/kprobes: Invoke handlers directly")
> Cc: stable@kernel.vger.org

Oops, I meant

Cc: stable@vger.kernel.org

> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> 
> ---
> The bug might have existed even before that commit from Naveen.
> 
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
>   arch/powerpc/kernel/kprobes.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index 2d27ec4feee4..f8b848aa65bd 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -23,6 +23,7 @@
>   #include <asm/cacheflush.h>
>   #include <asm/sstep.h>
>   #include <asm/sections.h>
> +#include <asm/io.h>
>   #include <linux/uaccess.h>
>   
>   DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
> @@ -264,6 +265,9 @@ int kprobe_handler(struct pt_regs *regs)
>   	if (user_mode(regs))
>   		return 0;
>   
> +	if (!(regs->msr & MSR_IR))
> +		addr = phys_to_virt(regs->nip);
> +
>   	/*
>   	 * We don't want to be preempted for the entire
>   	 * duration of kprobe processing
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  2020-02-14 13:54 ` Masami Hiramatsu
@ 2020-02-15 10:28   ` Christophe Leroy
  2020-02-16 12:34     ` Masami Hiramatsu
  0 siblings, 1 reply; 9+ messages in thread
From: Christophe Leroy @ 2020-02-15 10:28 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: linux-kernel, Anil S Keshavamurthy, Paul Mackerras, stable,
	Naveen N. Rao, linuxppc-dev, David S. Miller, Larry Finger

Hi,

Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
> Hi,
> 
> On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> 
>> When a program check exception happens while MMU translation is
>> disabled, following Oops happens in kprobe_handler() in the following
>> test:
>>
>> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {
> 
> Thanks for the report and patch. I'm not so sure about powerpc implementation
> but at where the MMU translation is disabled, can the handler work correctly?
> (And where did you put the probe on?)
> 
> Your fix may fix this Oops, but if the handler needs special care, it is an
> option to blacklist such place (if possible).

I guess that's another story. Here we are not talking about a place 
where kprobe has been illegitimately activated, but a place where there 
is a valid trap, which generated a valid 'program check exception'. And 
kprobe was off at that time.

As any 'program check exception' due to a trap (ie a BUG_ON, a WARN_ON, 
a debugger breakpoint, a perf breakpoint, etc...) calls 
kprobe_handler(), kprobe_handler() must be prepared to handle the case 
where the MMU translation is disabled, even if probes are not supposed 
to be set for functions running with MMU translation disabled.

Christophe

> 
> Anyway, Naveen, can you review it?
> 
> Thank you,
> 
>>
>> [   33.098554] BUG: Unable to handle kernel data access on read at 0x0000e268
>> [   33.105091] Faulting instruction address: 0xc000ec34
>> [   33.110010] Oops: Kernel access of bad area, sig: 11 [#1]
>> [   33.115348] BE PAGE_SIZE=16K PREEMPT CMPC885
>> [   33.119540] Modules linked in:
>> [   33.122591] CPU: 0 PID: 429 Comm: cat Not tainted 5.6.0-rc1-s3k-dev-00824-g84195dc6c58a #3267
>> [   33.131005] NIP:  c000ec34 LR: c000ecd8 CTR: c019cab8
>> [   33.136002] REGS: ca4d3b58 TRAP: 0300   Not tainted  (5.6.0-rc1-s3k-dev-00824-g84195dc6c58a)
>> [   33.144324] MSR:  00001032 <ME,IR,DR,RI>  CR: 2a4d3c52  XER: 00000000
>> [   33.150699] DAR: 0000e268 DSISR: c0000000
>> [   33.150699] GPR00: c000b09c ca4d3c10 c66d0620 00000000 ca4d3c60 00000000 00009032 00000000
>> [   33.150699] GPR08: 00020000 00000000 c087de44 c000afe0 c66d0ad0 100d3dd6 fffffff3 00000000
>> [   33.150699] GPR16: 00000000 00000041 00000000 ca4d3d70 00000000 00000000 0000416d 00000000
>> [   33.150699] GPR24: 00000004 c53b6128 00000000 0000e268 00000000 c07c0000 c07bb6fc ca4d3c60
>> [   33.188015] NIP [c000ec34] kprobe_handler+0x128/0x290
>> [   33.192989] LR [c000ecd8] kprobe_handler+0x1cc/0x290
>> [   33.197854] Call Trace:
>> [   33.200340] [ca4d3c30] [c000b09c] program_check_exception+0xbc/0x6fc
>> [   33.206590] [ca4d3c50] [c000e43c] ret_from_except_full+0x0/0x4
>> [   33.212392] --- interrupt: 700 at 0xe268
>> [   33.270401] Instruction dump:
>> [   33.273335] 913e0008 81220000 38600001 3929ffff 91220000 80010024 bb410008 7c0803a6
>> [   33.280992] 38210020 4e800020 38600000 4e800020 <813b0000> 6d2a7fe0 2f8a0008 419e0154
>> [   33.288841] ---[ end trace 5b9152d4cdadd06d ]---
>>
>> Check MSR and convert regs->nip to virtual address if the trap
>> happened with MSR_IR cleared.
>>
>> Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Fixes: 6cc89bad60a6 ("powerpc/kprobes: Invoke handlers directly")
>> Cc: stable@kernel.vger.org
>> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>
>> ---
>> The bug might have existed even before that commit from Naveen.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>>   arch/powerpc/kernel/kprobes.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
>> index 2d27ec4feee4..f8b848aa65bd 100644
>> --- a/arch/powerpc/kernel/kprobes.c
>> +++ b/arch/powerpc/kernel/kprobes.c
>> @@ -23,6 +23,7 @@
>>   #include <asm/cacheflush.h>
>>   #include <asm/sstep.h>
>>   #include <asm/sections.h>
>> +#include <asm/io.h>
>>   #include <linux/uaccess.h>
>>   
>>   DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
>> @@ -264,6 +265,9 @@ int kprobe_handler(struct pt_regs *regs)
>>   	if (user_mode(regs))
>>   		return 0;
>>   
>> +	if (!(regs->msr & MSR_IR))
>> +		addr = phys_to_virt(regs->nip);
>> +
>>   	/*
>>   	 * We don't want to be preempted for the entire
>>   	 * duration of kprobe processing
>> -- 
>> 2.25.0
>>
> 
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  2020-02-15 10:28   ` Christophe Leroy
@ 2020-02-16 12:34     ` Masami Hiramatsu
  2020-02-17  9:03       ` Christophe Leroy
  0 siblings, 1 reply; 9+ messages in thread
From: Masami Hiramatsu @ 2020-02-16 12:34 UTC (permalink / raw)
  To: Christophe Leroy
  Cc: linux-kernel, Anil S Keshavamurthy, Paul Mackerras, stable,
	Naveen N. Rao, linuxppc-dev, David S. Miller, Larry Finger

On Sat, 15 Feb 2020 11:28:49 +0100
Christophe Leroy <christophe.leroy@c-s.fr> wrote:

> Hi,
> 
> Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
> > Hi,
> > 
> > On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
> > Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> > 
> >> When a program check exception happens while MMU translation is
> >> disabled, following Oops happens in kprobe_handler() in the following
> >> test:
> >>
> >> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {
> > 
> > Thanks for the report and patch. I'm not so sure about powerpc implementation
> > but at where the MMU translation is disabled, can the handler work correctly?
> > (And where did you put the probe on?)
> > 
> > Your fix may fix this Oops, but if the handler needs special care, it is an
> > option to blacklist such place (if possible).
> 
> I guess that's another story. Here we are not talking about a place 
> where kprobe has been illegitimately activated, but a place where there 
> is a valid trap, which generated a valid 'program check exception'. And 
> kprobe was off at that time.

Ah, I got it. It is not a kprobe breakpoint, but to check that correctly,
it has to know the address where the breakpoint happens. OK.

> 
> As any 'program check exception' due to a trap (ie a BUG_ON, a WARN_ON, 
> a debugger breakpoint, a perf breakpoint, etc...) calls 
> kprobe_handler(), kprobe_handler() must be prepared to handle the case 
> where the MMU translation is disabled, even if probes are not supposed 
> to be set for functions running with MMU translation disabled.

Can't we check the MMU is disabled there (as same as checking the exception
happened in user space or not)?

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  2020-02-16 12:34     ` Masami Hiramatsu
@ 2020-02-17  9:03       ` Christophe Leroy
  2020-02-17 10:27         ` Masami Hiramatsu
  0 siblings, 1 reply; 9+ messages in thread
From: Christophe Leroy @ 2020-02-17  9:03 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: linux-kernel, Anil S Keshavamurthy, Paul Mackerras, stable,
	Naveen N. Rao, linuxppc-dev, David S. Miller, Larry Finger



Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
> On Sat, 15 Feb 2020 11:28:49 +0100
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> 
>> Hi,
>>
>> Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
>>> Hi,
>>>
>>> On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
>>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>
>>>> When a program check exception happens while MMU translation is
>>>> disabled, following Oops happens in kprobe_handler() in the following
>>>> test:
>>>>
>>>> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {
>>>
>>> Thanks for the report and patch. I'm not so sure about powerpc implementation
>>> but at where the MMU translation is disabled, can the handler work correctly?
>>> (And where did you put the probe on?)
>>>
>>> Your fix may fix this Oops, but if the handler needs special care, it is an
>>> option to blacklist such place (if possible).
>>
>> I guess that's another story. Here we are not talking about a place
>> where kprobe has been illegitimately activated, but a place where there
>> is a valid trap, which generated a valid 'program check exception'. And
>> kprobe was off at that time.
> 
> Ah, I got it. It is not a kprobe breakpoint, but to check that correctly,
> it has to know the address where the breakpoint happens. OK.
> 
>>
>> As any 'program check exception' due to a trap (ie a BUG_ON, a WARN_ON,
>> a debugger breakpoint, a perf breakpoint, etc...) calls
>> kprobe_handler(), kprobe_handler() must be prepared to handle the case
>> where the MMU translation is disabled, even if probes are not supposed
>> to be set for functions running with MMU translation disabled.
> 
> Can't we check the MMU is disabled there (as same as checking the exception
> happened in user space or not)?
> 

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 ? 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 ?

Christophe

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  2020-02-17  9:03       ` Christophe Leroy
@ 2020-02-17 10:27         ` Masami Hiramatsu
  2020-02-17 15:38           ` Christophe Leroy
  0 siblings, 1 reply; 9+ messages in thread
From: Masami Hiramatsu @ 2020-02-17 10:27 UTC (permalink / raw)
  To: Christophe Leroy
  Cc: linux-kernel, Anil S Keshavamurthy, Paul Mackerras, stable,
	Naveen N. Rao, linuxppc-dev, David S. Miller, Larry Finger

On Mon, 17 Feb 2020 10:03:22 +0100
Christophe Leroy <christophe.leroy@c-s.fr> wrote:

> 
> 
> Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
> > On Sat, 15 Feb 2020 11:28:49 +0100
> > Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> > 
> >> Hi,
> >>
> >> Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
> >>> Hi,
> >>>
> >>> On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
> >>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> >>>
> >>>> When a program check exception happens while MMU translation is
> >>>> disabled, following Oops happens in kprobe_handler() in the following
> >>>> test:
> >>>>
> >>>> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {
> >>>
> >>> Thanks for the report and patch. I'm not so sure about powerpc implementation
> >>> but at where the MMU translation is disabled, can the handler work correctly?
> >>> (And where did you put the probe on?)
> >>>
> >>> Your fix may fix this Oops, but if the handler needs special care, it is an
> >>> option to blacklist such place (if possible).
> >>
> >> I guess that's another story. Here we are not talking about a place
> >> where kprobe has been illegitimately activated, but a place where there
> >> is a valid trap, which generated a valid 'program check exception'. And
> >> kprobe was off at that time.
> > 
> > Ah, I got it. It is not a kprobe breakpoint, but to check that correctly,
> > it has to know the address where the breakpoint happens. OK.
> > 
> >>
> >> As any 'program check exception' due to a trap (ie a BUG_ON, a WARN_ON,
> >> a debugger breakpoint, a perf breakpoint, etc...) calls
> >> kprobe_handler(), kprobe_handler() must be prepared to handle the case
> >> where the MMU translation is disabled, even if probes are not supposed
> >> to be set for functions running with MMU translation disabled.
> > 
> > Can't we check the MMU is disabled there (as same as checking the exception
> > happened in user space or not)?
> > 
> 
> 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;
 
        /*


Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  2020-02-17 10:27         ` Masami Hiramatsu
@ 2020-02-17 15:38           ` Christophe Leroy
  2020-02-17 17:41             ` Christophe Leroy
  0 siblings, 1 reply; 9+ messages in thread
From: Christophe Leroy @ 2020-02-17 15:38 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: linux-kernel, Anil S Keshavamurthy, Paul Mackerras, stable,
	Naveen N. Rao, linuxppc-dev, David S. Miller, Larry Finger



Le 17/02/2020 à 11:27, Masami Hiramatsu a écrit :
> On Mon, 17 Feb 2020 10:03:22 +0100
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> 
>>
>>
>> Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
>>> On Sat, 15 Feb 2020 11:28:49 +0100
>>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>
>>>> Hi,
>>>>
>>>> Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
>>>>> Hi,
>>>>>
>>>>> On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
>>>>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>>>
>>>>>> When a program check exception happens while MMU translation is
>>>>>> disabled, following Oops happens in kprobe_handler() in the following
>>>>>> test:
>>>>>>
>>>>>> 		} else if (*addr != BREAKPOINT_INSTRUCTION) {
>>>>>
>>>>> Thanks for the report and patch. I'm not so sure about powerpc implementation
>>>>> but at where the MMU translation is disabled, can the handler work correctly?
>>>>> (And where did you put the probe on?)
>>>>>
>>>>> Your fix may fix this Oops, but if the handler needs special care, it is an
>>>>> option to blacklist such place (if possible).
>>>>
>>>> I guess that's another story. Here we are not talking about a place
>>>> where kprobe has been illegitimately activated, but a place where there
>>>> is a valid trap, which generated a valid 'program check exception'. And
>>>> kprobe was off at that time.
>>>
>>> Ah, I got it. It is not a kprobe breakpoint, but to check that correctly,
>>> it has to know the address where the breakpoint happens. OK.
>>>
>>>>
>>>> As any 'program check exception' due to a trap (ie a BUG_ON, a WARN_ON,
>>>> a debugger breakpoint, a perf breakpoint, etc...) calls
>>>> kprobe_handler(), kprobe_handler() must be prepared to handle the case
>>>> where the MMU translation is disabled, even if probes are not supposed
>>>> to be set for functions running with MMU translation disabled.
>>>
>>> Can't we check the MMU is disabled there (as same as checking the exception
>>> happened in user space or not)?
>>>
>>
>> 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.

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.

Christophe

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode
  2020-02-17 15:38           ` Christophe Leroy
@ 2020-02-17 17:41             ` Christophe Leroy
  0 siblings, 0 replies; 9+ messages in thread
From: Christophe Leroy @ 2020-02-17 17:41 UTC (permalink / raw)
  To: Masami Hiramatsu
  Cc: linux-kernel, Anil S Keshavamurthy, stable, Paul Mackerras,
	Naveen N. Rao, linuxppc-dev, David S. Miller, Larry Finger



On 02/17/2020 03:38 PM, Christophe Leroy wrote:
> 
> 
> Le 17/02/2020 à 11:27, Masami Hiramatsu a écrit :
>> On Mon, 17 Feb 2020 10:03:22 +0100
>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>
>>>
>>>
>>> Le 16/02/2020 à 13:34, Masami Hiramatsu a écrit :
>>>> On Sat, 15 Feb 2020 11:28:49 +0100
>>>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Le 14/02/2020 à 14:54, Masami Hiramatsu a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> On Fri, 14 Feb 2020 12:47:49 +0000 (UTC)
>>>>>> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>>>>>>
>>>>>>> When a program check exception happens while MMU translation is
>>>>>>> disabled, following Oops happens in kprobe_handler() in the 
>>>>>>> following
>>>>>>> test:
>>>>>>>
>>>>>>>         } else if (*addr != BREAKPOINT_INSTRUCTION) {
>>>>>>
>>>>>> Thanks for the report and patch. I'm not so sure about powerpc 
>>>>>> implementation
>>>>>> but at where the MMU translation is disabled, can the handler work 
>>>>>> correctly?
>>>>>> (And where did you put the probe on?)
>>>>>>
>>>>>> Your fix may fix this Oops, but if the handler needs special care, 
>>>>>> it is an
>>>>>> option to blacklist such place (if possible).
>>>>>
>>>>> I guess that's another story. Here we are not talking about a place
>>>>> where kprobe has been illegitimately activated, but a place where 
>>>>> there
>>>>> is a valid trap, which generated a valid 'program check exception'. 
>>>>> And
>>>>> kprobe was off at that time.
>>>>
>>>> Ah, I got it. It is not a kprobe breakpoint, but to check that 
>>>> correctly,
>>>> it has to know the address where the breakpoint happens. OK.
>>>>
>>>>>
>>>>> As any 'program check exception' due to a trap (ie a BUG_ON, a 
>>>>> WARN_ON,
>>>>> a debugger breakpoint, a perf breakpoint, etc...) calls
>>>>> kprobe_handler(), kprobe_handler() must be prepared to handle the case
>>>>> where the MMU translation is disabled, even if probes are not supposed
>>>>> to be set for functions running with MMU translation disabled.
>>>>
>>>> Can't we check the MMU is disabled there (as same as checking the 
>>>> exception
>>>> happened in user space or not)?
>>>>
>>>
>>> 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.
> 
> 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.
> 

What about something like that:

@@ -264,6 +265,13 @@ int kprobe_handler(struct pt_regs *regs)
  	if (user_mode(regs))
  		return 0;

+	if (!(regs->msr & MSR_IR)) {
+		if (!get_kprobe(phys_to_virt(regs->nip)))
+			return 0;
+		regs->nip += 4;
+		return 1;
+	}
+
  	/*
  	 * We don't want to be preempted for the entire
  	 * duration of kprobe processing


Christophe

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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-15 10:19 ` Christophe Leroy

LinuxPPC-Dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linuxppc-dev/0 linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ https://lore.kernel.org/linuxppc-dev \
		linuxppc-dev@lists.ozlabs.org linuxppc-dev@ozlabs.org
	public-inbox-index linuxppc-dev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.ozlabs.lists.linuxppc-dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git