Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 230850

Summary: /proc/PID/mem is not readable
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: elfutilsAssignee: Roland McGrath <roland>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: cagney, drepper
Target Milestone: ---Keywords: Patch, Reopened
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-06 23:25:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 229424    
Attachments:
Description Flags
Kernel testcase for read(2)/mmap(2)/trace(2) `/proc/%d/mem' readers.
none
elfutils-0.126 workaround using PTRACE_PEEKTEXT instead of `/proc/%d/mem'.
none
test case
none
Patch on-demand PTRACE_ATTACHING the inferior for /proc/PID/mem read(2). none

Description Jan Kratochvil 2007-03-03 18:25:43 UTC
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 18:39:53 UTC
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 18:43:24 UTC
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 08:16:06 UTC
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 08:26:55 UTC
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 16:27:06 UTC
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 23:25:08 UTC
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.
     */