From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751526AbdJRP3r (ORCPT ); Wed, 18 Oct 2017 11:29:47 -0400 Received: from imap.thunk.org ([74.207.234.97]:33974 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750926AbdJRP3p (ORCPT ); Wed, 18 Oct 2017 11:29:45 -0400 Date: Wed, 18 Oct 2017 11:28:58 -0400 From: "Theodore Ts'o" To: "Tobin C. Harding" Cc: Kees Cook , Steven Rostedt , "kernel-hardening@lists.openwall.com" , Linus Torvalds , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , LKML Subject: Re: [kernel-hardening] Re: [PATCH v2] printk: hash addresses printed with %p Message-ID: <20171018152858.fe6svcxycvzzadpy@thunk.org> Mail-Followup-To: Theodore Ts'o , "Tobin C. Harding" , Kees Cook , Steven Rostedt , "kernel-hardening@lists.openwall.com" , Linus Torvalds , Paolo Bonzini , Tycho Andersen , "Roberts, William C" , Tejun Heo , Jordan Glover , Greg KH , Petr Mladek , Joe Perches , Ian Campbell , Sergey Senozhatsky , Catalin Marinas , Will Deacon , Chris Fries , Dave Weinstein , Daniel Micay , Djalal Harouni , LKML References: <1508215972-7769-1-git-send-email-me@tobin.cc> <20171017093119.6dd98919@gandalf.local.home> <20171017231559.GD8001@eros> <20171018022805.GB30848@eros> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171018022805.GB30848@eros> User-Agent: NeoMutt/20170609 (1.8.3) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2017 at 01:28:05PM +1100, Tobin C. Harding wrote: > > >> Does %p[FfSs] leak addresses? Well, I guess it does if they are not > > >> found in kallsyms, but otherwise you have: > > >> > > >> function+0x > > > > > > > They haven't traditionally been a big deal. If they turn out to be > > problematic, we can deal with it then, IMO. If it's not in kallsyms, the raw address is probably not going to be terribly useful --- so even if it's not traditionally been a big deal, why not just hash them if it's not going to be printed as "function+0x"? If nothing else, it will help correlate the random address with other places where it was printed via %p. - Ted