Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4912950ybf; Wed, 4 Mar 2020 13:17:58 -0800 (PST) X-Google-Smtp-Source: ADFU+vvFYY2SkYtl2ErB/TWsOJJr3rAxID0iv9ivNemsudF0HblTM0tZWTIGKYMmwosZRJgYHYhx X-Received: by 2002:a05:6830:15d8:: with SMTP id j24mr4068186otr.258.1583356678341; Wed, 04 Mar 2020 13:17:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583356678; cv=none; d=google.com; s=arc-20160816; b=wK9NpKft68be7THWevVIqW74x3NhYSLdYP8CjWA7DMdx/QwrfvO1WFLuMM4VcNRRyK ZZqtZhaTUo+OJZD4R/MnmQ3gjbZ2z2F3P/t8LpoKxDNSN1HM/XdUqDZTAaFIwSwXipPF rmylL67KaIjex5FVfHs61E5xsSEU/Vzqr9tZKYw40oEog2/eN0NQYc+pjEPpMWNzyGnk ZrN1GVtfuIswZpUHg8/CwNXeXI5UTzmYH27oVUR++WmGUXqoqpSNX6yy+6ukTIeByVjx N4x0yMGEyjmt5jIMxb9zIm5H+rIvDUqqhDpuLM4prcJQExqDKAXMcQm7qSV2rXhY4GzO R4TQ== 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=HZOEjIoMYQisrtujPi4lQ2l5KrUJ4NZjSSqZjfSk0Uk=; b=orRX4VZn40/bFR/3BB6esdQECz5hAYO4kvnBv9QbLgY9PSecEo75Qq9ooOOXG3zz4c Zqyd7lZLJpMC6btCUBxJpI5Fhi12kjSVGb4FaiLDBOA6sRvh6MuAB1gUcDNDsZzSUKH6 mnRvGguKjkKrYmiJBny2ZcJ+efSmTIAn8OC81HyOGNnA6U/z3/sz0MeuOS/9GkIbYDj7 wOYDVcceEMaMxp3K5sDCHRYST0XIv+IxcxWtKKEsSfx+Mq0GfHE6BjbmA53SxistiJsb Q/9RkPrIeCNbGuMOsQtvfOuuR1p94EKKBYOGaXoq6YFfTaa/bXRDccNnqCHSjPdDAZQp 8/SA== 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 o20si1967335ota.17.2020.03.04.13.17.46; Wed, 04 Mar 2020 13:17:58 -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 S2388351AbgCDVQJ (ORCPT + 99 others); Wed, 4 Mar 2020 16:16:09 -0500 Received: from baldur.buserror.net ([165.227.176.147]:34298 "EHLO baldur.buserror.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387762AbgCDVQI (ORCPT ); Wed, 4 Mar 2020 16:16:08 -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 1j9bIq-0000R4-KO; Wed, 04 Mar 2020 15:11:40 -0600 Message-ID: From: Scott Wood To: Kees Cook , Jason Yan Cc: pmladek@suse.com, rostedt@goodmis.org, sergey.senozhatsky@gmail.com, andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org, "Tobin C . Harding" , Linus Torvalds , Daniel Axtens Date: Wed, 04 Mar 2020 15:11:39 -0600 In-Reply-To: <202003041022.26AF0178@keescook> 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: 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, torvalds@linux-foundation.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 Wed, 2020-03-04 at 10:34 -0800, Kees Cook wrote: > On Wed, Mar 04, 2020 at 08:47:07PM +0800, Jason Yan wrote: > > When I am implementing KASLR for powerpc, Scott Wood argued that format > > specifier "%p" always hashes the addresses that people do not have a > > choice to shut it down: https://patchwork.kernel.org/cover/11367547/ > > > > It's true that if in a debug environment or security is not concerned, > > such as KASLR is absent or kptr_restrict = 0, there is no way to shut > > the hashing down except changing the code and build the kernel again > > to use a different format specifier like "%px". And when we want to > > turn to security environment, the format specifier has to be changed > > back and rebuild the kernel. > > > > As KASLR is available on most popular platforms and enabled by default, > > print the raw value of address while KASLR is absent and kptr_restrict > > is zero. Those who concerns about security must have KASLR enabled or > > kptr_restrict set properly. > > Sorry, but no: %p censoring is there to stem the flood of endless pointer > leaks into logs, sysfs, proc, etc. These are used for attacks to build > reliable kernel memory targets, regardless of KASLR. (KASLR can be > bypassed with all kinds of sampling methods, side-channels, etc.) > > Linus has rejected past suggestions to provide a flag for it[1], > wanting %p to stay unconditionally censored. 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." Hashed addresses only allow comparison to other hashes which doesn't help when looking at (or trying to find) data structures in kernel memory, etc. I get what Linus is saying about "you can't have nice things because people won't test the normal config" but it's still annoying. :-P 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. Is there a consensus on whether crash dumps need to be sanitized of this stuff as well? It seems like you'd have the addresses in the register dump as well (please don't take that away too...). Maybe crash dumps would be a less problematic place to make the hashing conditional (i.e. less likely to break something in userspace that wasn't expecting a hash)? -Scott