From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114974 invoked by alias); 4 Sep 2019 20:21:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114963 invoked by uid 89); 4 Sep 2019 20:21:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Sep 2019 20:21:35 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7FA101DA2; Wed, 4 Sep 2019 20:21:33 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 507761F2; Wed, 4 Sep 2019 20:21:33 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Eli Zaretskii , Ruslan Kabatsayev Subject: Re: [PATCH v2] Improve ptrace-error detection on Linux targets References: <20190819032918.3536-1-sergiodj@redhat.com> <20190826183205.19008-1-sergiodj@redhat.com> <28c4f743-91f1-59c3-83ff-3f791811f996@redhat.com> <87mufrai1z.fsf@redhat.com> <87zhjjrh7n.fsf@redhat.com> Date: Wed, 04 Sep 2019 20:21:00 -0000 In-Reply-To: (Pedro Alves's message of "Wed, 4 Sep 2019 20:58:01 +0100") Message-ID: <87d0gfrewj.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00040.txt.bz2 On Wednesday, September 04 2019, Pedro Alves wrote: > On 9/4/19 8:31 PM, Sergio Durigan Junior wrote: >> I forgot to say, but the way my patch works now prevents the code path >> above to be executed. My patch catches the ptrace failure very early in >> gdbserver initialization the process, when linux_child_function is >> called during the execution of linux_check_ptrace_features. Since >> linux_child_function will try to perform a PTRACE_TRACEME (and fail if >> there are any restrictions in place), gdbserver will error out before it >> even tries to spawn/attach. >> >> Nevertheless, during my tests I bypassed linux_check_ptrace_features and >> confirmed that the error message from linux_attach (above) is correctly >> displayed: >> >> [sergio@fedora-rawhide build]$ sleep 120 & >> [5] 2732388 >> [sergio@fedora-rawhide build]$ ./gdb/gdbserver/gdbserver :9911 --attach 2732388 >> gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted >> gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED! >> gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2732391 No such process >> Cannot attach to process 2732388: >> >> The SELinux 'deny_ptrace' option is enabled and preventing GDB >> from using 'ptrace'. You can disable it by executing (as root): >> >> setsebool deny_ptrace off >> >> The Linux kernel's Yama ptrace scope is in effect, which can prevent >> GDB from using 'ptrace'. You can disable it by executing (as root): >> >> echo 0 > /proc/sys/kernel/yama/ptrace_scope >> >> Exiting > > So if you _don't_ hack linux_check_ptrace_features, what does the user > see, with either > > gdbserver [OPTIONS] --attach COMM PID Basically the same thing: [sergio@fedora-rawhide build]$ ./gdb/gdbserver/gdbserver :9911 --attach 2733600 gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED! gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2733602 No such process gdbserver: Could not trace the inferior process. gdbserver: ptrace: Operation not permitted The SELinux 'deny_ptrace' option is enabled and preventing GDB from using 'ptrace'. You can disable it by executing (as root): setsebool deny_ptrace off The Linux kernel's Yama ptrace scope is in effect, which can prevent GDB from using 'ptrace'. You can disable it by executing (as root): echo 0 > /proc/sys/kernel/yama/ptrace_scope linux_check_ptrace_features: waitpid: unexpected status 32512. Exiting The only difference is that we don't see the "Cannot attach to process PID:" message. > or extended-remote + "(gdb) attach" ? I'm trying to come up with a way to test this. The only way would be to make gdbserver successfully start so that we could perform an extended-remote connection from GDB. However, if gdbserver starts without problems, this means that the ptrace check succeeded and that there are no ptrace restrictions in place. Therefore, an "attach" would succeed as well. Which means that even if we're running GDB in a ptrace-restricted system, things will go OK as long as gdbserver is not restricted. In this case, we wouldn't see any error messages IIUC. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/