From patchwork Fri Jul 7 10:22:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Liebler X-Patchwork-Id: 785426 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3x3rK31xx1z9s7B for ; Fri, 7 Jul 2017 20:22:47 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="WqycGLOn"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:date :mime-version:in-reply-to:content-type:message-id; q=dns; s= default; b=MMvIV5aMj4uFQAt+SnY25Vguk5JInpCIueidpCb9iTfgFg61Po8/o CYyRQ3uRKXUHOlXZ/Vdmn9eim2DZYSLUmtD1GsCR95UdsncpHEVYz4OhOT8KHptf wIFGxAGFc5VFazdkzwFNHfX1GpsB0KyRIaTrvZsOoOK+H+yrBZzo1A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:cc:from:date :mime-version:in-reply-to:content-type:message-id; s=default; bh=1vh4nUK5wE0r1Sj+tWCsCb4PGCw=; b=WqycGLOng9oyPOd8GrNl2zEtXr66 UaD0OPWkBjsy0xulPfeClq5FLdAoT6SEkYvT05W3lJRWS7OI1Do7808d3cEt9kXM NMKFDb4ozxggZQDI90eedYWtL4HmwpP4nkPDZeH7obbbl/btPPht600DYR9NBhLp wdHMvwokyElHYyc= Received: (qmail 560 invoked by alias); 7 Jul 2017 10:22:39 -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 549 invoked by uid 89); 7 Jul 2017 10:22:38 -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> Cc: Florian Weimer From: Stefan Liebler Date: Fri, 7 Jul 2017 12:22:30 +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: X-TM-AS-GCONF: 00 x-cbid: 17070710-0040-0000-0000-000003BE2AC3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17070710-0041-0000-0000-000025B89B77 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_05:, , 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-1707070169 On 07/04/2017 05:37 PM, Stefan Liebler wrote: > On 07/04/2017 11:41 AM, Florian Weimer wrote: >> On 07/04/2017 10:22 AM, 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. >> >> I think this is still bogus. We can compile with newer kernel headers >> than the host kernel, and this will cause the test to fail. >> >> Thanks, >> Florian >> > > Okay. > So I can check the return value of the second ptrace (req_singleblock, > pid, NULL, NULL) call at runtime to determine the kernel-support: > > 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); > } > > > > Then the test runs on kernels with / without support for > PTRACE_SINGLEBLOCK. The first ptrace call ensures that request 12 is not > interpreted as PTRACE_GETREGS. > > Bye. > Stefan > Here is the complete patch with the change mentioned above. Is this approach okay? Bye. Stefan commit 5319bad7263aa1dc69da37bd4873876189ee5e97 Author: Stefan Liebler Date: Fri Jul 7 10:29:56 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..6e4ba00 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,69 @@ 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); + + /* 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. */ + 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); + } } }