From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754335AbcIANJ0 (ORCPT ); Thu, 1 Sep 2016 09:09:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751214AbcIANJY (ORCPT ); Thu, 1 Sep 2016 09:09:24 -0400 Date: Thu, 1 Sep 2016 08:09:20 -0500 From: Josh Poimboeuf To: Linus Torvalds Cc: Peter Zijlstra , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , the arch/x86 maintainers , Linux Kernel Mailing List , Andy Lutomirski , Steven Rostedt , Brian Gerst , Kees Cook , Frederic Weisbecker , Byungchul Park , Nilay Vaish Subject: Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful Message-ID: <20160901130920.e7ac4jff6swqqbfc@treble> References: <9fbe0db05bacf66d337c162edbf61450d0cff1e2.1472057064.git.jpoimboe@redhat.com> <20160824182220.GB10153@twins.programming.kicks-ass.net> <20160831165303.tvcudt7wkpechuqt@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 01 Sep 2016 13:09:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 31, 2016 at 10:15:19AM -0700, Linus Torvalds wrote: > So I think the patch is good, and I think the oops looks great, but I > think we should also just remove the stack dump. Sure, the register > state *can* contain these things too, but almost never do (and didn't, > in this example). > > The stack dump actually goes back to forever, and it used to be useful > back in 1992 or so. But it used to be useful mainly because stacks > were simpler and we didn't have very good call traces anyway. I > definitely remember having used them - I just do not remember having > used them in the last ten+ years. > > Of course, it's still true that if you can trigger an oops, you've > likely already lost the security game, but since the stack dump is so > useless, let's aim to just remove it and make games like the above > harder. Yeah. I'll do another patch to get rid of the raw stack dump (though maybe I'll wait until the other patches get merged first so I don't have patches flying around everywhere). > I'm also sure that we probably have a lot of other addresses in dmesg > that we should make sure aren't leaked. I did a quick grep and found > > Base memory trampoline at [ffff8f5e00097000] 97000 size 24576 > percpu: Embedded 35 pages/cpu @ffff8f6236c00000 s103640 r8192 d31528 u262144 > Freeing SMP alternatives memory: 32K (ffffffffaaec1000 - ffffffffaaec9000) > > and a few more, and didn't check if those might give load addresses > away, but it would be good to check. On my system, a grep found these: $ dmesg |grep "ffff[8-e]\|ffffffff[8-e]" [ 0.000000] found SMP MP-table at [mem 0x000f6b40-0x000f6b4f] mapped at [ffffa0b7000f6b40] [ 0.000000] Base memory trampoline at [ffffa0b700099000] 99000 size 24576 [ 0.000000] percpu: Embedded 485 pages/cpu @ffffa0b77d200000 s1946904 r8192 d31464 u2097152 [ 0.475975] Freeing SMP alternatives memory: 32K (ffffffff9e309000 - ffffffff9e311000) [ 2.656380] Freeing initrd memory: 10588K (ffffa0b736b42000 - ffffa0b737599000) [ 4.444099] Freeing unused kernel memory: 3592K (ffffffff9df87000 - ffffffff9e309000) [ 4.447080] Freeing unused kernel memory: 1352K (ffffa0b7288ae000 - ffffa0b728a00000) [ 4.449517] Freeing unused kernel memory: 632K (ffffa0b728d62000 - ffffa0b728e00000) The text starts at 0xffffa0b728000000 and 0xffffffff9d000000. I think only the "Freeing" messages would give away the vmlinux mappings. I'm wonder if it might be useful to encode the addresses somehow; they could conceivably be used to debug use-after-free issues. Or we could just remove them. -- Josh