All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
	"Ananth N Mavinakayanahalli" <ananth@in.ibm.com>,
	x86@kernel.org, lkml <linux-kernel@vger.kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Borislav Petkov" <bp@suse.de>
Subject: Re: [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text
Date: Tue, 05 Nov 2013 21:35:28 +0900	[thread overview]
Message-ID: <5278E610.2010202@hitachi.com> (raw)
In-Reply-To: <5278D89B.1070806@hitachi.com>

(2013/11/05 20:38), Masami Hiramatsu wrote:
> (2013/11/05 16:05), Ingo Molnar wrote:
>>
>> * Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
>>
>>> (2013/11/05 15:09), Ingo Molnar wrote:
>>>>
>>>> * Steven Rostedt <rostedt@goodmis.org> wrote:
>>>>
>>>>> On Fri, 01 Nov 2013 11:25:37 +0000
>>>>> Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
>>>>>
>>>>>> Prohibit probing on func_ptr_is_kernel_text().
>>>>>> Since the func_ptr_is_kernel_text() is called from
>>>>>> notifier_call_chain() which is called from int3 handler,
>>>>>> probing it may cause double int3 fault and kernel will
>>>>>> reboot.
>>>>>>
>>>>>> This happenes when the kernel built with CONFIG_DEBUG_NOTIFIERS=y.
>>>>>>
>>>>>> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
>>>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>>>> Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
>>>>>> Cc: Borislav Petkov <bp@suse.de>
>>>>>> Cc: Ingo Molnar <mingo@kernel.org>
>>>>>> ---
>>>>>>  kernel/extable.c |    2 +-
>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/kernel/extable.c b/kernel/extable.c
>>>>>> index 832cb28..022fb25 100644
>>>>>> --- a/kernel/extable.c
>>>>>> +++ b/kernel/extable.c
>>>>>> @@ -129,7 +129,7 @@ int kernel_text_address(unsigned long addr)
>>>>>>   * pointer is part of the kernel text, we need to do some
>>>>>>   * special dereferencing first.
>>>>>>   */
>>>>>> -int func_ptr_is_kernel_text(void *ptr)
>>>>>> +int nokprobe func_ptr_is_kernel_text(void *ptr)
>>>>>>  {
>>>>>>  	unsigned long addr;
>>>>>>  	addr = (unsigned long) dereference_function_descriptor(ptr);
>>>>>>
>>>>>
>>>>> One thing I worry about the "nokprobe" annotation, is that it moves the 
>>>>> location of the function out of local. This function no exists in the 
>>>>> section with its users. Same with the debug functions in the other 
>>>>> patch.
>>>>
>>>> Well, it's a bit like noinline, that changes the position of the function 
>>>> as well. So it's not true that 'noxyz' attributes don't affect function 
>>>> placement - they often don't, but some do.
>>>>
>>>> The more important aspect is that 'noprobe' makes it really, really 
>>>> apparent what the tag is about, at first sight.
>>>>
>>>> _How_ the 'non probing' is achived is an implementational detail when 
>>>> kprobes are enabled: right now it puts a function into a separate section, 
>>>> but we could just a much build a list of function names and check against 
>>>> it at probe insertion time.
>>>
>>> Actually, kprobes already has it -- kprobes_blacklist. Currently the 
>>> list is manually maintained in kprobes.c separated from the function 
>>> definition. [...]
>>
>> Yes, I meant a list that is built automatically from the 'noprobe' 
>> annotations.
> 
> Agreed. That makes maintenance work simple, and we can remove
> ".kprobes.text" section.
> 
>>> [...] I hope to build the list when the kernel build time if possible... 
>>> Would you have any idea to classify some annotated(but no side-effect) 
>>> functions?
>>
>> The macro magic I can think of would need to change the syntax of the 
>> function definition - for example that is how the SYSCALL_DEFINE*() macros 
>> work.
> 
> Would you mean something like the below macro? :)
> 
> NOKPROBE_SYMBOL(int, func_ptr_is_kernel_text)(void *ptr)
> 
> which is expanded as;
> 
> static struct nokprobe_entry __used
> __nokprobe_entry_func_ptr_is_kernel_text = {
>   .name = "func_ptr_is_kernel_text"
> };
> static struct kprobe_blacklist_entry __used
> __attribute__((section("_nokprobe_list")))
> __p_nokprobe_entry_func_ptr_is_kernel_text = &__nokprobe_entry_func_ptr_is_kernel_text;
> int func_ptr_is_kernel_text(void *ptr)
> 

By the way, this method can be done in C file, but not in asm file.
And there are many sensitive entries in the entry_*.S. I think we have
two options.

(A) keep the kprobes.text(or nokprobe.text) section for such assembler parts.
(B) Put a starter symbol and end symbol in such region and make a list
 of symbols between them in build time by using nm.

Anyway, until removing all __kprobes from kernel, we can not remove the
kprobes.text section. So, at the first step I just try to introduce
above macro and apply it to only the symbols in kprobes_blacklist.
After that, I'll try to classify the real unsafe entries and apply
the new macro. Eventually, I think I can remove all __kprobes.

Thank you,


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com



  reply	other threads:[~2013-11-05 12:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 11:25 [PATCH -tip v2 0/3] kprobes: introduce nokprobe and updating blacklist Masami Hiramatsu
2013-11-01 11:25 ` [PATCH -tip v2 1/3] kprobes: Introduce nokprobe annotation for non-probe-able functions Masami Hiramatsu
2013-11-01 13:55   ` Steven Rostedt
2013-11-05  1:45     ` Masami Hiramatsu
2013-11-01 11:25 ` [PATCH -tip v2 2/3] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_* Masami Hiramatsu
2013-11-01 13:56   ` Steven Rostedt
2013-11-01 11:25 ` [PATCH -tip v2 3/3] [BUGFIX] kprobes: Prohibit probing on func_ptr_is_kernel_text Masami Hiramatsu
2013-11-01 13:57   ` Steven Rostedt
2013-11-05  2:00   ` Steven Rostedt
2013-11-05  3:15     ` Masami Hiramatsu
2013-11-05  6:09     ` Ingo Molnar
2013-11-05  6:59       ` Masami Hiramatsu
2013-11-05  7:05         ` Ingo Molnar
2013-11-05 11:38           ` Masami Hiramatsu
2013-11-05 12:35             ` Masami Hiramatsu [this message]
2013-11-06  6:07             ` Ingo Molnar
2013-11-06 10:34               ` Masami Hiramatsu
2013-11-06 11:50                 ` Ingo Molnar
2013-11-06 12:21               ` Steven Rostedt
2013-11-05 13:13           ` Steven Rostedt

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=5278E610.2010202@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.