user space target symbol dereferencing

[Mark Wielaard <mwielaard at redhat dot com>]

Hi all,

Here are some ideas on extending the tapset language with some kind of
user space dereferencing constructs. I tried a couple of things out to
get a better feeling of the systemtap parser and the translator. But I
don't have a good feeling on what is really wanted/needed. I did have
some discussions with Frank on all this on irc. And he suggested to
just write it all up and send it to the list. So comments welcome.

After playing a bit with the ctime stuff I looked into what might be
needed to use less embedded C for these tapsets. Currently a lot of
the helper functions in aux_syscalls.stp use embedded C for things
like:

# Given a userspace pointer to a timeval,
# copy and decode it and return a string.
#
function _struct_timeval_u:string(uaddr:long, n:long)

So the initial idea was that we needed something for dereferecing things
like system call user space arguments. Instead of using -> and []
you would operators like => and :[]: to denote deref to user space
(better syntax suggestions appreciated). Such dereferences would
translate to explicit set_fs(USER_DS) access_ok() checks and using
__stp_get_user() to make sure you wouldn't end up somewhere that user
space doesn't have access to.

This is kind of ugly (but maybe that is just the chosen syntax) and so
I came up with having two kinds of target symbols, the normal "kernel
context" ones $foo and the "user context" ones denoted with %foo. Then
you could just use the normal syntax and do %foo->bar[16] and all
dereferences would always be confined to user space.

Then we thought it might just work directly by guessing whether the
target symbol/dereferenced pointer is in user space using the existing
constructs and do a set_fs(USER_DS) and then an access_ok() to see if
it a pointer already in user space. But that would basically just add
overhead without really adding new functionality. Also someone could
"spoof" a pointer in kernel space (say as argument to a syscall)
getting around any user space access checks you would like to see
done.

While trying some of the above out I happily mistyped things and saw
that deref() just works fine because set_fs(KERNEL_DS) doesn't
actually constrain the addresses to kernel space. Is this true for all
architectures? If so and we don't need/want any "type safety" on user
space access checks we could just rewrite most things in
aux_syscalls.stp by direct dereferencing through -> and [] anyway.

In all of the above I assumed we would want some kind of "type safety"
because we are seeing more user space probing working, but they still
run in kernel context. My idea was that you would have these safety
constraints through the tapset syntax of defining target symbols and/or
dereferencing (=>) constructs. But maybe there are completely
different ideas in this space?

One issue with any of this is that the "embedded C" versions work
without needing dwarf info since they include the C header files and
so have all the info during compile time. On the other hand this is
kind of cheating since if you have the source code around then you
probably also have the debuginfo around. Maybe we even need a
simple data type definition so you could write at least simple structs
out "by hand" and somehow get the C compiler to provide us with the
offsets for use in dwarfless probes. I didn't try this, I am probably
missing lots of nasty details.

Frank pointed to bug #4166 - Should support array-like indexing on
$pointer variables, and bug #2049 - revise $target->subfield syntax,
which contains the items:
- To allow "." to denote subfields, likely with a syntax wrapper
  $(foo.bar)
- To permit numeric experssions (rather than just number literals)
  as array indexes
That are related to all the above, but need less
"policy/syntax/semantics" decisions up front. I might work on those
first before tackling any of the above again. So people can give a bit
more feedback and concrete suggestions on the "user space" targets
first.

Cheers,

Mark