linux-kernel - Re: [PATCH v4 02/10] user_events: Add minimal support for trace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Nov 2021 13:58:03 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        linux-trace-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [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@...ux.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@...ux.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@...nel.org>