On Sun, Oct 16, 2011 at 07:57:57PM +0300, Mikolaj Golub wrote: > Hi, > > I have a patch that makes kvm_uread() read from user space using ptrace(2). > > http://people.freebsd.org/~trociny/kvm_uread.ptrace.patch > > With this change 'ps -e' does not requires procfs(5). > > Do you like it or there might be some reasons why it is a bad idea? > > Grepping sources it looks like currently only ps uses kvm_getenvv(3) (and thus > kvm_uread()). > > Note, when reading from its own user space it just does bcopy(3), so if a > wrong address range is passed to kvm_uread() the program will segfault. Do we > need some protection here and what? Masking SIGSEGV? Ptracing a random process may have a disastrous consequences for the traced process, caller or system.
For the process, the ptrace(2) can cause spurious signal delivery or EINTR returns. If the process you attached to is critical for the system operation, you can get hung or failed system. In my opinion, the way to implement the feature is to (re)use linprocfs_doargv() and provide another kern.proc sysctl to retrieve the argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as procfs and linprocfs inside the kernel. While you are at the code, it would be useful to also export the auxv vector, which is immediately before env.
pgpn6KWHsiqIL.pgp
Description: PGP signature
