public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Re: probes that access userspace
       [not found] <E55D.2090005__29732.3145241991$1129302467$gmane$org@us.ibm.com>
@ 2005-10-14 16:23 ` Frank Ch. Eigler
  2005-10-14 19:10   ` Kevin Stafford
  2005-10-14 21:09   ` Jim Keniston
  0 siblings, 2 replies; 7+ messages in thread
From: Frank Ch. Eigler @ 2005-10-14 16:23 UTC (permalink / raw)
  To: Kevin Stafford; +Cc: systemtap


kevinrs wrote:

> Especially when considering syscall tapset there are times when it
> is useful to access the value referenced by a user space
> pointer. [...]

> Is dwarf able to provide enough information to accurately detect a
> user space pointer reference? [...]

No, there appears to be no such qualification data in the debuginfo at
all.  IIRC, the preprocessor makes __user go away before the compiler
ever sees it.

> [...]  If this is not possible, I think it would be useful to
> enhance the language such that a probe script could explicitly
> notify the translator of a user space pointer access [...]

Perhaps.  Other than the system call interfaces, is this difficulty
likely to arise often elsewhere?

> This will be especially beneficial for scripts probing user-space
> apps. Eventually, when SystemTap supports user-space probes, the
> translator will need to know how to follow pointers in user space.

Not quite.  For user-level probes, there is no ambiguity: every
pointer dereference is in user space.

- FChE

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: probes that access userspace
  2005-10-14 16:23 ` probes that access userspace Frank Ch. Eigler
@ 2005-10-14 19:10   ` Kevin Stafford
  2005-10-14 19:21     ` Frank Ch. Eigler
  2005-10-14 21:09   ` Jim Keniston
  1 sibling, 1 reply; 7+ messages in thread
From: Kevin Stafford @ 2005-10-14 19:10 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: systemtap

Frank Ch. Eigler wrote:

>>[...]  If this is not possible, I think it would be useful to
>>enhance the language such that a probe script could explicitly
>>notify the translator of a user space pointer access [...]
>>    
>>
>Perhaps.  Other than the system call interfaces, is this difficulty
>likely to arise often elsewhere?
>
>[...] For user-level probes, there is no ambiguity: every
>pointer dereference is in user space.
>  
>
Being that for user-level probes, every pointer dereference is in user 
space, I believe
it is certain that this difficulty will arise elsewhere.

-- 
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: probes that access userspace
  2005-10-14 19:10   ` Kevin Stafford
@ 2005-10-14 19:21     ` Frank Ch. Eigler
  0 siblings, 0 replies; 7+ messages in thread
From: Frank Ch. Eigler @ 2005-10-14 19:21 UTC (permalink / raw)
  To: Kevin Stafford; +Cc: systemtap

Hi -

On Fri, Oct 14, 2005 at 12:11:15PM -0700, Kevin Stafford wrote:
> >>[...]  If this is not possible, I think it would be useful to
> >>enhance the language such that a probe script could explicitly
> >>notify the translator of a user space pointer access [...]
> >>   
> >Perhaps.  Other than the system call interfaces, is this difficulty
> >likely to arise often elsewhere?
> >
> >[...] For user-level probes, there is no ambiguity: every
> >pointer dereference is in user space.
>
> Being that for user-level probes, every pointer dereference is in
> user space, I believe it is certain that this difficulty will arise
> elsewhere.

Perhaps I was being unclear.  The "difficulty" I was referring to was
the ambiguity in whether an ordinary or special dereference operation
is required for any given $var->field expression.  It is this
ambiguity that could be resolved by the user via a language extension,
and it is this ambiguity that does not exist for variables that show
up in user-level probes.


- FChE

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: probes that access userspace
  2005-10-14 16:23 ` probes that access userspace Frank Ch. Eigler
  2005-10-14 19:10   ` Kevin Stafford
@ 2005-10-14 21:09   ` Jim Keniston
  2005-10-14 22:15     ` Roland McGrath
  1 sibling, 1 reply; 7+ messages in thread
From: Jim Keniston @ 2005-10-14 21:09 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Kevin Stafford, SystemTAP

On Fri, 2005-10-14 at 09:23, Frank Ch. Eigler wrote:
> kevinrs wrote:
> 
> > Especially when considering syscall tapset there are times when it
> > is useful to access the value referenced by a user space
> > pointer. [...]
> 
> > Is dwarf able to provide enough information to accurately detect a
> > user space pointer reference? [...]
> 
> No, there appears to be no such qualification data in the debuginfo at
> all.  IIRC, the preprocessor makes __user go away before the compiler
> ever sees it.

That's my understanding as well.

> 
> > [...]  If this is not possible, I think it would be useful to
> > enhance the language such that a probe script could explicitly
> > notify the translator of a user space pointer access [...]
> 
> Perhaps.  Other than the system call interfaces, is this difficulty
> likely to arise often elsewhere?

Almost certainly.  According to cscope, there are over 8700 uses of
__user in the kernel source.  This should not be a surprise if you
consider that the whole point of an OS is to implement system calls.

> 
> > This will be especially beneficial for scripts probing user-space
> > apps. Eventually, when SystemTap supports user-space probes, the
> > translator will need to know how to follow pointers in user space.
> 
> Not quite.  For user-level probes, there is no ambiguity: every
> pointer dereference is in user space.

Correct, there's no ambiguity.  So you're not likely to need a "-> into
user-space" operator when probing user apps.  The trickier problem of
making safe refs to user space from (kernel-space) probe handlers
remains, though.

> 
> - FChE
> 

Jim

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: probes that access userspace
  2005-10-14 21:09   ` Jim Keniston
@ 2005-10-14 22:15     ` Roland McGrath
  0 siblings, 0 replies; 7+ messages in thread
From: Roland McGrath @ 2005-10-14 22:15 UTC (permalink / raw)
  To: Jim Keniston; +Cc: Frank Ch. Eigler, Kevin Stafford, SystemTAP

> > No, there appears to be no such qualification data in the debuginfo at
> > all.  IIRC, the preprocessor makes __user go away before the compiler
> > ever sees it.
> 
> That's my understanding as well.

It's certainly possible to do a compiler extension to express __user in the
DWARF type info.  I've considered it, and can discuss it further with the
compiler folks.  That solution is a long-term prospect--it would be
unlikely to happen by GCC 4.1, and might never be backported to compilers
like RHEL4's.  

However, we've also gotten the opinion from at least one kernel developer
that relying on __user annotations is still insufficiently paranoid.  That
is, they might be missing from some kernel source, and so any time you
access a pointer you are taking your fate in your own hands since it might
be an unannotated user-mode pointer.  I'm not sure there is anything more
to be done about that concern than state the caveat.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: probes that access userspace
@ 2005-10-14 21:12 Kevin Stafford
  0 siblings, 0 replies; 7+ messages in thread
From: Kevin Stafford @ 2005-10-14 21:12 UTC (permalink / raw)
  To: systemtap

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]


-- 
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com




[-- Attachment #2: Re: probes that access userspace --]
[-- Type: message/rfc822, Size: 1839 bytes --]

From: Kevin Stafford <kevinrs@us.ibm.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: probes that access userspace
Date: Fri, 14 Oct 2005 14:10:53 -0700
Message-ID: <43501EDD.2070003@us.ibm.com>

Frank Ch. Eigler wrote:

>Hi -
>
>[...]
>
>>Being that for user-level probes, every pointer dereference is in
>>user space, I believe it is certain that this difficulty will arise
>>elsewhere.
>>    
>>
>
>Perhaps I was being unclear.  The "difficulty" I was referring to was
>the ambiguity in whether an ordinary or special dereference operation
>is required for any given $var->field expression.
>
Understood. The "difficulty" I was referring to was the necessity to 
write embedded
C auxiliary functions to access user-space pointer arguments.

>[...]It is this ambiguity that could be resolved by the user via a 
>language extension, and it is this ambiguity that does not exist for 
>variables that show up in user-level probes.
>  
>
Agreed. A language extension would require the script writer to know 
where the
pointer was looking, thus eliminating any ambiguity or difficulty. Do we 
agree that
this would be a useful mechanism for user-level probes and the syscall 
tapset, among
possible others?

>- FChE
>
>  
>


-- 
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com





^ permalink raw reply	[flat|nested] 7+ messages in thread

* probes that access userspace
@ 2005-10-14 15:05 Kevin Stafford
  0 siblings, 0 replies; 7+ messages in thread
From: Kevin Stafford @ 2005-10-14 15:05 UTC (permalink / raw)
  To: systemtap

Especially when considering syscall tapset there are times when it is 
useful to access
the value referenced by a user space pointer. In probe script language, 
such an attempt
(i.e. $userspace_struct->member) will cause a pointer dereference fault. 
Thus it is
necessary to write a function to dig the value out of the pointer 
manually. Ex:

_get_user_ptr_val($userspace_struct,member) _get_user_ptr_val

function _get_user_ptr_val(u_addr,mem) %{
   [...]
   copy_from_user(..., THIS->u_addr, ...);
   [...]
%}

Is dwarf able to provide enough information to accurately detect a user 
space pointer
reference? If so, is it possible to teach the translator to bring 
references of user
space into the kernel automagically? Such a mechanism would relieve the 
user/tapset
author from writing an embedded C function for every pointer they wanted 
to look at.
The current implementation does not support such behavior.

If this is not possible, I think it would be useful to enhance the 
language such that
a probe script could explicitly notify the translator of a user space 
pointer access
(perhaps *var for scalars & *struct=>mem for structs). This will be 
especially
beneficial for scripts probing user-space apps. Eventually, when 
SystemTap supports
user-space probes, the translator will need to know how to follow 
pointers in user space.

-- 
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-10-14 22:15 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <E55D.2090005__29732.3145241991$1129302467$gmane$org@us.ibm.com>
2005-10-14 16:23 ` probes that access userspace Frank Ch. Eigler
2005-10-14 19:10   ` Kevin Stafford
2005-10-14 19:21     ` Frank Ch. Eigler
2005-10-14 21:09   ` Jim Keniston
2005-10-14 22:15     ` Roland McGrath
2005-10-14 21:12 Kevin Stafford
  -- strict thread matches above, loose matches on Subject: below --
2005-10-14 15:05 Kevin Stafford

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).