mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jacob Wen <jian.w.wen@oracle.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 2/2] tracing: Add a verifier to check string pointers for trace events
Date: Mon, 7 Jun 2021 13:24:32 -0400	[thread overview]
Message-ID: <20210607132432.08287102@oasis.local.home> (raw)
In-Reply-To: <YL5DE9vqDG/fUSMh@google.com>

On Mon, 7 Jun 2021 16:02:27 +0000
Sean Christopherson <seanjc@google.com> wrote:

> I assumed that was the gist of the unsafe string detection, but the module core
> data exemption confused me.  I take it that the tracepoint itself goes away if
> the module is unloaded?  I.e. it's safe for a module to pass a constant string to
> its own tracepoints, but not to tracepoints defined elsewhere?  The comment
> above tracepoint_string() seems to confirm this.


If a trace event of a module was enabled, a flag is set, so that when
that module is unloaded, the ring buffer that it was enabled in is
cleared. That's because there's more data that is referenced about the
trace event then just strings. And referencing that data is dangerous
if it no longer exists.

> 
> > There's two fixes you can do with this. One is to covert that to use
> > __string, the other is to do what RCU does, and use the
> > tracepoint_string() functionality.

I realize now that tracepoint_string() is not a work around. It only is
or exporting the string to user space. The __string option is really
the only fix here.



> This doesn't appear to be correct.  Were you thinking of something else?
> 
> Unless I'm misreading the code and section output, tracepoint_string() just saves
> a pointer to the string into a dedicated section, it doesn't magically hoist the
> string itself into the kernel proper.  And I can't see how that would work, e.g.
> if the module is compiled and linked independent from the core kernel.

That is correct. I was mistaken about it. It has some code to track
unloading, and I was thinking it saved the string itself, but that is
not correct.

> 
> And the comment above the macro strongly suggests that persistence needs to be
> guaranteed by the entity using tracepoint_string().  Testing bears this out, e.g.
> the WARN and UNSAFE_MEMORY errors still happen when using tracepoint_string().

That is correct. I misspoke when I suggested using it. :-/


> 
>  * The @str used must be a constant string and persistent as it would not
>  * make sense to show a string that no longer exists. But it is still fine
>  * to be used with modules, because when modules are unloaded, if they
>  * had tracepoints, the ring buffers are cleared too. As long as the string
>  * does not change during the life of the module, it is fine to use
>  * tracepoint_string() within a module.
>  */
> #define tracepoint_string(str)						\
> 	({								\
> 		static const char *___tp_str __tracepoint_string = str; \
> 		___tp_str;						\
> 	})
> 
> 
> Thanks for the help!

No problem.

-- Steve

  reply	other threads:[~2021-06-07 17:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 18:59 [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from " Steven Rostedt
2021-02-26 18:59 ` [PATCH 1/2] tracing: Add check of trace event print fmts for dereferencing pointers Steven Rostedt
2021-02-27 14:16   ` [tracing] 5c71984c21: WARNING:at_kernel/trace/trace_events.c:#test_event_printk kernel test robot
2021-02-26 18:59 ` [PATCH 2/2] tracing: Add a verifier to check string pointers for trace events Steven Rostedt
2021-06-05  1:20   ` Sean Christopherson
2021-06-05  2:28     ` Steven Rostedt
2021-06-05  2:45       ` Steven Rostedt
2021-06-07 16:02         ` Sean Christopherson
2021-06-07 17:24           ` Steven Rostedt [this message]
2021-02-26 22:21 ` [PATCH 0/2] tracing: Detect unsafe dereferencing of pointers from " Linus Torvalds
2021-02-26 23:33   ` Steven Rostedt
2021-02-27  4:04     ` Joe Perches
2021-02-27 19:18   ` Steven Rostedt
2021-02-28  0:08     ` Steven Rostedt
2021-03-01  5:27       ` Pawel Laszczak
2021-03-02  8:23         ` Peter Chen
2021-03-02 14:56           ` Steven Rostedt
2021-03-03  1:21             ` Peter Chen
2021-03-03  1:54               ` Steven Rostedt
2021-03-07  4:01             ` Peter Chen
2021-03-07 21:14               ` Steven Rostedt

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=20210607132432.08287102@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=jian.w.wen@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®