Red Hat Bugzilla – Bug 230850
/proc/PID/mem is not readable
Last modified: 2007-11-30 17:11:58 EST
Description of problem:
eu-addr2line(1) does not resolve functions from VDSO
Version-Release number of selected component (if applicable):
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")
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.
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.
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.
Created attachment 149248 [details]
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.
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
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.
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
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
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.