Good News:All of these patches have been merged into the kernel as of 2.4.0-test10!
As of Linux 2.3.99-pre1, SUBTERFUGUE can be run without this patch; the --waitchannelhack flag must be used in this case. The patch below is still recommended, though; as SUBTERFUGUE will run slower without it.
- patch for kernel 2.4.0-test9 [Not needed for 2.4.0-test10 and later.]
- patch for kernel 2.3.99-pre1 [These patches require SUBTERFUGUE 0.1.2 or later, and include only chunks for the first change below (the other changes are merged into 2.3.99-pre1). These patches are backward compatible with existing versions of strace--the strace patch below isn't required (and won't work) with these patch.]
For kernels prior to 2.3.99-pre1, a patch is required in order to run SUBTERFUGUE. The required features have been slowly merged into the 2.3 series (as the progression of patches shows). The 2.3.39 patch should work down to at least 2.3.35, and might even work on 2.2.x with some effort.
Note: The previous version of these patches had a small bug which broke strace. The fix is to change "if (!(current->ptrace & PT_PTRACED))" to "if (!(p->ptrace & PT_PTRACED))" in fork.c.
- patch for kernel 2.3.39
- patch for kernel 2.3.42
- patch for kernel 2.3.48 [The last two chunks listed below were merged into 2.3.48 (!), so this patch is shorter.]
- patch for kernel 2.3.51 [This patch requires SUBTERFUGUE 0.1.2 or later, and includes only chunks for the first two items (GETPPID is no longer needed). This patch is backward compatible with existing versions of strace--the strace patch below isn't required (and won't work) with this patch.]
Changes Included in the Patch
Here are the changes included in the patch. Most are fairly innocuous extensions, but the first two might break some things.
- The exit_code reported during PTRACE_SYSCALL stops now has its high bit (0x80) set, to distinguish it from signal stops. In the new patches, this is done in a backward-compatible way. In the older patches, this breaks strace, and probably any other program that uses PTRACE_SYSCALL (see ptrace(2)). The fix is pretty simple--just mask off the high bit (or adapt the program to make use of the extra information). A patch is available that does this for strace. (It doesn't appear that gdb is affected.) (Update: Merged in 2.4.0-test10.)
- When a new child is created (i.e., with clone, fork, or vfork), and the child is being traced (e.g., it's done a PTRACE_TRACEME), it will now report to the correct parent. Without this patch, for most cases, the wrong parent is being reported to. This patch is correct, but it opens up what some would consider a security hole--a malicious child might unexpectedly invoke PTRACE_TRACEME, causing it to report to a waiting parent process that never expected to hear from it. This was discussed on linux-kernel for a bit; there didn't seem to be a consensus about whether this was even a hole at all. (Update: Merged in 2.3.99-pre1.)
- A new ptrace command PTRACE_GETPPID is implemented, which lets a tracing process discover the original parent of a traced child. This information is otherwise unavailable. (Update: As of about 2.3.51, this info will be available in /proc.)
- A new wait flag __WALL is implemented, to allow clone and non-clone children to be waited for simultaneously. (Update: Merged in 2.3.48.)
- Exits of the system calls fork, vfork, and clone are now reported. (Update: Merged in 2.3.48.)