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:   Thu, 11 Nov 2021 09:33:34 -0800
From:   Beau Belgrave <beaub@...ux.microsoft.com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     Steven Rostedt <rostedt@...dmis.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 Wed, Nov 10, 2021 at 10:56:30PM +0900, Masami Hiramatsu wrote:
> On Tue, 9 Nov 2021 11:08:44 -0800
> Beau Belgrave <beaub@...ux.microsoft.com> wrote:

> I would like to keep verifying in writer side then we can ensure the
> data on ring buffer (of perf and of ftrace) is sane. If you add the unsafe
> flag, you have to change all the code which access the ring buffer, not only
> the filter but also eprobes, histograms, perf-tools, and other user-space
> tracing tools which reads the tracing buffer directly.
> 
> > It sounded like Steven wanted to think about this a bit, so I'll wait a
> > bit before poking again for consensus :)
> > 
> > Do you have any strong feelings about where it goes?
> 
> I recommend you to start verifying the writer side, it should make the
> change as small as possible. Unsafe flag idea may involve many other
> tools. And it is not fundamentary required for user-events.
> 
> Thank you,
> 
> -- 
> Masami Hiramatsu <mhiramat@...nel.org>

Ok, I will start there.

Are static string buffers required as well for the null check?

Or is this only for dyn strings that require the check?

Also, I am assuming that __rel_loc offset is based after the __rel_loc
payload, IE: Offset 0 of __rel_loc is immediately after the 4 byte
__rel_loc description?

Thanks,
-Beau