lkml.org 
[lkml]   [2019]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v6 4/6] tracing/probe: Support user-space dereference
On Wed, 8 May 2019 13:11:43 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> On Mon, 6 May 2019 11:52:26 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Mon, 18 Mar 2019 15:43:52 +0900
> > Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > > +.. _user_mem_access:
> > > +User Memory Access
> > > +------------------
> > > +Kprobe events supports user-space memory access. For that purpose, you can use
> > > +either user-space dereference syntax or 'ustring' type.
> > > +
> > > +The user-space dereference syntax allows you to access a field of a data
> > > +structure in user-space. This is done by adding the "u" prefix to the
> > > +dereference syntax. For example, +u4(%si) means it will read memory from the
> > > +address in the register %si offset by 4, and the mory is expected to be in
> >
> > ^^^^
> > "memory"
>
> OK, thanks!
>
> >
> > > +user-space. You can use this for strings too, e.g. +u0(%si):string will read
> > > +a string from the address in the register %si that is expected to be in user-
> > > +space. 'ustring' is a shortcut way of performing the same task. That is,
> > > ++0(%si):ustring is equivalent to +u0(%si):string.
> > > +
> > > +Note that kprobe-event provides the user-memory access syntax but it doesn't
> > > +use it transparently. This means if you use normal dereference or string type
> > > +for user memory, it might fail, and always fails on some arch. So user has to
> >
> > "and may always fail on some archs. The user has to carefully check
> > if the target data is in kernel or user space."
>
> OK. I'll update.
>
> > > +check if the targe data is in kernel or in user space carefully.
> > >
> > > Per-Probe Event Filtering
> > > -------------------------
> > > diff --git a/Documentation/trace/uprobetracer.rst b/Documentation/trace/uprobetracer.rst
> > > index 4346e23e3ae7..de8812c932bc 100644
> > > --- a/Documentation/trace/uprobetracer.rst
> > > +++ b/Documentation/trace/uprobetracer.rst
> > > @@ -42,16 +42,17 @@ Synopsis of uprobe_tracer
> > > @+OFFSET : Fetch memory at OFFSET (OFFSET from same file as PATH)
> > > $stackN : Fetch Nth entry of stack (N >= 0)
> > > $stack : Fetch stack address.
> > > - $retval : Fetch return value.(*)
> > > + $retval : Fetch return value.(\*1)
> > > $comm : Fetch current task comm.
> > > - +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
> > > + +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS address.(\*2)(\*3)
> > > NAME=FETCHARG : Set NAME as the argument name of FETCHARG.
> > > FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types
> > > (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types
> > > (x8/x16/x32/x64), "string" and bitfield are supported.
> >
> > Hmm, shouldn't uprobes default to userspace. Isn't the purpose mostly
> > to find out what's going on in userspace. Perhaps we should add a 'k'
> > annotation to uprobes to denote that it's for kernel space, as that
> > should be the exception and not the norm.
>
> No, uprobe can not access kernel space, because it doesn't have the
> current kernel context. Note that all registers, stacks which
> can be accessed from uprobe handler are user-space. We can not access
> kernel context from that. See below
>
> > > - (*) only for return probe.
> > > - (**) this is useful for fetching a field of data structures.
> > > + (\*1) only for return probe.
> > > + (\*2) this is useful for fetching a field of data structures.
> > > + (\*3) Unlike kprobe event, "u" prefix will just be ignored.
>
> Thus the 'u' is just ignored on uprobe event.

I totally missed the footnote here. Can we stress this point more up in
the "User Memory Access" section. Specifically state something like:
"Uprobes only access userspace memory, thus the 'u' is not required,
and if it is added to a uprobe, it will simply be ignored".

Thanks!

-- Steve

\
 
 \ /
  Last update: 2019-05-08 17:24    [W:0.079 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site