Re: [PATCH v4 02/10] user_events: Add minimal support for trace_event into ftrace

[Masami Hiramatsu <mhiramat@kernel.org>]

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>