Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp120289ybf; Fri, 28 Feb 2020 23:27:52 -0800 (PST) X-Google-Smtp-Source: APXvYqwI6YCsP0geCvbN1pGTy4v3SWwaZbc2yRsmvPWYrOP4tItyjbCQzDSVmnL6U7OraFD6rrq/ X-Received: by 2002:a9d:5e18:: with SMTP id d24mr6392802oti.155.1582961272558; Fri, 28 Feb 2020 23:27:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582961272; cv=none; d=google.com; s=arc-20160816; b=y/8EhMkkgfqObdMGwK+HZ/5pCCkxJib/2oNlnr2NVBzBpI8CsbUODGYtcOVNgu2UaW CEa9QU3cZN5xAc5qlbLf2fqW11QFP8zkbgRH66wlq5bm5XKxgZMPpFIeAcg/6xnwiQaD ESIU1B2MqmHpuhp00zRMCiNRoCMZLhBjEqf3KCAiaM3ffpNa+B/KWWKonAWNcr2Zz2JL 7QABvvEcJ1GVSD9iFK5O8oPVQ91EgSTnKpViWbYD/VM92gilEBMnotWGa6UWzBbFWAtu Ylfd39KTj1NkOtknOtnSOBNzZoww3EFKTZpKAYrVRNAAsXfJCWByPk7dwf5WW5nTg+aS nqyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=vIuMTBg/2s7VTcpd2z8v6Jg9QfTCGOK5ac2MIO2J01c=; b=vcuZKzjQVGjdb9l7Dl5jLvKxtrnUTol5AXYZ6V7IMWFRMwBnt2aGDzBJxJNPrxAjpe AVOHbqcpCQC9v2/tpzY3IsPn/80Uv1i0WhLy5PdpF2z47Lq/mYAyYWEcf4+T0hzMd5uY P7fwiBc0jmbn4GOjjzFx+eHB/XR2Wrmy7SDvF4t3EFy8x8ZKtM6LclaxXKd01WjPAtzg IplCNHIsPaDHxGmpdNvygc3T44ouyFYlM3ZtrKEFa70ggjNnevr9PNhswR5BboXpomlC sPUIzmcli0MPkQNcXA0wJMpgEFzZFNRw2bcjKplXsQxMBWluuzZd2tNUkPQw+azr8fqR BCqA== 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 9si3136983oiq.104.2020.02.28.23.27.39; Fri, 28 Feb 2020 23:27: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 S1726695AbgB2H13 (ORCPT + 99 others); Sat, 29 Feb 2020 02:27:29 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:33292 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725747AbgB2H13 (ORCPT ); Sat, 29 Feb 2020 02:27:29 -0500 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B1E09537301830FD26E2; Sat, 29 Feb 2020 15:27:24 +0800 (CST) Received: from [127.0.0.1] (10.173.221.195) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.439.0; Sat, 29 Feb 2020 15:27:15 +0800 Subject: Re: [PATCH v3 0/6] implement KASLR for powerpc/fsl_booke/64 To: Scott Wood , Daniel Axtens , , , , , , , , , CC: , References: <20200206025825.22934-1-yanaijie@huawei.com> <87tv3drf79.fsf@dja-thinkpad.axtens.net> <8171d326-5138-4f5c-cff6-ad3ee606f0c2@huawei.com> <4c0e7fec63dbc7b91fa6c24692c73c256c131f51.camel@buserror.net> From: Jason Yan Message-ID: <188971ed-f1c4-39b3-c07e-89cc593d88d7@huawei.com> Date: Sat, 29 Feb 2020 15:27:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <4c0e7fec63dbc7b91fa6c24692c73c256c131f51.camel@buserror.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.173.221.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/2/29 12:28, Scott Wood 写道: > On Fri, 2020-02-28 at 14:47 +0800, Jason Yan wrote: >> >> 在 2020/2/28 13:53, Scott Wood 写道: >>> On Wed, 2020-02-26 at 16:18 +0800, Jason Yan wrote: >>>> Hi Daniel, >>>> >>>> 在 2020/2/26 15:16, Daniel Axtens 写道: >>>>> Maybe replacing the REG format string in KASLR mode would be >>>>> sufficient? >>>>> >>>> >>>> Most archs have removed the address printing when dumping stack. Do we >>>> really have to print this? >>>> >>>> If we have to do this, maybe we can use "%pK" so that they will be >>>> hidden from unprivileged users. >>> >>> I've found the addresses to be useful, especially if I had a way to dump >>> the >>> stack data itself. Wouldn't the register dump also be likely to give away >>> the >>> addresses? >> >> If we have to print the address, then kptr_restrict and dmesg_restrict >> must be set properly so that unprivileged users cannot see them. > > And how does that work with crash dumps that could be from any context? > > dmesg_restrict is irrelevant as it just controls who can see the dmesg, not > what goes into it. kptr_restrict=1 will only get the value if you're not in > any sort of IRQ, *and* if the crashing context happened to have CAP_SYSLOG. > No other value of kptr_restrict will ever get you the raw value. > >>> >>> I don't see any debug setting for %pK (or %p) to always print the actual >>> address (closest is kptr_restrict=1 but that only works in certain >>> contexts)... from looking at the code it seems it hashes even if kaslr is >>> entirely disabled? Or am I missing something? >>> >> >> Yes, %pK (or %p) always hashes whether kaslr is disabled or not. So if >> we want the real value of the address, we cannot use it. But if you only >> want to distinguish if two pointers are the same, it's ok. > > Am I the only one that finds this a bit crazy? If you want to lock a system > down then fine, but why wage war on debugging even when there's no > randomization going on? Comparing two pointers for equality is not always > adequate. > AFAIK, %p hashing is only exist because of many legacy address printings and force who really want the raw values to switch to %px or even %lx. It's not the opposite of debugging. Raw address printing is not forbidden, only people need to estimate the risk of adrdress leaks. Turnning to %p may not be a good idea in this situation. So for the REG logs printed when dumping stack, we can disable it when KASLR is open. For the REG logs in other places like show_regs(), only privileged can trigger it, and they are not combind with a symbol, so I think it's ok to keep them. diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index fad50db9dcf2..659c51f0739a 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -2068,7 +2068,10 @@ void show_stack(struct task_struct *tsk, unsigned long *stack) newsp = stack[0]; ip = stack[STACK_FRAME_LR_SAVE]; if (!firstframe || ip != lr) { - printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip); + if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) + printk("%pS", (void *)ip); + else + printk("["REG"] ["REG"] %pS", sp, ip, (void *)ip); #ifdef CONFIG_FUNCTION_GRAPH_TRACER ret_addr = ftrace_graph_ret_addr(current, &ftrace_idx, ip, stack); Thanks, Jason > -Scott > > > > . >