From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55683 invoked by alias); 19 Oct 2017 10:48:31 -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 54837 invoked by uid 89); 19 Oct 2017 10:48:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=laptop, commitment, informing, polished 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; Thu, 19 Oct 2017 10:48:20 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E6D9F464E; Thu, 19 Oct 2017 10:48:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E6D9F464E Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 17EAFBBE76; Thu, 19 Oct 2017 10:48:17 +0000 (UTC) Subject: Re: [PATCH 2/2] GDB test suite: Get core files on targets with systemd-coredump To: Andreas Arnez References: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> <1505760152-28775-3-git-send-email-arnez@linux.vnet.ibm.com> <38b0202f-5c78-a8bb-7bc8-e86f3a02ca33@redhat.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <6b3a1715-22ee-2cb0-03be-1d98d2a3a237@redhat.com> Date: Thu, 19 Oct 2017 10:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00599.txt.bz2 On 10/18/2017 04:56 PM, Andreas Arnez wrote: > On Tue, Oct 17 2017, Pedro Alves wrote: > >> On 10/17/2017 06:36 PM, Andreas Arnez wrote: > > [...] > >>> This might be the right trade-off if we expect test cases to be executed >>> only on systems that the user has full control over. But I consider >>> this restriction too tight and would prefer a "best effort" approach >>> instead. Maybe we should emit a warning *and* try our best to execute >>> the test? >> >> Not sure, really. It seems like the "best effort" results in >> racy tests, e.g., if "coredumpctl" returns an old dump, or >> if coredumpctl decides to rate-limit core dump generation (which >> according to the docs, it does). It very much sounds like that >> can lead to hard to diagnose problems and send GDB hackers tilting >> at windmills. > > That might be. However, the same problems may affect *any* coredumpctl > user, not just the GDB test suite. And coredumpctl users are *our* > users, after all. Sure, but we're not interested in testing coredumpctl's ability to copy a core dump out of the log before that file is handed over to gdb? We're testing GDB's ability to load a core dump file that the kernel produced, doesn't matter to us really how many hoops the file went through before it was fed to gdb. I mean, we don't go and run filesystem-level stress-tests because we copy files around in the filesystem -- we just assume the filesystem is bug free, and let filesystem folks worry about such testing. If coredumpctl Just Worked flawlessly for our testsuite's use case (which is not like a regular user's use case), then I'd be all for this. My problem is really that it doesn't really work all that well, and by not informing GDB developers that there's (currently...) a better non-racy way to run make-sure-you-can-load-kernel-core-dumps tests, then we're not doing our follow GDB developers a real service. > Maybe we should postpone GDB test suite support for > systemd-coredump until these problems are fixed. But if all "informed > developers" just give up and disable systemd-coredump, I fear that they > will never be addressed. Judging from our rate of fixes for our own racy-tests, some of which are caused by other-components issues (frequently glibc/kernel), I don't think that exposing us to more sources of races will help with that either. >>> But I'm not so sure about this. IMHO a default mainstream Linux >>> installation should be suited for development- and debugging purposes >>> *without* any tweaking. Also, if there are good reasons for a security >>> measure, we shouldn't rely on disabling it globally. >> >> I think that battle is lost. > > That surely sounds depressing... I guess I'm late to the battlefield > then ;-) My remark may have sounded fatalistic, but in reality nothing is ever settled forever in software land. All it really takes is someone motivated to go and improve things, work with the relevant communities, etc. It's just that it's an uphill battle, where there seems to be a lot more interest/investment in the community to make things secure by default even if it makes it a little more inconvenient for the system component developer. Balancing both a bit better might be possible, but it requires commitment, involvement and a vigilant eye over the whole stack. History is showing that this just won't come "for free" for us, unfortunately. Let's also not forget that the needs of a GDB developer are not the same as the needs of a developer that uses GDB to debug its own programs for a given system. GDB _is_ part of the system, and regression testing it involves stressing other system components in ways that a normal developer normally won't. For example, running the testsuite could in theory well end up producing hundreds of core dumps for a variation of tests in a few seconds. A regular developer doesn't need that. Another example, ideally, we'd have tests that make sure that GDB behaves correctly when Yama rejects an attach, when it rejects spawning a child process, _in addition_ to testing actual run and attach succeeding. So ideally we'd have a way to control the Yama scope at run time without affecting the whole system. But that's something that you can't do unless you're root, and running the testsuite with root permissions is not something that I'd recommend (though maybe we could have an optional "testsuite/gdb.root/" directory with such tests). > >> Mainstream Linux installations are already very much not suited for >> development OOTB. You have to install a bunch of development packages >> that are not installed by default, before you can build anything, >> including compiler, etc. If you can install packages, then you can >> also disable a few features that really are not meant for development >> environments. What we're missing is a simple "one-click button" way >> to adapt an installation / user environment for development. > > Let me just point out that I see a difference between installing > additional packages and disabling security measures. Admins might be > easily convinced to do the former, but there will probably be more push > back on the latter. A "one-click button" would not really help with > that. > > And all this sounds as if developers were no longer seen as a target > group of a Fedora distribution, say. On the other hand -- quote --: > "Fedora Workstation is a polished, easy to use operating system for > laptop and desktop computers, with a complete set of tools for > developers and makers of all kinds." > >> >>> >>> With respect to Yama's ptrace scope, the distributions seem to differ. >>> For instance, Fedora does not activate it by default >>> (https://fedoraproject.org/wiki/Security_Features_Matrix), while Ubuntu >>> does (https://wiki.ubuntu.com/Security/Features). And I wonder whether >>> this feature couldn't be adjusted to be more debug-friendly either. >> >> The whole point of the feature is to prevent debugging, so I don't >> see how, off hand. > > Well, I think the goal is to prevent visibility of sensitive data like > passwords and keys through ptrace -- which is a fair point. But does > this really require disabling ptrace from "non-ancestor" processes > completely? It just seems to me that the collateral damage to debug > capabilities was accepted too easily in this design. > > [...] > > Anyway, regarding GDB test suite support for systemd-coredump, I won't > push too hard. While I have a slight preference towards "best effort", > I understand your concern with possible surprises. So I'm fine with > dropping this patch. (Again, I don't mind this going in if we make it visibly warn/optional.) > Patch #1 in this series might still be useful, so > I'll send an updated version of it. Yes, please. Thanks! -- Pedro Alves