From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755218AbcHZD3W (ORCPT ); Thu, 25 Aug 2016 23:29:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35942 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751569AbcHZD3U (ORCPT ); Thu, 25 Aug 2016 23:29:20 -0400 Date: Thu, 25 Aug 2016 22:19:04 -0500 From: Josh Poimboeuf To: Linus Torvalds Cc: Frederic Weisbecker , Thomas Gleixner , Kees Cook , "H . Peter Anvin" , Nilay Vaish , the arch/x86 maintainers , Steven Rostedt , Andy Lutomirski , Ingo Molnar , Linux Kernel Mailing List , Brian Gerst , Byungchul Park , Peter Zijlstra Subject: Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful Message-ID: <20160826031904.ldqgc6bg4g6is4un@treble> References: <9fbe0db05bacf66d337c162edbf61450d0cff1e2.1472057064.git.jpoimboe@redhat.com> <20160824182220.GB10153@twins.programming.kicks-ass.net> <20160824193707.qw7vii3l4ggcfl6d@treble> <20160825174904.vfam55lpo7geczqf@treble> <20160825210716.e3p42qm5k4yd3cqb@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.28]); Fri, 26 Aug 2016 03:19:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2016 at 02:23:35PM -0700, Linus Torvalds wrote: > On Aug 25, 2016 2:08 PM, "Josh Poimboeuf" wrote: > > > > Ah, the plot thickens. I didn't know about 'dmesg_restrict'. So I > > guess we don't have to restrict the stack dump addresses after all, > > since the entire dmesg buffer is protected by syslog()? > > No. > > Guys, the whole dmesg_restrict thing is a joke. You can't restrict access > to system messages in general. It's just a stupid idea. > > So stop thinking like some theoretical security people - we have more than > enough of those. Start thinking like *practical* people that actually care > about the user experience, and interfaces, and then within those confined, > think about security. > > Because remember: if you don't get that security comes *second*, you're not > a security person, you're just a joke. People actually *using* the system > come first. So I'm not all that familiar with this pointer restriction stuff. And I don't claim to be a security person. I'm just trying to understand what the real issues are so we can fix them. And anyway I thought this whole discussion was trying to resolve a security concern which you brought up: not leaking kernel addresses to unprivileged user space. > So stop with the idiotic security flags that same people cannot actually > use, either because they restrict use too much, or because they are so > expensive that they aren't practical by default. > > The things is, we should strive to do something *useful*. And > dmesg_restrict is not that. For an oops, there are other opportunities for address leakage besides the stack trace function addresses. There's the raw stack dump which dumps the first 12 stack entries. And there's the register dump. I'm pretty sure we don't want to get rid of those. I suppose we could come up with some innovative way to filter or sanitize kernel addresses from the stack dump and the registers. But that probably hurts usability for kernel developers. Another issue is that there are a lot of duplicate symbol names in the kernel. So the symbol name alone might not be enough to disambiguate the function address. Not to mention the fact that today there are a gazillion uses of printk() with '%p' in the kernel. So yes, dmesg_restrict sounds useful to me. It's a way to prevent users from seeing kernel addresses without affecting my ability to debug issues. For a locked down system, why would non-root users need to access dmesg anyway? > In contrast, striving to just get the symbol names - but not the hex > addresses - is actually both more useful and more secure than what we have > now. How exactly does removing data from the stack dump make it more useful? > And dammit, even addr2line should just be able to understand the "symbol+ > offset" format, so even that is a really bad reason to show the hex number. Maybe addr2line *should* be able to understand "symbol+offset", but it doesn't, so it breaks my workflow. Is there another lightweight tool out there (i.e., not gdb) which does it? I also wonder if other tools might have similar issues. Though I can't think of anything off the top of my head. -- Josh