From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965233AbcHaRPW (ORCPT ); Wed, 31 Aug 2016 13:15:22 -0400 Received: from mail-oi0-f42.google.com ([209.85.218.42]:36415 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964904AbcHaRPV (ORCPT ); Wed, 31 Aug 2016 13:15:21 -0400 MIME-Version: 1.0 In-Reply-To: <20160831165303.tvcudt7wkpechuqt@treble> References: <9fbe0db05bacf66d337c162edbf61450d0cff1e2.1472057064.git.jpoimboe@redhat.com> <20160824182220.GB10153@twins.programming.kicks-ass.net> <20160831165303.tvcudt7wkpechuqt@treble> From: Linus Torvalds Date: Wed, 31 Aug 2016 10:15:19 -0700 X-Google-Sender-Auth: IuOPE3PAfFgJy9bgCK0VVvMdKZw Message-ID: Subject: Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful To: Josh Poimboeuf 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 31, 2016 at 9:53 AM, Josh Poimboeuf wrote: > > Here's an example of what a stack dump looks like after this change: Looks good, but it also shows: > RSP: 0018:ffffc900008f3a68 EFLAGS: 00010246 Ok, we know the stack pointer now... > RBP: ffffc900008f3a80 R08: 00000002a014a073 R09: ffffc900008f3aa0 .. and it looks like we have a frame pointer too, which is pretty close to the stack pointer. So let's look at the stack dump: > Stack: > ffff880079af7350 ffff880079905400 0000000000000000 ffffc900008f3ae0 > ffffffffa0196610 0000000000000001 00010000ffffffff 0000000087654321 Yeah, counting down, the frame pointer points to the next frame, and right after that you see the return address: 0xffffffffa0196610. So let's look at the call trace: > Call Trace: > __send_control_msg+0x80/0xf0 [virtio_console] Ok, so now we can match up that value to a symbol. And that means that now we can match up *all* symbols in that module. Even if the module isn't readable on that machine, you can just look it up by checking the distro modules on another machine. And if it had been core kernel code, you'd haev had the whole core kernel ofdfsets. 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. 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. Linus