ptrace PTRACE_PEEKUSER behavior

ptrace PTRACE_PEEKUSER behavior

[Anoop]

The call ptrace(PTRACE_PEEKUSER, <pid>, ...) does not work as described in the
man page.

Specifically, the man page states:
PTRACE_PEEKUSER
	Reads a word at offset addr in the child's USER area, which
	holds the registers and other information about the process (see
	<linux/user.h> and <sys/user.h>). The word is returned as the
	result of the ptrace() call. Typically the offset must be word-
	aligned, though this might vary by architecture. (data is
	ignored.)

Using the PTRACE_PEEKUSER action, the "regs" component can be read, but the
values past regs are not obtained. Even the reg values are not  
retrieved from a
'user' structure, but from the 'task_struct' of the process.

linux-2.6.26-rc1/include/asm-x86/user_32.h defines struct user like this.

/* When the kernel dumps core, it starts by dumping the user struct -
this will be used by gdb to figure out where the data and stack segments
are within the file, and what virtual addresses to use. */
struct user{
	/* We start with the registers, to mimic the way that "memory" is returned
	from the ptrace(3,...) function. */
	struct user_regs_struct regs; /* Where the registers are actually stored
	*/
	/* ptrace does not yet supply these. Someday.... */ <===================
	int u_fpvalid; /* True if math co-processor being used. */
	/* for this mess. Not yet used. */
	struct user_i387_struct i387; /* Math Co-processor registers. */
	/* The rest of this junk is to help gdb figure out what goes where */
	unsigned long int u_tsize; /* Text segment size (pages). */
	unsigned long int u_dsize; /* Data segment size (pages). */
	unsigned long int u_ssize; /* Stack segment size (pages). */
	unsigned long start_code; /* Starting virtual address of text. */
	unsigned long start_stack; /* Starting virtual address of stack area.
	This is actually the bottom of the stack, the top of the stack is always
	found in the	esp register. */
	long int signal; /* Signal that caused the core dump. */
	int reserved; /* No longer used */
	struct user_pt_regs * u_ar0; /* Used by gdb to help find the values for */
	/* the registers. */
	struct user_i387_struct* u_fpstate; /* Math Co-processor pointer. */
	unsigned long magic; /* To uniquely identify a core file */
	char u_comm[32]; /* User command that was responsible */
	int u_debugreg[8];
};

Noting the comment after 'struct user_regs_struct regs', is there any specific
reason why ptrace doesn't provide the rest of the members of this  
structure? In
that case shouldn't the man pages be corrected?

- Anoop

Re: ptrace PTRACE_PEEKUSER behavior

[Andi Kleen]

Anoop <acv@linux.vnet.ibm.com> writes:

[intentional fullquote]

> The call ptrace(PTRACE_PEEKUSER, <pid>, ...) does not work as described in the
> man page.
>
> Specifically, the man page states:
> PTRACE_PEEKUSER
> 	Reads a word at offset addr in the child's USER area, which
> 	holds the registers and other information about the process (see
> 	<linux/user.h> and <sys/user.h>). The word is returned as the
> 	result of the ptrace() call. Typically the offset must be word-
> 	aligned, though this might vary by architecture. (data is
> 	ignored.)
>
> Using the PTRACE_PEEKUSER action, the "regs" component can be read, but the
> values past regs are not obtained. Even the reg values are not  
> retrieved from a
> 'user' structure, but from the 'task_struct' of the process.
>
> linux-2.6.26-rc1/include/asm-x86/user_32.h defines struct user like this.

[..]
>
> /* When the kernel dumps core, it starts by dumping the user struct -

[..]
> 	*/
> 	/* ptrace does not yet supply these. Someday.... */ <===================
> 	/* for this mess. Not yet used. */
> 	struct user_i387_struct i387; /* Math Co-processor registers. */
> 	/* The rest of this junk is to help gdb figure out what goes where */
> 	unsigned long int u_tsize; /* Text segment size (pages). */
> 	unsigned long int u_dsize; /* Data segment size (pages). */
> 	unsigned long int u_ssize; /* Stack segment size (pages). */
> 	unsigned long start_code; /* Starting virtual address of text. */
> 	unsigned long start_stack; /* Starting virtual address of stack area.
> 	This is actually the bottom of the stack, the top of the stack is always
> 	found in the	esp register. */
> 	long int signal; /* Signal that caused the core dump. */
> 	int reserved; /* No longer used */
> 	struct user_pt_regs * u_ar0; /* Used by gdb to help find the values for */
> 	/* the registers. */
> 	struct user_i387_struct* u_fpstate; /* Math Co-processor pointer. */
> 	unsigned long magic; /* To uniquely identify a core file */
> 	char u_comm[32]; /* User command that was responsible */
> 	int u_debugreg[8];
> };
>
> Noting the comment after 'struct user_regs_struct regs', is there any specific
> reason why ptrace doesn't provide the rest of the members of this  
> structure?

Since Linux internally has no "struct user" all of this has to be
implemented by special case code (in particularly a big switch statement)
While that could be done if nobody uses it (and that seems
to be the case) it would be just a waste of code.

> In
> that case shouldn't the man pages be corrected?

Probably. cc mtk.

-Andi

Re: ptrace PTRACE_PEEKUSER behavior

[Michael Kerrisk]

On 5/5/08, Andi Kleen <andi@firstfloor.org> wrote:
> Anoop <acv@linux.vnet.ibm.com> writes:
>
>  [intentional fullquote]
>
>
>  > The call ptrace(PTRACE_PEEKUSER, <pid>, ...) does not work as described in the
>  > man page.
>  >
>  > Specifically, the man page states:
>  > PTRACE_PEEKUSER
>  >       Reads a word at offset addr in the child's USER area, which
>  >       holds the registers and other information about the process (see
>  >       <linux/user.h> and <sys/user.h>). The word is returned as the
>  >       result of the ptrace() call. Typically the offset must be word-
>  >       aligned, though this might vary by architecture. (data is
>  >       ignored.)
>  >
>  > Using the PTRACE_PEEKUSER action, the "regs" component can be read, but the
>  > values past regs are not obtained. Even the reg values are not
>  > retrieved from a
>  > 'user' structure, but from the 'task_struct' of the process.
>  >
>  > linux-2.6.26-rc1/include/asm-x86/user_32.h defines struct user like this.
>
>  [..]
>  >
>  > /* When the kernel dumps core, it starts by dumping the user struct -
>
>
> [..]
>
> >       */
>  >       /* ptrace does not yet supply these. Someday.... */ <===================
>
> >       /* for this mess. Not yet used. */
>  >       struct user_i387_struct i387; /* Math Co-processor registers. */
>  >       /* The rest of this junk is to help gdb figure out what goes where */
>  >       unsigned long int u_tsize; /* Text segment size (pages). */
>  >       unsigned long int u_dsize; /* Data segment size (pages). */
>  >       unsigned long int u_ssize; /* Stack segment size (pages). */
>  >       unsigned long start_code; /* Starting virtual address of text. */
>  >       unsigned long start_stack; /* Starting virtual address of stack area.
>  >       This is actually the bottom of the stack, the top of the stack is always
>  >       found in the    esp register. */
>  >       long int signal; /* Signal that caused the core dump. */
>  >       int reserved; /* No longer used */
>  >       struct user_pt_regs * u_ar0; /* Used by gdb to help find the values for */
>  >       /* the registers. */
>  >       struct user_i387_struct* u_fpstate; /* Math Co-processor pointer. */
>  >       unsigned long magic; /* To uniquely identify a core file */
>  >       char u_comm[32]; /* User command that was responsible */
>  >       int u_debugreg[8];
>  > };
>  >
>  > Noting the comment after 'struct user_regs_struct regs', is there any specific
>  > reason why ptrace doesn't provide the rest of the members of this
>  > structure?
>
>
> Since Linux internally has no "struct user" all of this has to be
>  implemented by special case code (in particularly a big switch statement)
>  While that could be done if nobody uses it (and that seems
>  to be the case) it would be just a waste of code.
>
>
>  > In
>  > that case shouldn't the man pages be corrected?
>
>
> Probably. cc mtk.

Anoop would you be able to write a patch for the the man page?  (Yoou
can get the latest page in a tarball at the location below.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: ptrace PTRACE_PEEKUSER behavior

[Roland McGrath]

'struct user' is really a virtual structure layout, and never exists
anywhere as an actual struct.  It's really just defining the argument
values that can be used in PEEKUSR/POKEUSR calls.  Its details are
completely machine-specific.  On x86, only the user_regs_struct parts at
the beginning, and the u_debugreg parts near the end, are offsets that are
valid in ptrace calls.  The other elements in x86's 'struct user' are just
historical cruft now.  Any documentation of the details would have to be
given for all the different arch layouts.


Thanks,
Roland

Re: ptrace PTRACE_PEEKUSER behavior

[Anoop]

Quoting Roland McGrath <roland@redhat.com>:

> 'struct user' is really a virtual structure layout, and never exists
> anywhere as an actual struct.  It's really just defining the argument
> values that can be used in PEEKUSR/POKEUSR calls.

But the powerpc ptrace code returns the FPRs & FPSCR though they are  
not part of user struct.

CHECK_FULL_REGS(child->thread.regs);
if (index < PT_FPR0) {
		tmp = ptrace_get_reg(child, (int) index);
} else { <=============
		flush_fp_to_thread(child);
		tmp = ((unsigned long *)child->thread.fpr)[index - PT_FPR0];
}
ret = put_user(tmp,(unsigned long __user *) data);

Does this mandate inclusion of floating point set in powerpc user struct?

Regards,
- Anoop

Re: ptrace PTRACE_PEEKUSER behavior

[Roland McGrath]

> 
> Quoting Roland McGrath <roland@redhat.com>:
> 
> > 'struct user' is really a virtual structure layout, and never exists
> > anywhere as an actual struct.  It's really just defining the argument
> > values that can be used in PEEKUSR/POKEUSR calls.
> 
> But the powerpc ptrace code returns the FPRs & FPSCR though they are  
> not part of user struct.

I guess I was too strong in describing 'struct user' as useful even in that
sense.  Each arch defines the offset values for its PEEKUSR/POKEUSR, and on
powerpc the asm/ptrace.h PT_* macros are the only true definition of that ABI.

'struct user' is used in a.out core dumps, if those can even still be
generated on powerpc.  Other than that, the struct is actually meaningless
cruft on powerpc.  On other machines it's almost that, except that e.g. on
x86 there is no other definition than offsetof(struct user, u_debugreg[0])
to supply that offset for PTRACE_POKEUSR.

> Does this mandate inclusion of floating point set in powerpc user struct?

I think what it mandates is dropping any idea that 'struct user' is
necessarily meaningful in any generic sense.  The only use it has is
arch-specific cases where offsetof(struct user, something) is part of the
ptrace ABI.


Thanks,
Roland