Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp7115740ybf; Fri, 6 Mar 2020 10:39:52 -0800 (PST) X-Google-Smtp-Source: ADFU+vvTe8UE7BvD9RugZRojZSmSl/XcPyCYmBx4yrOG1iKyv2r+NLLdTXxAbMVxSFoT3fLjAG6+ X-Received: by 2002:a05:6830:1b68:: with SMTP id d8mr3602691ote.56.1583519992506; Fri, 06 Mar 2020 10:39:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583519992; cv=none; d=google.com; s=arc-20160816; b=TzxLBPOKK3pvKSh7RjfP97xwLZi9W28Gv/F0Ia0Px/Jp1lRUMLTkRaf0vu+CNaEsPM W8iqISQmcGp4cT6aE5p/SpiVv+gEX/hINoW8WOFH4m/FvEtUZWSZc3Z7NB6sZdx3R4rr sDLAAgXv0W6maok5LaxcLh503qplgmomb7nUNwGdGSHy/6ol+a2MrRU/pCosIh5B/VY6 nn/mN/NX4jcelYfal8G6RaPvIyobLDfA2leH70HkEAOZHf4DlxJVmUTSaJGWAz9xmHdL kTkmyqyjOm/Gj9Ps/k/ukmGrF5IytCQVCd+5tjLqSzWGSlIrebALaHx89APecPUtl2jc WQ7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :mime-version:organization:references:in-reply-to:date:cc:to:from :message-id; bh=MhXWtibkqCyhtT4F1+OfQoqsZqOpTINx6hj17YrJ0cM=; b=Vw2AjghigkXQZp0z9NL7P1Orn6OzWUH8351bquW8edB3IYVRUGM7wFKbl+3FZOnj4F ZRj/fgsD8MiGVCMVKAmR7Xn9CuqAzD1cFdvYRlXrFsqNu63ikFzp28gnJXTjLElIfFCV W9yJshFJSvrUf2VqpzY3YiMHyxkEj9hxqYopvMFjCPrYgxk80Z+LMPJ/D2IOnMnqUhiG vaohS/nv4sx1NVXB7p2eKJZcYQ364T/NVtP4uROpTJ8lPHA21I+2BgyV3nbWINvlT4s6 XTlKKlBEnyyjzkBF/+5SqGGZMFxaudrsqMaWNLXe/gC2MHlG6jK1/DJ/f4y2a25RKwVg hyrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w26si1798220otk.156.2020.03.06.10.39.40; Fri, 06 Mar 2020 10:39:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726237AbgCFSi0 (ORCPT + 99 others); Fri, 6 Mar 2020 13:38:26 -0500 Received: from baldur.buserror.net ([165.227.176.147]:38498 "EHLO baldur.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725873AbgCFSi0 (ORCPT ); Fri, 6 Mar 2020 13:38:26 -0500 Received: from [2601:449:8480:af0:12bf:48ff:fe84:c9a0] by baldur.buserror.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jAHn7-0002zj-NU; Fri, 06 Mar 2020 12:33:46 -0600 Message-ID: <78e666fb78604d98252c436e9e3f6a27cff25a9a.camel@buserror.net> From: Scott Wood To: Linus Torvalds Cc: Kees Cook , Jason Yan , Petr Mladek , Steven Rostedt , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , lkml , "Tobin C . Harding" , Daniel Axtens Date: Fri, 06 Mar 2020 12:33:44 -0600 In-Reply-To: References: <20200304124707.22650-1-yanaijie@huawei.com> <202003041022.26AF0178@keescook> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2601:449:8480:af0:12bf:48ff:fe84:c9a0 X-SA-Exim-Rcpt-To: torvalds@linux-foundation.org, keescook@chromium.org, yanaijie@huawei.com, pmladek@suse.com, rostedt@goodmis.org, sergey.senozhatsky@gmail.com, andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org, tobin@kernel.org, dja@axtens.net X-SA-Exim-Mail-From: oss@buserror.net X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on baldur.localdomain X-Spam-Level: X-Spam-Status: No, score=-17.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -15 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -1.5 GREYLIST_ISWHITE The incoming server has been whitelisted for * this recipient and sender Subject: Re: [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64 X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on baldur.buserror.net) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-03-05 at 12:51 -0600, Linus Torvalds wrote: > On Wed, Mar 4, 2020 at 3:16 PM Scott Wood wrote: > > > > The frustration is with the inability to set a flag to say, "I'm debugging > > and > > don't care about leaks... in fact I'd like as much information as possible > > to > > leak to me." > > Well, I definitely don't want to tie it to "I turned off kaslr in > order to help debugging". That just means that now you're debugging a > kernel that is fundamentally different from what people are running. One shouldn't *test* with something different from what people are running but once a problem has been identified I don't see the problem with changing the kernel to make diagnosis easier (assuming the problem is reproduceable). Though I suppose one could just locally apply a "no pointer hashing" patch when debugging... > So I'd much rather have people just set a really magic flag, perhaps > when kgdb is in use or something. > > > In any case, this came up now due to a question about what to use when > > printing crash dumps. PowerPC currently prints stack and return addresses > > with %lx (in addition to %pS in the latter case) and someone proposed > > converting them to %p and/or removing them altogether. > > Please just use '%pS'. > > The symbol and offset is what is useful when users send crash-dumps. > The hex value is entirely pointless with kaslr - which should > basically be the default. > > Note that this isn't about security at that point - crash dumps are > something that shouldn't happen, but if they do happen, we want the > pointers. But the random hex value just isn't _useful_, so it's just > making things less legible. Losing %lx on the return address would be a minor annoyance (harder to verify that you're looking at the right stack frame in a dump, more steps to look up the line number when modules and kaslr aren't involved, etc), but %pS doesn't help with stack addresses themselves -- and yes, digging into the actual stack data (via kdump, external debugger, etc.) is sometimes useful. Maybe condition it on it being an actual crash dump and not some other caller of show_stack()? -Scott