Bug 230850 - /proc/PID/mem is not readable
/proc/PID/mem is not readable
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: elfutils (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Roland McGrath
: Patch, Reopened
Depends On:
Blocks: 229424
  Show dependency treegraph
 
Reported: 2007-03-03 13:25 EST by Jan Kratochvil
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-06 18:25:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Kernel testcase for read(2)/mmap(2)/trace(2) `/proc/%d/mem' readers. (1.65 KB, application/octet-stream)
2007-03-03 13:39 EST, Jan Kratochvil
no flags Details
elfutils-0.126 workaround using PTRACE_PEEKTEXT instead of `/proc/%d/mem'. (2.96 KB, patch)
2007-03-03 13:43 EST, Jan Kratochvil
no flags Details | Diff
test case (2.28 KB, text/plain)
2007-03-05 03:16 EST, Roland McGrath
no flags Details
Patch on-demand PTRACE_ATTACHING the inferior for /proc/PID/mem read(2). (1.90 KB, patch)
2007-03-06 11:27 EST, Jan Kratochvil
no flags Details | Diff

  None (edit)
Description Jan Kratochvil 2007-03-03 13:25:43 EST
Description of problem:
eu-addr2line(1) does not resolve functions from VDSO

Version-Release number of selected component (if applicable):
kernel-xen-2.6.19-1.2898.2.3.fc7.i686
elfutils-0.126-1.i386

How reproducible:
Always.

Steps to Reproduce:
1. sleep 1h & pid=$!
2. grep -w vdso /proc/$pid/maps
3. eu-addr2line -f -p $pid $(ai "Address off VDSO + 0x420 where
__kernel_sigreturn() is located")

Actual results:
??
??:0

Expected results:
__kernel_sigreturn
??:0

Additional info:
This is definitely a kernel Bug and this one should be reassigned to kernel.
But elfutils has code to read VDSO by pread64(2) and I believe it should have
been working somewhere when you released elfutils this way.  I failed to find a
single i686 kernel version/variant (incl. upstream versions) supporting reading
from `/proc/%d/mem' by read(2).
Therefore I cannot call it a kernel Regression.
Comment 1 Jan Kratochvil 2007-03-03 13:39:53 EST
Created attachment 149185 [details]
Kernel testcase for read(2)/mmap(2)/trace(2) `/proc/%d/mem' readers.

Testcase using read(2) or mmap(2) or ptrace(2) to read VDSO contents.
On local kernel-xen-2.6.19-1.2898.2.3.fc7.i686 only ptrace(2) works.

Probably to be submitted to RHTS later.
Comment 2 Jan Kratochvil 2007-03-03 13:43:24 EST
Created attachment 149186 [details]
elfutils-0.126 workaround using PTRACE_PEEKTEXT instead of `/proc/%d/mem'.

Here is a workaround for elfutils-0.126 that uses PTRACE_PEEKTEXT instead of
the original `/proc/%d/mem' pread64(2)ing code.
It somehow handles ptrace(2) recursivity for processes already being ptrace(2)d
from the current caller's process.
Comment 3 Roland McGrath 2007-03-05 03:16:06 EST
Created attachment 149248 [details]
test case

Run the attached test case with no args to duplicate -p PID behavior as seen
from eu-addr2line et al, and with argument "ptrace" to demonstrate how it works
when called from the thread that is ptrace'ing the target PID.
Comment 4 Roland McGrath 2007-03-05 03:26:55 EST
Try also e.g. "sh -c 'exec eu-addr2line -f -p $$ 0x40000420'".

It is intended behavior in the upstream kernel and this is unchanged in Fedora
kernels, that /proc/PID/mem reads are allowed only by that thread itself or by
the thread that is ptrace'ing it.  It was not always this way, but some
"security" decision was made to disallow reads even by a thread that would be
allowed to attach ptrace, if it is not actually doing ptrace at the time (so gdb
can read).

The libdwfl code that the -p option gets to, especially the vdso-grokking stuff,
was not really intended necessarily to work standalone as it is entirely.  It's
more of an example of how things all plug together in the library support and
what code you'd reuse in a more complex caller integrated with actual debugging
stuff.  In the fullness of time, there will be clean things to plug into instead
of ptrace and /proc grovelling, and then -p PID support can use those and the
vdso support will fall into place.
Comment 5 Jan Kratochvil 2007-03-06 11:27:06 EST
Created attachment 149350 [details]
Patch on-demand PTRACE_ATTACHING the inferior for /proc/PID/mem read(2).

As there is needed some workaround of the current state proposing it for
elfutils.  Otherwise the same code should be present in all the applications
using it.
Your testcase from Comment 3 would be fine to also include for elfutils
together with this patch (it would run without the "ptrace" argument and it
should work).
Comment 6 Jan Kratochvil 2007-03-06 18:25:08 EST
According to Roland this case never occurs as the only tool exhibiting it is
`eu-addr2line -p ...'.
Included a note in libunwind (Bug 229424):
  /* FIXME: Here we would fail for a process not being ourselves and not being
     PTRACE_ATTACHed for unwinding of VDSO symbols (such as sigreturn function
     from a signal handler on the 32-bit x86 platform).
     Fails read_proc_memory() with ESRCH on pread64() there.
     As this case probably never occurs with libunwind we do not workaround it.
     */

Note You need to log in before you can comment on or make changes to this bug.