All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Andreas Ziegler <andreas.ziegler@fau.de>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: uprobes: bug in comm/string output?
Date: Thu, 17 Jan 2019 18:47:17 +0900	[thread overview]
Message-ID: <20190117184717.9bbd1218b9f4fe6a8070a0fe@kernel.org> (raw)
In-Reply-To: <17147ef5-4348-9a02-d781-0f089fe603f5@fau.de>

On Thu, 17 Jan 2019 09:08:41 +0100
Andreas Ziegler <andreas.ziegler@fau.de> wrote:

> On 17.01.19 09:00, Masami Hiramatsu wrote:
> > On Thu, 17 Jan 2019 15:13:09 +0900
> > Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > 
> >> On Wed, 16 Jan 2019 11:16:07 +0100
> >> Andreas Ziegler <andreas.ziegler@fau.de> wrote:
> >>
> >>>
> >>> I went into this a bit deeper today, and right now it is simply failing 
> >>> to parse the code because there is no FETCH_OP_COMM case in 
> >>> process_fetch_insn() for uprobes so that will return -EILSEQ, leading to 
> >>> a make_data_loc(0, ...) in store_trace_args(). If we just add 
> >>> FETCH_OP_COMM and let val point to current->comm (that's what 
> >>> trace_kprobe.c does), we get an -EFAULT return value from 
> >>> fetch_store_string because strncpy_from_user() checks if the argument is 
> >>> in user space.
> >>
> >> Correct. I missed to add OP_COMM support. And uprobe's fetch_store_string
> >> is only for user space strings.
> >>
> >>> So I think we might need a special case for that, something like 
> >>> FETCH_OP_ST_COMM_STRING which is only used for FETCH_OP_COMM and copies 
> >>> current->comm over to the dynamic area. The implementation could be 
> >>> similar to the old fetch_comm_string implementation before your rewrite.
> >>
> >> Hmm, instead, I would like to add current->comm checker and only allows
> >> to copy that. That would be simpler and enough.
> >>
> >> Could you test below patch?
> >>
> >>
> >> tracing: uprobes: Re-enable $comm support for uprobe events
> >>
> >> From: Masami Hiramatsu <mhiramat@kernel.org>
> >>
> >> Since commit 533059281ee5 ("tracing: probeevent: Introduce new
> >> argument fetching code") dropped the $comm support from uprobe
> >> events, this re-enable it.
> 
> this should read 're-enables'.
> 
> >>
> >> For $comm support, use strncpy() instead of strncpy_from_user()
>                              ^
> we're using strlcpy(), not strncpy().
> 
> >> to copy current task's comm. Because it is in the kernel space,
> >> strncpy_from_user() always fails to copy the comm.
> >> This also use strlen() instead of strlen_user() to measure the
>                ^                        ^
> 'uses', and the function should be 'strnlen_user()'.
> 
> >> length of the comm.
> >>
> >> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> >> Reported-by: Andreas Ziegler <andreas.ziegler@fau.de>
> >> ---
> >>  kernel/trace/trace_uprobe.c |   13 +++++++++++--
> >>  1 file changed, 11 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> >> index e335576b9411..97d134e83e0f 100644
> >> --- a/kernel/trace/trace_uprobe.c
> >> +++ b/kernel/trace/trace_uprobe.c
> >> @@ -156,7 +156,10 @@ fetch_store_string(unsigned long addr, void *dest, void *base)
> >>  	if (unlikely(!maxlen))
> >>  		return -ENOMEM;
> >>  
> >> -	ret = strncpy_from_user(dst, src, maxlen);
> >> +	if (addr == (unsigned long)current->comm)
> >> +		ret = strlcpy(dst, current->comm, maxlen);
> >> +	else
> >> +		ret = strncpy_from_user(dst, src, maxlen);
> >>  	if (ret >= 0) {
> >>  		if (ret == maxlen)
> >>  			dst[ret - 1] = '\0';
> >> @@ -173,7 +176,10 @@ fetch_store_strlen(unsigned long addr)
> >>  	int len;
> >>  	void __user *vaddr = (void __force __user *) addr;
> >>  
> >> -	len = strnlen_user(vaddr, MAX_STRING_SIZE);
> >> +	if (addr == (unsigned long)current->comm)
> >> +		len = strlen(current->comm);
> > 
> > To balance with the strnlen_user, we must increse the len in this block.
> > (strlen doesn't count the final '\0', but strnlen_user counts it)
> > 
> 
> yes, we need to add a '+ 1' here.
> 
> With the typos and this one fixed, this is
> 
> Acked-by: Andreas Ziegler <andreas.ziegler@fau.de>

Thank you for fixing typo and Ack :)

Thanks you,

> 
> > Thank you,
> > 
> >> +	else
> >> +		len = strnlen_user(vaddr, MAX_STRING_SIZE);
> >>  
> >>  	return (len > MAX_STRING_SIZE) ? 0 : len;
> >>  }
> >> @@ -213,6 +219,9 @@ process_fetch_insn(struct fetch_insn *code, struct pt_regs *regs, void *dest,
> >>  	case FETCH_OP_IMM:
> >>  		val = code->immediate;
> >>  		break;
> >> +	case FETCH_OP_COMM:
> >> +		val = (unsigned long)current->comm;
> >> +		break;
> >>  	case FETCH_OP_FOFFS:
> >>  		val = translate_user_vaddr(code->immediate);
> >>  		break;
> > 
> > 
> 


-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2019-01-17  9:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-14 12:38 uprobes: bug in comm/string output? Andreas Ziegler
2019-01-15 13:36 ` Andreas Ziegler
2019-01-16  9:41   ` [PATCH] tracing/uprobes: Fix output for multiple string arguments Andreas Ziegler
2019-01-16 13:40     ` Steven Rostedt
2019-01-16 14:13       ` Andreas Ziegler
2019-01-16 14:16       ` [PATCH v2] " Andreas Ziegler
2019-01-16 14:34         ` Steven Rostedt
2019-01-17  6:01         ` Masami Hiramatsu
2019-01-17  7:40           ` Andreas Ziegler
2019-01-17  7:58             ` Masami Hiramatsu
2019-01-17 14:20               ` Steven Rostedt
2019-01-17 14:29                 ` Andreas Ziegler
2019-01-17 14:51                   ` Steven Rostedt
2019-01-17 15:14                     ` Andreas Ziegler
2019-01-17 15:35                       ` Steven Rostedt
2019-01-16 10:00   ` uprobes: bug in comm/string output? Masami Hiramatsu
2019-01-16 10:16     ` Andreas Ziegler
2019-01-17  6:13       ` Masami Hiramatsu
2019-01-17  8:00         ` Masami Hiramatsu
2019-01-17  8:08           ` Andreas Ziegler
2019-01-17  9:47             ` Masami Hiramatsu [this message]
2019-01-17 13:44               ` Andreas Ziegler
2019-01-17 13:47                 ` Greg Kroah-Hartman
2019-01-17 23:50                 ` Masami Hiramatsu

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=20190117184717.9bbd1218b9f4fe6a8070a0fe@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=andreas.ziegler@fau.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rostedt@goodmis.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.