Bug 325451

Summary: ptrace compatibility problem with PTRACE_{PEEK,POKE}USR_AREA
Product: Red Hat Enterprise Linux 5 Reporter: Brad Hinson <bhinson>
Component: kernelAssignee: Roland McGrath <roland>
Status: CLOSED ERRATA QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: high    
Version: 5.1CC: andrew.white, dzickus, jan.kratochvil, jglauber, roland
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: s390x   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0314 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 14:57:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
debuggee.c
none
debugger.c
none
demo1.s
none
Modified demo1.s
none
Modified debugger.c
none
Modified debuggee.c
none
kernel patch, fixes test case none

Description Brad Hinson 2007-10-09 19:27:41 UTC
Description of problem:
In RHEL 5, only the 64-bit s390 kernel is provided (not the 31-bit), but
the 31-bit compat libs are provided.  The issue is reproduced by building the
attached files with:

gcc -m31 -g -o debuggee debuggee.c demo1.s
gcc -m31 -g -o debugger debugger.c

Using ptrace() to debug a target process. On the s390 we use some 'undocumented'
calls into ptrace. These calls are, ptrace(PTRACE_PEEKUSR_AREA...) and
ptrace(PTRACE_POKEUSR_AREA...).  The calls should read/write a structure filled
with register values that represent a snapshot of the target process. This was
working fine on RHEL 4, but on RHEL5 31bit, it fails with an EIO failure.  I've
attached a small demo of the problem. './debugger' will run the demo. If you
convert the demo for 64bit instead of 31bit then it works as expected.

I expect to see :
process stopped
read PC = 0x004004bc
wrote PC = 0x004004c0
We're back!

But on RHEL5 I get :
process stopped
PTRACE_PEEKUSR_AREA, failed
 : Input/output error
read PC = (nil)
PTRACE_PEEKUSR_AREA, failed
 : Input/output error
wrote PC = 0x00000004
We're back!

I thought the way that the ptrace(PTRACE_PEEKUSR_AREA...) call worked
was, you pass an offset of the first register to read, and a size
indicating the amount of registers to read, (such that the size value
could be any multiple of the register size), and your buffer would be
filled with register values from the indicated offset up to the size
allowed in pt_area->len. If that was the case then you could read one
register by passing an offset and a size of one register. Is this idea
correct?

------------

On RHEL 4, glibc-kernheaders provides 31-bit and 64-bit versions of ptrace.h:

# rpm -ql glibc-kernheaders | grep ptrace.h

/usr/include/asm-s390/ptrace.h
/usr/include/asm-s390x/ptrace.h
/usr/include/asm/ptrace.h
/usr/include/linux/ptrace.h

# cat /usr/include/asm/ptrace.h 

#ifndef __ASM_STUB_PTRACE_H__
# define __ASM_STUB_PTRACE_H__
# if defined __s390__ && !defined __s390x__
#  include <asm-s390/ptrace.h>
# endif
# if defined __s390x__
#  include <asm-s390x/ptrace.h>
# endif
#endif

but on RHEL 5, there's only one version:

# rpm -ql kernel-headers | grep ptrace.h

/usr/include/asm/ptrace.h
/usr/include/linux/ptrace.h

Would providing the 31-bit version of ptrace.h fix this, or is the error
related to using ptrace(PTRACE_PEEKUSR_AREA...)?

Version-Release number of selected component (if applicable):
kernel-2.6.18-52.el5

How reproducible:
100%

Steps to Reproduce:
1. gcc -m31 -g -o debuggee debuggee.c demo1.s
2. gcc -m31 -g -o debugger debugger.c
3. ./debugger

Comment 1 Brad Hinson 2007-10-09 19:28:34 UTC
Created attachment 221671 [details]
debuggee.c

Comment 2 Brad Hinson 2007-10-09 19:28:50 UTC
Created attachment 221681 [details]
debugger.c

Comment 3 Brad Hinson 2007-10-09 19:29:13 UTC
Created attachment 221691 [details]
demo1.s

Comment 4 Brad Hinson 2007-10-16 15:43:32 UTC
Modified demo follows.  From email:

I've modified the demo slightly. I've decided to only read the first 34
available registers from the register structure. You can see that some registers
can't be read/written. However, the interesting part is that writing the PC
value is accepted without error, but when we read it back we can see it's
incorrect. Is this a different problem to the original?

Comment 5 Brad Hinson 2007-10-16 15:44:55 UTC
Created attachment 228891 [details]
Modified demo1.s

Comment 6 Brad Hinson 2007-10-16 15:45:20 UTC
Created attachment 228901 [details]
Modified debugger.c

Comment 7 Brad Hinson 2007-10-16 15:45:45 UTC
Created attachment 228911 [details]
Modified debuggee.c

Comment 8 Roland McGrath 2007-10-16 21:34:13 UTC
Please show the results of the new test program.

Comment 9 Brad Hinson 2007-10-22 19:54:03 UTC
# /tmp/bld
# /tmp/debugger 
process stopped
read PC = 0x4c5c08e0
Failed to write register MASK
Failed to write register ACR9
wrote PC = 0x4c5c08e4
read PC = 0x4c5c08e4
read PC = 0x4c5c08e6

Comment 14 RHEL Program Management 2007-11-07 03:55:41 UTC
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

Comment 16 Roland McGrath 2007-11-07 23:59:36 UTC
Created attachment 251071 [details]
kernel patch, fixes test case

Comment 17 RHEL Program Management 2007-11-08 00:15:15 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 19 Don Zickus 2007-12-14 18:41:42 UTC
in 2.6.18-60.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Comment 22 errata-xmlrpc 2008-05-21 14:57:52 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0314.html