linux-kernel - Re: ptrace PTRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 May 2008 14:45:42 +0200
From:	"Michael Kerrisk" <mtk.manpages@...il.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	Anoop <acv@...ux.vnet.ibm.com>, linux-kernel@...r.kernel.org,
	roland@...hat.com, mtk.manpages@...glemail.com
Subject: Re: ptrace PTRACE_PEEKUSER behavior

On 5/5/08, Andi Kleen <andi@...stfloor.org> wrote:
> Anoop <acv@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/