linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Beau Belgrave <beaub@linux.microsoft.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 02/10] user_events: Add minimal support for trace_event into ftrace
Date: Mon, 8 Nov 2021 12:25:27 -0800	[thread overview]
Message-ID: <20211108202527.GA1862@kbox> (raw)
In-Reply-To: <20211108131639.33a4f186@gandalf.local.home>

On Mon, Nov 08, 2021 at 01:16:39PM -0500, Steven Rostedt wrote:
> On Mon, 8 Nov 2021 09:13:36 -0800
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> 
> 
> > Does that mean the decoders in eprobes/histogram don't check event
> > record sizes before accessing the data? Shouldn't that get fix
> > centrally? That would mean a loaded module could do the same thing
> > (user_events only works if the user has access to tracefs, so it's not
> > like it's open to all users).
> 
> There's checks to make sure everything fits in eprobes and kprobes. If it
> doesn't then the event is simply dropped.
> 
> For example, if you look at __eprobe_trace_func() in trace_eprobe.c, you'll
> see that it calls get_eprobe_size(), which goes through and just reads what
> it is about to accept. Then it reserves the amount of data on the ring
> buffer, and then calls store_trace_args() which also passes in the size
> that it found, in case things change. If it's too big, it only records what
> it originally intended.
> 
> -- Steve

It seems there are 2 concerns:
1. If data comes in and it's not in the size that is specified, it's
suspicious and should either be truncated or ignored. Maybe under
ignore, over truncate.

2. If the data is more than specified, it must be checked to see if
there are __data_loc / __rel_loc entries and they must be validated as
within range of accepted limits. If there are no __data_loc / __rel_loc
it should either be truncated or ignored.

Is there more that I may have missed?

I'd like to know if I do fix them that the features like filtering will still
be available to user_events or if it's better to just add flags to disable
kernel filtering?

I'm still unsure this is limited to just user_events.

For example, why doesn't filter_pred_strloc and filter_pred_pchar in
trace_events_filter.c check the boundary it will be accessing?

It seems like tracepoints from kernel modules, while more trusted, can also
cause this kind of thing due to bugs, etc.

Thanks,
-Beau

  reply	other threads:[~2021-11-08 20:25 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 17:04 [PATCH v4 00/10] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 01/10] user_events: Add UABI header for user access to user_events Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 02/10] user_events: Add minimal support for trace_event into ftrace Beau Belgrave
2021-11-04 21:34   ` kernel test robot
2021-11-08  2:32     ` Masami Hiramatsu
2021-11-08 16:59       ` Beau Belgrave
2021-11-07 14:31   ` Masami Hiramatsu
2021-11-08 17:13     ` Beau Belgrave
2021-11-08 18:16       ` Steven Rostedt
2021-11-08 20:25         ` Beau Belgrave [this message]
2021-11-08 21:00           ` Steven Rostedt
2021-11-08 22:09             ` Beau Belgrave
2021-11-08 22:30               ` Steven Rostedt
2021-11-08 22:59                 ` Beau Belgrave
2021-11-09  4:58               ` Masami Hiramatsu
2021-11-09  2:56           ` Masami Hiramatsu
2021-11-09 19:08             ` Beau Belgrave
2021-11-09 19:25               ` Steven Rostedt
2021-11-09 20:14                 ` Beau Belgrave
2021-11-09 20:45                   ` Steven Rostedt
2021-11-09 21:27                     ` Beau Belgrave
2021-11-09 21:39                       ` Steven Rostedt
2021-11-10 13:56               ` Masami Hiramatsu
2021-11-11 17:33                 ` Beau Belgrave
2021-11-12 13:40                   ` Masami Hiramatsu
2021-11-07 18:18   ` Steven Rostedt
2021-11-08 19:56     ` Beau Belgrave
2021-11-08 20:53       ` Steven Rostedt
2021-11-08 21:15         ` Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 03/10] user_events: Add print_fmt generation support for basic types Beau Belgrave
2021-11-08 22:03   ` Steven Rostedt
2021-11-04 17:04 ` [PATCH v4 04/10] user_events: Handle matching arguments from dyn_events Beau Belgrave
2021-11-08 22:05   ` Steven Rostedt
2021-11-04 17:04 ` [PATCH v4 05/10] user_events: Add basic perf and eBPF support Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 06/10] user_events: Add self-test for ftrace integration Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 07/10] user_events: Add self-test for dynamic_events integration Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 08/10] user_events: Add self-test for perf_event integration Beau Belgrave
2021-11-04 17:04 ` [PATCH v4 09/10] user_events: Optimize writing events by only copying data once Beau Belgrave
2021-11-08 22:45   ` Steven Rostedt
2021-11-08 23:00     ` Beau Belgrave
2021-11-08 23:04       ` Steven Rostedt
2021-11-08 23:17         ` Beau Belgrave
2021-11-08 23:20           ` Steven Rostedt
2021-11-04 17:04 ` [PATCH v4 10/10] user_events: Add documentation file Beau Belgrave
2021-11-04 19:05   ` Jonathan Corbet
2021-11-04 21:08     ` Beau Belgrave
2021-11-04 21:18       ` Jonathan Corbet

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=20211108202527.GA1862@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).