From patchwork Fri Jul 7 13:53:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Liebler X-Patchwork-Id: 21468 Received: (qmail 60640 invoked by alias); 7 Jul 2017 13:54:02 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 59185 invoked by uid 89); 7 Jul 2017 13:54:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH] S390: Sync ptrace.h with kernel. [BZ #21539] To: libc-alpha@sourceware.org References: <20170613200522.GA14306@altlinux.org> <7ce52670-669c-d9c0-dcf0-4d328bbeda79@linux.vnet.ibm.com> <6d68f86b-321b-12ee-688e-02f7869c2951@redhat.com> From: Stefan Liebler Date: Fri, 7 Jul 2017 15:53:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <6d68f86b-321b-12ee-688e-02f7869c2951@redhat.com> X-TM-AS-GCONF: 00 x-cbid: 17070713-0040-0000-0000-000003BE731D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17070713-0041-0000-0000-000025B8E491 Message-Id: <035660ff-d3ea-e05c-2b38-76a8be225aa3@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070228 On 07/07/2017 12:45 PM, Florian Weimer wrote: > On 07/07/2017 12:22 PM, Stefan Liebler wrote: >> + /* Ptrace request 12 is done with zero data argument: >> + -If the kernel has support for PTRACE_SINGLEBLOCK (then the kernel >> + header asm/ptrace.h defines this macro), the ptrace call is not allowed >> + to fail and has to continue the tracee until next taken branch. >> + >> + -If the kernel (<3.15) has no support for PTRACE_SINGLEBLOCK, the >> + ptrace call has to fail with EIO. Then I continue the tracee with >> + PTRACE_CONT. >> + >> + -If the request 12 is interpreted as PTRACE_GETREGS, it will fail too. >> + It fails with EFAULT on intel / power as data argument is NULL. >> + According to the man-page: "Unfortunately, under Linux, different >> + variations of this fault will return EIO or EFAULT more or less >> + arbitrarily". >> + But if request 12 is interpreted as PTRACE_GETREGS, the first ptrace >> + call will touch the buffer which is detected by this test. */ > > I think the comment is still a bit off. I think it is only necessary to > retain the second two lines, the other things is already implied by the > short comments in the code below. okay. I removed the other lines. > > (I have not tested whether this actually works. I assume you have > checked a couple of userspace/kernel permutations.) Yes. I've run the test on several machines. > > Thanks, > Florian > If this is okay, I'll commit it on Monday. Bye. Stefan commit 5a547ac7caceb9ad2ac4903966b9d5294dfa4f7c Author: Stefan Liebler Date: Fri Jul 7 15:07:42 2017 +0200 S390: Fix tst-ptrace-singleblock if kernel does not support PTRACE_SINGLEBLOCK. The request PTRACE_SINGLEBLOCK was introduced in Linux 3.15. Thus the ptrace call will fail on older kernels. Thus the test is now testing PTRACE_SINGLEBLOCK with data argument pointing to a buffer on stack which is assumed to fail. If the request would be interpreted as PTRACE_GETREGS, then the ptrace call will not fail and the regs are written to buf. If we run with a kernel with support for PTRACE_SINGLEBLOCK a ptrace call with data=NULL, returns zero with no error. If we run with a kernel without support for PTRACE_SINGLEBLOCK a ptrace call with data=NULL reports an error. In the latter case, the test is just continuing with PTRACE_CONT. ChangeLog: * sysdeps/unix/sysv/linux/s390/tst-ptrace-singleblock.c: Support running on kernels without PTRACE_SINGLEBLOCK. diff --git a/sysdeps/unix/sysv/linux/s390/tst-ptrace-singleblock.c b/sysdeps/unix/sysv/linux/s390/tst-ptrace-singleblock.c index 95a2f55..c8eea0a 100644 --- a/sysdeps/unix/sysv/linux/s390/tst-ptrace-singleblock.c +++ b/sysdeps/unix/sysv/linux/s390/tst-ptrace-singleblock.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include /* Ensure that we use the PTRACE_SINGLEBLOCK definition from glibc ptrace.h in tracer_func. We need the kernel ptrace.h for structs ptrace_area @@ -63,6 +65,10 @@ tracer_func (int pid) gregset_t regs2; int status; + int ret; +#define MAX_CHARS_IN_BUF 4096 + char buf[MAX_CHARS_IN_BUF + 1]; + size_t buf_count; while (1) { @@ -104,11 +110,55 @@ tracer_func (int pid) The s390 kernel has no support for PTRACE_GETREGS! Thus glibc ptrace.h is adjusted to match kernel ptrace.h. + The glibc sys/ptrace.h header contains the identifier + PTRACE_SINGLEBLOCK in enum __ptrace_request. In contrast, the kernel + asm/ptrace.h header defines PTRACE_SINGLEBLOCK. + This test ensures, that PTRACE_SINGLEBLOCK defined in glibc works as expected. If the kernel would interpret it as PTRACE_GETREGS, then the tracee will not make any progress - and this testcase will time out. */ - TEST_VERIFY_EXIT (ptrace (req_singleblock, pid, NULL, NULL) == 0); + and this testcase will time out or the ptrace call will fail with + different errors. */ + + /* Ptrace request 12 is first done with data argument pointing to + a buffer: + -If request 12 is interpreted as PTRACE_GETREGS, it will store the regs + to buffer without an error. + + -If request 12 is interpreted as PTRACE_SINGLEBLOCK, it will fail + as data argument is used as signal-number and the address of + buf is no valid signal. + + -If request 12 is not implemented, it will also fail. + + Here the test expects that the buffer is untouched and an error is + returned. */ + memset (buf, 'a', MAX_CHARS_IN_BUF); + ret = ptrace (req_singleblock, pid, NULL, buf); + buf [MAX_CHARS_IN_BUF] = '\0'; + buf_count = strspn (buf, "a"); + TEST_VERIFY_EXIT (buf_count == MAX_CHARS_IN_BUF); + TEST_VERIFY_EXIT (ret == -1); + + /* If request 12 is interpreted as PTRACE_GETREGS, the first ptrace + call will touch the buffer which is detected by this test. */ + errno = 0; + ret = ptrace (req_singleblock, pid, NULL, NULL); + if (ret == 0) + { + /* The kernel has support for PTRACE_SINGLEBLOCK ptrace request. */ + TEST_VERIFY_EXIT (errno == 0); + } + else + { + /* The kernel (< 3.15) has no support for PTRACE_SINGLEBLOCK ptrace + request. */ + TEST_VERIFY_EXIT (errno == EIO); + TEST_VERIFY_EXIT (ret == -1); + + /* Just continue tracee until it exits normally. */ + TEST_VERIFY_EXIT (ptrace (PTRACE_CONT, pid, NULL, NULL) == 0); + } } }