linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/12] powerpc/entry32: Blacklist exception entry points for kprobe.
Date: Tue, 31 Mar 2020 12:14:27 +0530	[thread overview]
Message-ID: <1585637023.fay3842pux.naveen@linux.ibm.com> (raw)
In-Reply-To: <bc184460-70be-0fe2-0a01-a97ee96652c0@c-s.fr>

Christophe Leroy wrote:
> 
> 
> Le 31/03/2020 à 08:17, Naveen N. Rao a écrit :
>> Christophe Leroy wrote:
>>>
>>>
>>> Le 30/03/2020 à 20:33, Christophe Leroy a écrit :
>>>>
>>>>
>>>> Le 30/03/2020 à 19:08, Naveen N. Rao a écrit :
>>>>> Christophe Leroy wrote:
>>>>>> kprobe does not handle events happening in real mode.
>>>>>>
>>>>>> As exception entry points are running with MMU disabled,
>>>>>> blacklist them.
>>>>>>
>>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>>>> ---
>>>>>>  arch/powerpc/kernel/entry_32.S | 7 +++++++
>>>>>>  1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/powerpc/kernel/entry_32.S 
>>>>>> b/arch/powerpc/kernel/entry_32.S
>>>>>> index 94f78c03cb79..9a1a45d6038a 100644
>>>>>> --- a/arch/powerpc/kernel/entry_32.S
>>>>>> +++ b/arch/powerpc/kernel/entry_32.S
>>>>>> @@ -51,6 +51,7 @@ mcheck_transfer_to_handler:
>>>>>>      mfspr    r0,SPRN_DSRR1
>>>>>>      stw    r0,_DSRR1(r11)
>>>>>>      /* fall through */
>>>>>> +_ASM_NOKPROBE_SYMBOL(mcheck_transfer_to_handler)
>>>>>>
>>>>>>      .globl    debug_transfer_to_handler
>>>>>>  debug_transfer_to_handler:
>>>>>> @@ -59,6 +60,7 @@ debug_transfer_to_handler:
>>>>>>      mfspr    r0,SPRN_CSRR1
>>>>>>      stw    r0,_CSRR1(r11)
>>>>>>      /* fall through */
>>>>>> +_ASM_NOKPROBE_SYMBOL(debug_transfer_to_handler)
>>>>>>
>>>>>>      .globl    crit_transfer_to_handler
>>>>>>  crit_transfer_to_handler:
>>>>>> @@ -94,6 +96,7 @@ crit_transfer_to_handler:
>>>>>>      rlwinm    r0,r1,0,0,(31 - THREAD_SHIFT)
>>>>>>      stw    r0,KSP_LIMIT(r8)
>>>>>>      /* fall through */
>>>>>> +_ASM_NOKPROBE_SYMBOL(crit_transfer_to_handler)
>>>>>>  #endif
>>>>>>
>>>>>>  #ifdef CONFIG_40x
>>>>>> @@ -115,6 +118,7 @@ crit_transfer_to_handler:
>>>>>>      rlwinm    r0,r1,0,0,(31 - THREAD_SHIFT)
>>>>>>      stw    r0,KSP_LIMIT(r8)
>>>>>>      /* fall through */
>>>>>> +_ASM_NOKPROBE_SYMBOL(crit_transfer_to_handler)
>>>>>>  #endif
>>>>>>
>>>>>>  /*
>>>>>> @@ -127,6 +131,7 @@ crit_transfer_to_handler:
>>>>>>      .globl    transfer_to_handler_full
>>>>>>  transfer_to_handler_full:
>>>>>>      SAVE_NVGPRS(r11)
>>>>>> +_ASM_NOKPROBE_SYMBOL(transfer_to_handler_full)
>>>>>>      /* fall through */
>>>>>>
>>>>>>      .globl    transfer_to_handler
>>>>>> @@ -286,6 +291,8 @@ reenable_mmu:
>>>>>>      lwz    r2, GPR2(r11)
>>>>>>      b    fast_exception_return
>>>>>>  #endif
>>>>>> +_ASM_NOKPROBE_SYMBOL(transfer_to_handler)
>>>>>> +_ASM_NOKPROBE_SYMBOL(transfer_to_handler_cont)
>>>>>
>>>>> These are added after 'reenable_mmu', which is itself not 
>>>>> blacklisted. Is that intentional?
>>>>
>>>> Yes I put it as the complete end of the entry part, ie just before 
>>>> stack_ovf which is a function by itself.
>>>>
>>>> Note that reenable_mmu is inside an #ifdef CONFIG_TRACE_IRQFLAGS.
>>>>
>>>> I'm not completely sure where to put the _ASM_NOKPROBE_SYMBOL()s, 
>>>> that's the reason why I put it close to the symbol itself in my first 
>>>> series.
>>>>
>>>> Could you have a look at the code and tell me what looks the most 
>>>> appropriate as a location to you ?
>>>>
>>>> https://elixir.bootlin.com/linux/v5.6/source/arch/powerpc/kernel/entry_32.S#L230 
>>>
>>>
>>> Ok, thinking about it once more, I guess we have a problem as 
>>> everything after that reenable_mmu will be visible.
>> 
>> I see that we reach reenable_mmu through a 'rfi' with MSR_KERNEL, which 
>> seems safe to me. So, I figured it can be probed without issues?
> 
> Yes it can. And that's the reason why I didn't blacklist it. However the 
> 4: and 7: which are after reenable_mmu are called from earlier, at a 
> time we are still in real mode. So I need to do something about that I 
> guess.

Ah yes, good catch. Makes sense to move 'reenable_mmu' after all.

Thanks,
Naveen


  reply	other threads:[~2020-03-31  6:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-29  9:41 [PATCH 01/12] powerpc/52xx: Blacklist functions running with MMU disabled for kprobe Christophe Leroy
2020-03-29  9:41 ` [PATCH 02/12] powerpc/82xx: Blacklist pq2_restart() " Christophe Leroy
2020-03-29  9:41 ` [PATCH 03/12] powerpc/83xx: Blacklist mpc83xx_deep_resume() " Christophe Leroy
2020-03-29  9:41 ` [PATCH 04/12] powerpc/powermac: Blacklist functions running with MMU disabled " Christophe Leroy
2020-03-29  9:41 ` [PATCH 05/12] powerpc/mem: Blacklist flush_dcache_icache_phys() " Christophe Leroy
2020-03-29  9:41 ` [PATCH 06/12] powerpc/32s: Make local symbols non visible in hash_low Christophe Leroy
2020-03-30 17:06   ` Naveen N. Rao
2020-03-30 17:22     ` Christophe Leroy
2020-03-30 17:49       ` Naveen N. Rao
2020-03-29  9:41 ` [PATCH 07/12] powerpc/32s: Blacklist functions running with MMU disabled for kprobe Christophe Leroy
2020-03-29  9:41 ` [PATCH 08/12] powerpc/rtas: Remove machine_check_in_rtas() Christophe Leroy
2020-03-29  9:41 ` [PATCH 09/12] powerpc/32: Blacklist functions running with MMU disabled for kprobe Christophe Leroy
2020-03-29  9:41 ` [PATCH 10/12] powerpc/entry32: Blacklist exception entry points " Christophe Leroy
2020-03-30 17:08   ` Naveen N. Rao
2020-03-30 18:33     ` Christophe Leroy
2020-03-31  5:51       ` Christophe Leroy
2020-03-31  6:17         ` Naveen N. Rao
2020-03-31  6:28           ` Christophe Leroy
2020-03-31  6:44             ` Naveen N. Rao [this message]
2020-03-31  6:13       ` Naveen N. Rao
2020-03-29  9:41 ` [PATCH 11/12] powerpc/entry32: Blacklist syscall exit " Christophe Leroy
2020-03-29  9:41 ` [PATCH 12/12] powerpc/entry32: Blacklist exception " Christophe Leroy
2020-03-30 17:13 ` [PATCH 01/12] powerpc/52xx: Blacklist functions running with MMU disabled " Naveen N. Rao

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=1585637023.fay3842pux.naveen@linux.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.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).