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
| ||
|
Date: Thu, 27 Jul 2006 16:31:28 -0400 From: Daniel Jacobowitz <dan@...ian.org> To: Albert Cahalan <acahalan@...il.com> Cc: torvalds@...l.org, alan@...rguk.ukuu.org.uk, ak@...e.de, mingo@...e.hu, arjan@...radead.org, akpm@...l.org, linux-kernel@...r.kernel.org, roland@...hat.com Subject: Re: ptrace bugs and related problems On Thu, Jul 27, 2006 at 02:55:17AM -0400, Albert Cahalan wrote: > Many of these bugs are generic, some are pure i386, some are for > i386 binaries on the x86-64 kernel, and some apply to a bit more. > Some bugs may involve race conditions: I use a 2-core AMD system. > Kernels vary, but are generally quite recent. (stock 2.6.17.7, > FC5's latest update, etc.) Reporting bugs individually, and with a bit more detail, has the advantage that people can actually keep track of them and recognize them; I highly recommend it. And how are we supposed to answer bugs that apply individually to kernels of unspecified origin? > There is a ptrace option to follow vfork, and an option to get a > message when the parent is released by the child. In kernel/fork.c > there is a bad attempt at optimization which prevents the release > message (PTRACE_EVENT_VFORK_DONE) from being sent unless the ptrace > user also chose the option to follow the vfork child. This doesn't make sense. Example? wait_for_completion(&vfork); if (unlikely (current->ptrace & PT_TRACE_VFORK_DONE)) ptrace_notify ((PTRACE_EVENT_VFORK_DONE << 8) | SIGTRAP); When the parent's vfork is done, the parent's debugger gets a notification. > The debugger has no way to reliably stop a process without causing > confusion. The SIGSTOP signal is not queued. The app under debug might > use SIGSTOP and rely on SIGSTOP to work. The debugger can't steal this. > Any signal that could be queued can also be blocked. The debugger has > no way to get notice when a signal has merely been queued, can not > see into the queue, and can not reasonably adjust the signal mask. See utrace. This problem is roughly not solvable using ptrace. > The PTRACE_EVENT_EXEC messages are just plain unreliable. They don't > always arrive. Things get especially ugly when a non-leader task > does an execve. This is what I meant by vague bug reports. The code for sending this event is quite simple. Things do get ugly when non-leader tasks exec; I don't know whether the forced exits of other threads are clearly visible from the debugger. > A debugger needs to read the vdso page. A debugger might want to use > either /proc/*/mem or PTRACE_PEEK. One of the architectures can't do > both. If I remember right, x86-64 can't PTRACE_PEEK. As far as I know I don't have this problem, on x86_64. > Suppose my debugger has a few threads. PTRACE_ATTACH will not share. > All ptrace calls fail for all threads other than the one that attached. > It really sucks to have to funnel everything through one thread. This is a known limit of ptrace. It's discussed periodically. > BTW, not bugs exactly, but... Getting ptrace events via waitpid is > horrible. Events arrive in some arbitrary order, with no peeking ahead > either within a single target process or even across multiple target > processes. Messages from successful clone/fork/exec may arrive before > or after the child stops, making for some lovely non-deterministic > behavior. Also, it's no fun to mix waitpid with signals or select. > Writing a reliable debugger with ptrace on Linux is absurdly painful. See utrace. -- Daniel Jacobowitz CodeSourcery - 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/
Powered by blists - more mailing lists