linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: rostedt@goodmis.org, linux-trace-devel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 13/13] user_events: Use __get_rel_str for relative string fields
Date: Mon, 13 Dec 2021 10:47:23 -0800	[thread overview]
Message-ID: <20211213184723.GA10317@kbox> (raw)
In-Reply-To: <20211213001215.366afbe59715ed5aa1e2e865@kernel.org>

On Mon, Dec 13, 2021 at 12:12:15AM +0900, Masami Hiramatsu wrote:
> On Fri, 10 Dec 2021 10:45:51 -0800
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> 
> > On Fri, Dec 10, 2021 at 10:23:27AM +0900, Masami Hiramatsu wrote:
> > > Hi Beau,
> > > 
> > > On Thu,  9 Dec 2021 14:32:10 -0800
> > > Beau Belgrave <beaub@linux.microsoft.com> wrote:
> > > 
> > > > Switch between __get_str and __get_rel_str within the print_fmt of
> > > > user_events. Add unit test to ensure print_fmt is correct on known
> > > > types.
> > > > 
> > > > Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
> > > > ---
> > > >  kernel/trace/trace_events_user.c              |  24 ++-
> > > >  .../selftests/user_events/ftrace_test.c       | 166 ++++++++++++++++++
> > > >  2 files changed, 182 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/kernel/trace/trace_events_user.c b/kernel/trace/trace_events_user.c
> > > > index 56eb58ddb4cf..3779fa2ca14a 100644
> > > > --- a/kernel/trace/trace_events_user.c
> > > > +++ b/kernel/trace/trace_events_user.c
> > > > @@ -257,7 +257,7 @@ static int user_event_add_field(struct user_event *user, const char *type,
> > > >  	goto add_field;
> > > >  
> > > >  add_validator:
> > > > -	if (strstr(type, "char[") != 0)
> > > > +	if (strstr(type, "char") != 0)
> > > >  		validator_flags |= VALIDATOR_ENSURE_NULL;
> > > 
> > > What is this change for? This seems not related to the other changes.
> > > (Also, what happen if it is a single char type?)
> > > 
> > 
> > I'm glad you asked, it appears like __data_loc / __rel_loc can take char
> > as it's type (It doesn't appear to be limited to char[] cases). I wanted
> > to ensure something malicious couldn't sneak past by using this corner
> > case.
> > 
> > IE: __data_loc char test
> > 
> > In trace_events_filter.c:
> > int filter_assign_type(const char *type)
> > {
> >         if (strstr(type, "__data_loc") && strstr(type, "char"))
> >                 return FILTER_DYN_STRING;
> > 
> >         if (strchr(type, '[') && strstr(type, "char"))
> >                 return FILTER_STATIC_STRING;
> > 
> >         if (strcmp(type, "char *") == 0 || strcmp(type, "const char *") == 0)
> >                 return FILTER_PTR_STRING;
> > 
> >         return FILTER_OTHER;
> > }
> > 
> > char[ is only checked if __data_loc is not specified.
> 
> OK, but in that case, is this patch good place for that change?
> 

I'll move this to part 12.

> > 
> > > >  
> > > >  	validator = kmalloc(sizeof(*validator), GFP_KERNEL);
> > > > @@ -456,14 +456,21 @@ static const char *user_field_format(const char *type)
> > > >  	return "%llu";
> > > >  }
> > > >  
> > > > -static bool user_field_is_dyn_string(const char *type)
> > > > +static bool user_field_is_dyn_string(const char *type, const char **str_func)
> > > >  {
> > > > -	if (str_has_prefix(type, "__data_loc ") ||
> > > > -	    str_has_prefix(type, "__rel_loc "))
> > > > -		if (strstr(type, "char[") != 0)
> > > > -			return true;
> > > > +	if (str_has_prefix(type, "__data_loc ")) {
> > > > +		*str_func = "__get_str";
> > > > +		goto check;
> > > > +	}
> > > > +
> > > > +	if (str_has_prefix(type, "__rel_loc ")) {
> > > > +		*str_func = "__get_rel_str";
> > > > +		goto check;
> > > > +	}
> > > >  
> > > >  	return false;
> > > > +check:
> > > > +	return strstr(type, "char") != 0;
> > > >  }
> > > >  
> > > >  #define LEN_OR_ZERO (len ? len - pos : 0)
> > > > @@ -472,6 +479,7 @@ static int user_event_set_print_fmt(struct user_event *user, char *buf, int len)
> > > >  	struct ftrace_event_field *field, *next;
> > > >  	struct list_head *head = &user->fields;
> > > >  	int pos = 0, depth = 0;
> > > > +	const char *str_func;
> > > >  
> > > >  	pos += snprintf(buf + pos, LEN_OR_ZERO, "\"");
> > > >  
> > > > @@ -488,9 +496,9 @@ static int user_event_set_print_fmt(struct user_event *user, char *buf, int len)
> > > >  	pos += snprintf(buf + pos, LEN_OR_ZERO, "\"");
> > > >  
> > > >  	list_for_each_entry_safe_reverse(field, next, head, link) {
> > > > -		if (user_field_is_dyn_string(field->type))
> > > > +		if (user_field_is_dyn_string(field->type, &str_func))
> > > >  			pos += snprintf(buf + pos, LEN_OR_ZERO,
> > > > -					", __get_str(%s)", field->name);
> > > > +					", %s(%s)", str_func, field->name);
> > > >  		else
> > > >  			pos += snprintf(buf + pos, LEN_OR_ZERO,
> > > >  					", REC->%s", field->name);
> > > > diff --git a/tools/testing/selftests/user_events/ftrace_test.c b/tools/testing/selftests/user_events/ftrace_test.c
> > > 
> > > Just a nitpick, if possible, please split this part from the kernel update.
> > > 
> > 
> > I will try to do so, could you help me understand why I would split this
> > out? (For future patches)
> > 
> > I thought the intention of each would be to contain it's logical grouping:
> > I wanted to show, yes the code changed, and yes we have a unit test for
> > that new condition.
> 
> Hrm, in this specific case, maybe this can be acceptable. Following
> case you might need to take care of it.
> 
> - if the feature and the test code are maintained by different maintainer.
> - if the test code is added much later than the feature.
> 
> In both case, the piece of patches will be applied separately. The former
> case, by different maintainer, the latter case by different tree (e.g. 
> stable tree may not have the test case.)
> 
> BTW, I also think this change is a fix for the previous patches in the series.
> In that case, please update those patches so that the patch is completely works.
> That will be good for bisecting.
> 

Do you mean you want the rest of this change rolled into 04/13 (print_fmt
generation)?

And have the char vs char[ rolled into 12/13 (add validators)?

I can then roll the unit test for this case under 05/13 (ftrace
selftest).

Thanks,
-Beau


  reply	other threads:[~2021-12-13 18:47 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09 22:31 [PATCH v7 00/13] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-12-09 22:31 ` [PATCH v7 01/13] user_events: Add UABI header for user access to user_events Beau Belgrave
2021-12-10 13:30   ` Masami Hiramatsu
2021-12-10 17:29     ` Beau Belgrave
2021-12-09 22:31 ` [PATCH v7 02/13] user_events: Add minimal support for trace_event into ftrace Beau Belgrave
2021-12-10 10:43   ` Masami Hiramatsu
2021-12-10 17:43     ` Steven Rostedt
2021-12-13  0:09       ` Masami Hiramatsu
2021-12-13 16:48         ` Steven Rostedt
2021-12-10 18:03     ` Beau Belgrave
2021-12-13  4:24       ` Masami Hiramatsu
2021-12-13 17:58         ` Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 03/13] user_events: Add print_fmt generation support for basic types Beau Belgrave
2021-12-10  2:50   ` Masami Hiramatsu
2021-12-09 22:32 ` [PATCH v7 04/13] user_events: Handle matching arguments from dyn_events Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 05/13] user_events: Add basic perf and eBPF support Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 06/13] user_events: Add self-test for ftrace integration Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 07/13] user_events: Add self-test for dynamic_events integration Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 08/13] user_events: Add self-test for perf_event integration Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 09/13] user_events: Optimize writing events by only copying data once Beau Belgrave
2021-12-10 14:51   ` Masami Hiramatsu
2021-12-10 18:36     ` Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 10/13] user_events: Add documentation file Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 11/13] user_events: Add sample code for typical usage Beau Belgrave
2021-12-09 22:32 ` [PATCH v7 12/13] user_events: Validate user payloads for size and null termination Beau Belgrave
2021-12-10 14:46   ` Masami Hiramatsu
2021-12-09 22:32 ` [PATCH v7 13/13] user_events: Use __get_rel_str for relative string fields Beau Belgrave
2021-12-10  1:23   ` Masami Hiramatsu
2021-12-10 18:45     ` Beau Belgrave
2021-12-12 15:12       ` Masami Hiramatsu
2021-12-13 18:47         ` Beau Belgrave [this message]
2021-12-14  6:30           ` 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=20211213184723.GA10317@kbox \
    --to=beaub@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --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 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).