lkml.org 
[lkml]   [2021]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 02/10] user_events: Add minimal support for trace_event into ftrace
On Mon, 8 Nov 2021 14:09:45 -0800
Beau Belgrave <beaub@linux.microsoft.com> wrote:

> On Mon, Nov 08, 2021 at 04:00:27PM -0500, Steven Rostedt wrote:
> > On Mon, 8 Nov 2021 12:25:27 -0800
> > Beau Belgrave <beaub@linux.microsoft.com> wrote:
> >
> > > 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?
> >
> > If these are "user defined" then perhaps we add a wrapper to the filtering
> > that is called instead of the normal filtering for theses events that
> > verify the fields of the events being filtered are located on the ring
> > buffer. Although, strings and such are rare or just slow in filtering that
> > we could make sure the content is still on the buffer that is being
> > filtered.
> >
>
> It seems like both histograms and filter both reference field flags to
> determine how to get the data.
>
> How would you feel about another FILTER_* flag on fields, like:
> FILTER_DYN_STRING_SAFE
> FILTER_PTR_STRING_SAFE
>
> user_events when parsing would instead of leaving FILTER_OTHER for
> __data_loc / __rel_loc switch to the above.
>
> The predicate filter method would then switch based on those types to
> safer versions.
>
> That way other parts could take advantage of this if needed beyond
> user_events.
>
> If this is addressed at the filter/histogram level, would then the write
> callsites still check bounds per-write? Or maybe only care about the
> undersized data cases?

Even with the unsafe flags, I think the callsites still needs
the undersized check at least. It may have the maxsize and minsize
for the events. If the event defined with dynamic data
(__data_loc/__rel_loc), minsize is the sum of the field size and
maxsize will be the PAGE_SIZE (or smaller than that). If the event
has no dynamic data field, minsize == maxsize.

Thank you,

--
Masami Hiramatsu <mhiramat@kernel.org>

\
 
 \ /
  Last update: 2021-11-09 05:59    [W:0.100 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site