Re: ptrace in 2.6.5

Re: ptrace in 2.6.5

[Andi Kleen]

Fabiano Ramos <ramos_fabiano@yahoo.com.br> writes:

> Hi All.
>
>      Is ptrace(), in singlestep mode, required to stop after a int 0x80?
>     When tracing a sequence like
>
> 	mov ...
> 	int 0x80
> 	mov ....
>
>     ptrace would notify the tracer after the two movs, but not after the
> int 0x80. I want to know if it is a bug or the expected behaviour.

What happens is that after the int 0x80 the CPU is in ring 0 (you
don't get an trace event in that mode unless you use a kernel debugger). 
Then when the kernel returns the last instruction executed before it is an 
IRET. But the IRET is also executed still in ring 0 and you should not get 
an event for it (you can not even access its code from user space).

So it's expected behaviour.

-Andi

Re: ptrace in 2.6.5

[Davide Libenzi]

On Mon, 10 May 2004, Andi Kleen wrote:

> Fabiano Ramos <ramos_fabiano@yahoo.com.br> writes:
> 
> > Hi All.
> >
> >      Is ptrace(), in singlestep mode, required to stop after a int 0x80?
> >     When tracing a sequence like
> >
> > 	mov ...
> > 	int 0x80
> > 	mov ....
> >
> >     ptrace would notify the tracer after the two movs, but not after the
> > int 0x80. I want to know if it is a bug or the expected behaviour.
> 
> What happens is that after the int 0x80 the CPU is in ring 0 (you
> don't get an trace event in that mode unless you use a kernel debugger). 
> Then when the kernel returns the last instruction executed before it is an 
> IRET. But the IRET is also executed still in ring 0 and you should not get 
> an event for it (you can not even access its code from user space).
> 
> So it's expected behaviour.

IIRC, it's the "int" instruction that automatically clears the TF bit from 
flags. The next "iret" will restore the caller flags and re-enable the TF bit.



- Davide

Re: ptrace in 2.6.5

[Fabiano Ramos]

On Mon, 2004-05-10 at 15:49, Andi Kleen wrote:
> Fabiano Ramos <ramos_fabiano@yahoo.com.br> writes:
> 
> > Hi All.
> >
> >      Is ptrace(), in singlestep mode, required to stop after a int 0x80?
> >     When tracing a sequence like
> >
> > 	mov ...
> > 	int 0x80
> > 	mov ....
> >
> >     ptrace would notify the tracer after the two movs, but not after the
> > int 0x80. I want to know if it is a bug or the expected behaviour.
> 
> What happens is that after the int 0x80 the CPU is in ring 0 (you
> don't get an trace event in that mode unless you use a kernel debugger). 
> Then when the kernel returns the last instruction executed before it is an 
> IRET. But the IRET is also executed still in ring 0 and you should not get 
> an event for it (you can not even access its code from user space).
> 
> So it's expected behaviour.
> 
> -Andi

I got it. But I need it to stop after the instruction. I am a newbie,
so is it trivial to patch the kernel so that it STOPS after the int
0x80? Can  you give me some light on it?

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ptrace in 2.6.5

[OGAWA Hirofumi]

Fabiano Ramos <ramos_fabiano@yahoo.com.br> writes:

> > >      Is ptrace(), in singlestep mode, required to stop after a int 0x80?
> > >     When tracing a sequence like
> > >
> > > 	mov ...
> > > 	int 0x80
> > > 	mov ....
> > >
> > >     ptrace would notify the tracer after the two movs, but not after the
> > > int 0x80. I want to know if it is a bug or the expected behaviour.
> > 
> > What happens is that after the int 0x80 the CPU is in ring 0 (you
> > don't get an trace event in that mode unless you use a kernel debugger). 
> > Then when the kernel returns the last instruction executed before it is an 
> > IRET. But the IRET is also executed still in ring 0 and you should not get 
> > an event for it (you can not even access its code from user space).
> 
> I got it. But I need it to stop after the instruction. I am a newbie,
> so is it trivial to patch the kernel so that it STOPS after the int
> 0x80? Can  you give me some light on it?

This is the behavior of CPU, not kernel. "iret" after "int 0x80",
it restores the eip to "mov ...".

 	int 0x80
        		does syscall
                        iret
 	mov ....
                  <---- exception here (eip = "next insn")
	next insn
        
So single-step exception happen *after* executed the "mov ...".
Probably you need to use the breakpoint instead of single-step.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: ptrace in 2.6.5

[OGAWA Hirofumi]

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:

> So single-step exception happen *after* executed the "mov ...".
> Probably you need to use the breakpoint instead of single-step.

Ah, sorry. Just use PTRACE_SYSCALL instead of PTRACE_SINGLESTEP.
It's will stop before/after does syscall.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: ptrace in 2.6.5

[Daniel Jacobowitz]

On Tue, May 11, 2004 at 07:47:08AM +0900, OGAWA Hirofumi wrote:
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> 
> > So single-step exception happen *after* executed the "mov ...".
> > Probably you need to use the breakpoint instead of single-step.
> 
> Ah, sorry. Just use PTRACE_SYSCALL instead of PTRACE_SINGLESTEP.
> It's will stop before/after does syscall.

Doing it this way is pretty lousy - you have to inspect the code after
every step to see if it's an int $0x80.  Is there some reason not to
report a trap on the syscall return path if single-stepping?

-- 
Daniel Jacobowitz

Re: ptrace in 2.6.5

[Davide Libenzi]

On Mon, 10 May 2004, Daniel Jacobowitz wrote:

> On Tue, May 11, 2004 at 07:47:08AM +0900, OGAWA Hirofumi wrote:
> > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> > 
> > > So single-step exception happen *after* executed the "mov ...".
> > > Probably you need to use the breakpoint instead of single-step.
> > 
> > Ah, sorry. Just use PTRACE_SYSCALL instead of PTRACE_SINGLESTEP.
> > It's will stop before/after does syscall.
> 
> Doing it this way is pretty lousy - you have to inspect the code after
> every step to see if it's an int $0x80.  Is there some reason not to
> report a trap on the syscall return path if single-stepping?

Well, the "iret" restore TF, and Intel states that the TF flag must be set 
at the beginning of the instruction for the trap to be fired. The next 
insn has the TF set, and the tap is fired. But the EIP is the one 
following the trapped insn.



- Davide

Re: ptrace in 2.6.5

[Fabiano Ramos]

On Mon, 2004-05-10 at 19:58, Daniel Jacobowitz wrote:
> On Tue, May 11, 2004 at 07:47:08AM +0900, OGAWA Hirofumi wrote:
> > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> writes:
> > 
> > > So single-step exception happen *after* executed the "mov ...".
> > > Probably you need to use the breakpoint instead of single-step.
> > 
> > Ah, sorry. Just use PTRACE_SYSCALL instead of PTRACE_SINGLESTEP.
> > It's will stop before/after does syscall.
> 
> Doing it this way is pretty lousy - you have to inspect the code after
> every step to see if it's an int $0x80.  Is there some reason not to
> report a trap on the syscall return path if single-stepping?

Strange thing. When entering a syscall, the int 0x80 does clear the
trap, but first it is saved into the stack. When the iret is executed,
the eflags is restored from the stack, thus single stepping is
re-enabled.

The question is: the int 0x80 can be seen as complex instructions that
is only completed after the iret. This way, I do not see why a debug
trap is not generated afer the int 0x80 and BEFORE the mov.

I reinvented the wheel and built a module that did the same thing as
a singlestep ptrace, and a the trap WAS generated after the int 0x80
completed, before the mov. 

So I think it has sth to do with the debug trap handler. 

I DO NOT BELIEVE THIS BEAVIOUR is right, since if it is not stopping
after the int 0x80, ptrace is not TRULLY singlestepping.

Re: ptrace in 2.6.5

[Davide Libenzi]

On Mon, 10 May 2004, Fabiano Ramos wrote:

> The question is: the int 0x80 can be seen as complex instructions that
> is only completed after the iret. This way, I do not see why a debug
> trap is not generated afer the int 0x80 and BEFORE the mov.
> 
> I reinvented the wheel and built a module that did the same thing as
> a singlestep ptrace, and a the trap WAS generated after the int 0x80
> completed, before the mov. 
> 
> So I think it has sth to do with the debug trap handler. 
> 
> I DO NOT BELIEVE THIS BEAVIOUR is right, since if it is not stopping
> after the int 0x80, ptrace is not TRULLY singlestepping.

If you look at the Intel manual 24319202 page 44 (TF bit), it clearly says 
that the trap is generated on the instruction that follows the IRET. In 
the same doc, at page 145, it also says that the return address seen by 
the trap handler is the one following the trapped instructuion (INT#1 is a 
trap). Ideally, I'm with you in expecting a full trace on all the 
instructions (out of INTs), but this doesn't seem to be what documented.
On the kernel side, this would be pretty much solved by issuing a ptrace 
op, with a modified EIP (+2) on return from a syscall (if in single-step 
mode).



- Davide

Re: ptrace in 2.6.5

[Davide Libenzi]

On Mon, 10 May 2004, Davide Libenzi wrote:

> On the kernel side, this would be pretty much solved by issuing a ptrace 
> op, with a modified EIP (+2) on return from a syscall (if in single-step 
> mode).

Actaully, the EIP should not be changed (since it already points to the 
intruction following INT 0x80) and I believe it is sufficent to replace 
the test for _TIF_SYSCALL_TRACE with (_TIF_SYSCALL_TRACE | TIF_SINGLESTEP) 
in the system call return path. This should generate a ptrace trap with 
EIP pointing to the next instruction following INT 0x80.



- Davide

Re: ptrace in 2.6.5

[Davide Libenzi]

On Mon, 10 May 2004, Davide Libenzi wrote:

> On Mon, 10 May 2004, Davide Libenzi wrote:
> 
> > On the kernel side, this would be pretty much solved by issuing a ptrace 
> > op, with a modified EIP (+2) on return from a syscall (if in single-step 
> > mode).
> 
> Actaully, the EIP should not be changed (since it already points to the 
> intruction following INT 0x80) and I believe it is sufficent to replace 
> the test for _TIF_SYSCALL_TRACE with (_TIF_SYSCALL_TRACE | TIF_SINGLESTEP) 
> in the system call return path. This should generate a ptrace trap with 
> EIP pointing to the next instruction following INT 0x80.

The patch below (for i386) should work.



- Davide




Index: arch/i386/kernel/entry.S
===================================================================
RCS file: /usr/src/bkcvs/linux-2.5/arch/i386/kernel/entry.S,v
retrieving revision 1.83
diff -u -r1.83 entry.S
--- arch/i386/kernel/entry.S	12 Apr 2004 20:29:12 -0000	1.83
+++ arch/i386/kernel/entry.S	11 May 2004 06:35:29 -0000
@@ -354,7 +354,7 @@
 	# perform syscall exit tracing
 	ALIGN
 syscall_exit_work:
-	testb $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT), %cl
+	testb $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP), %cl
 	jz work_pending
 	sti				# could let do_syscall_trace() call
 					# schedule() instead
Index: include/asm-i386/thread_info.h
===================================================================
RCS file: /usr/src/bkcvs/linux-2.5/include/asm-i386/thread_info.h,v
retrieving revision 1.19
diff -u -r1.19 thread_info.h
--- include/asm-i386/thread_info.h	12 Apr 2004 20:29:12 -0000	1.19
+++ include/asm-i386/thread_info.h	11 May 2004 06:34:47 -0000
@@ -165,7 +165,7 @@
 
 /* work to do on interrupt/exception return */
 #define _TIF_WORK_MASK \
-  (0x0000FFFF & ~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT))
+  (0x0000FFFF & ~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SINGLESTEP))
 #define _TIF_ALLWORK_MASK	0x0000FFFF	/* work to do on any return to u-space */
 
 /*

Re: ptrace in 2.6.5

[Daniel Jacobowitz]

On Mon, May 10, 2004 at 11:41:53PM -0700, Davide Libenzi wrote:
> On Mon, 10 May 2004, Davide Libenzi wrote:
> 
> > On Mon, 10 May 2004, Davide Libenzi wrote:
> > 
> > > On the kernel side, this would be pretty much solved by issuing a ptrace 
> > > op, with a modified EIP (+2) on return from a syscall (if in single-step 
> > > mode).
> > 
> > Actaully, the EIP should not be changed (since it already points to the 
> > intruction following INT 0x80) and I believe it is sufficent to replace 
> > the test for _TIF_SYSCALL_TRACE with (_TIF_SYSCALL_TRACE | TIF_SINGLESTEP) 
> > in the system call return path. This should generate a ptrace trap with 
> > EIP pointing to the next instruction following INT 0x80.
> 
> The patch below (for i386) should work.

Yeah, that's what I was suggesting.  I think the patch is right.

-- 
Daniel Jacobowitz

ptrace in 2.6.5

[Fabiano Ramos]

Hi All.

     Is ptrace(), in singlestep mode, required to stop after a int 0x80?
    When tracing a sequence like

	mov ...
	int 0x80
	mov ....

    ptrace would notify the tracer after the two movs, but not after the
int 0x80. I want to know if it is a bug or the expected behaviour.

TIA,
Fabiano

Re: ptrace in 2.6.5

[Daniel Jacobowitz]

On Mon, May 10, 2004 at 12:46:19PM -0300, Fabiano Ramos wrote:
> Hi All.
> 
>      Is ptrace(), in singlestep mode, required to stop after a int 0x80?
>     When tracing a sequence like
> 
> 	mov ...
> 	int 0x80
> 	mov ....
> 
>     ptrace would notify the tracer after the two movs, but not after the
> int 0x80. I want to know if it is a bug or the expected behaviour.

I think it's a bug.

-- 
Daniel Jacobowitz

Re: ptrace in 2.6.5

[Fabiano Ramos]

On Mon, 2004-05-10 at 13:10, Daniel Jacobowitz wrote:
> On Mon, May 10, 2004 at 12:46:19PM -0300, Fabiano Ramos wrote:
> > Hi All.
> > 
> >      Is ptrace(), in singlestep mode, required to stop after a int 0x80?
> >     When tracing a sequence like
> > 
> > 	mov ...
> > 	int 0x80
> > 	mov ....
> > 
> >     ptrace would notify the tracer after the two movs, but not after the
> > int 0x80. I want to know if it is a bug or the expected behaviour.
> 
> I think it's a bug.

When tracing the following code,

0x0804869f:  8B 4D 0C                     mov   ecx, [ebp+12]
0x080486a2:  CD 80                        int   0x80
0x080486a4:  89 45 F8                     mov   [ebp-8], eax
0x080486a7:  83 7D F8 82                  cmp   [ebp-8], -126


the tracer would produce

EIP: 0x080486a2
EIP: 0x080486a7


--- tracer.c ----
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <signal.h>
#include <syscall.h>
#include <sys/ptrace.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <linux/user.h>
#include <unistd.h>
#include <errno.h>
 
 
extern char **environ;
 
int main(int argc, char **argv)
{
 
        struct user_regs_struct regs;
 
        int wait_val;           /*  child's return value        */
        int pid;                /*  child's process id          */
                                                                                 
        switch (pid = fork()) {
                                                                                                                        
        case -1:
                perror("fork");
                break;
                                                                                                                        
        case 0: /*  child process starts        */
                ptrace(PTRACE_TRACEME, 0, NULL, NULL);
                execv(argv[1],&argv[1]);
                                                                                                                     
        default:/*  parent process starts       */
                waitpid(pid,&wait_val,0);

		ptrace(PTRACE_SINGLESTEP,pid,NULL,NULL);                                                                                                                                        		waitpid(pid,&wait_val,0);                                                                                                                        
                while (1) {
                                                                                                                                               			/* get EIP */
	                ptrace(PTRACE_GETREGS, pid, 0, (int)&regs);
                        printf("\n0x%08lx", regs.eip);
                                                                                                                        			ptrace(PTRACE_SINGLESTEP, pid, 0, 0);
                         
                        wait(&wait_val);
                        if ( WIFEXITED(wait_val)) break;
                                                                                                                        
                }
                                                                                                                        
        }
}