This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Preventing a tapscript from accessing user space.
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: David Wilder <dwilder at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: 10 Jun 2007 13:22:50 -0400
- Subject: Re: Preventing a tapscript from accessing user space.
- References: <45C7CE21.6090103@us.ibm.com>
David Wilder wrote (some time ago):
> [...] For example: if $arg is a pointer to a struct in user space
> (presumably passed to the kernel via some system call). What
> prevents me from doing i=$arg->j in the tapscript?
Nothing - we can't. The "__user" modifier doesn't make it into the
debugging data. The old bug #2049 outlines a way of letting the
script explicitly designate user- vs. kernel-space pointer
dereferences.
> Also when I looked at the code generated by stap I was hoping to see
> deref() used but that is not what I found.
There should be one there, inside the generated "tvar_get" function.
> On i386 the above example works ok because we can just access the
> user space, it works but it is not correct. On s390 I can't do that
> I must use something like get_user(), but I cant do that ether
> because get_user() calls might_sleep() and the probe is running with
> interrupts off.
The i386 code is predicated on the assumption that user-space accesses
are possible with ordinary loads/stores, but exceptions are caught and
returned as -EFAULT values rather than sleeping or whatnot.
- FChE