Re: Ability to manipulate fork() return values

From: Mike Coleman (mkc@kc.net)
Date: Tue Feb 22 2000 - 01:44:59 EST


I need this too, for SUBTERFUGUE, as well as the other patchlet that you
(Pavel) just posted (waiting for clone and non-clone children simultaneously).

There are also three other patchlets that I believe are necessary if you want
to do really solid tracing (including clone). The particulars are available
at http://subterfugue.org/patches.html , but here is a brief rundown:

- Change do_fork so that clone children created with CLONE_PARENT are
  reparented correctly. This is just the logical thing--the current behavior
  is completely useless, as far as I can see. (There is a possible small
  security issue, which could be addressed if needed.)

- Set the high (0x80) bit of exit_code on PTRACE_SYSCALL stops. As far as I
  can tell, without this (or a variation), it's practically impossible to tell
  whether a stop in this case happened due to a syscall exit or a true
  SIGTRAP. (This change breaks existing versions of 'strace', but the fix is
  trivial.)

- Add a new command PTRACE_GETPPID which returns the original parent pid of a
  process. To see why this is needed, imagine that you're tracing a process
  as it goes through a fork. Suppose the child reports (at your wait4) first,
  as it is leaving the fork call. You know the child's pid, but there's no
  way to find out its original ppid. If you're following a set of processes,
  there may be many outstanding fork calls at any point, and when children
  start reporting, you want to be able to line them up with their parents.

  An alternative (and better IMO) solution would be to have the *original*
  ppid reported everywhere (e.g., /proc/n/{stat,status}). The current
  behavior of making ptrace reparenting visible everywhere is arguably the
  wrong thing, as it confuses any processes that are watching.

I'd really like to have these in for 2.4, or hear objections so that I can try
to address them. Any advice at all on how to proceed would be welcome.

--Mike

Pavel Machek <pavel@suse.cz> writes:
> Fork behaves other than normal syscalls -- debugger is not called at
> syscall exit. This patch fixes that. It does touch only return path
> from fork(), which is "cold enough". Ability to change registers after
> fork() is essential if strace wants to work correctly with clone().
>
> [patch is against 42, but I checked it applies to 46]
> Pavel
>
> --- linux-2.3.42/arch/i386/kernel/entry.S.orig Sat Feb 5 02:07:42 2000
> +++ linux-2.3.42/arch/i386/kernel/entry.S Sat Feb 5 02:09:32 2000
> @@ -180,6 +180,8 @@
> call SYMBOL_NAME(schedule_tail)
> addl $4, %esp
> GET_CURRENT(%ebx)
> + testb $0x20,flags(%ebx) # PF_TRACESYS
> + jne tracesys_exit
> jmp ret_from_sys_call
>
> /*

-- 
Any sufficiently adverse technology is indistinguishable from Microsoft.

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



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:29 EST