From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753802AbdLMSVb (ORCPT ); Wed, 13 Dec 2017 13:21:31 -0500 Received: from mail-ot0-f176.google.com ([74.125.82.176]:41344 "EHLO mail-ot0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753694AbdLMSV2 (ORCPT ); Wed, 13 Dec 2017 13:21:28 -0500 X-Google-Smtp-Source: ACJfBosupoNbdhg0USdx7oxFYiBsXGV1ri6a6LvLNahyaSIgZw0S0lEvX/0sbhtAMt+F4DgKpUvFjYMsViNgBDVAL3Y= MIME-Version: 1.0 In-Reply-To: <87r2ryaim5.fsf@concordia.ellerman.id.au> References: <20171201200819.GA25519@linux.vnet.ibm.com> <1512158945-27269-2-git-send-email-paulmck@linux.vnet.ibm.com> <20171204134203.GR7829@linux.vnet.ibm.com> <20171204161100.GT7829@linux.vnet.ibm.com> <87wp1sa55h.fsf@concordia.ellerman.id.au> <87r2ryaim5.fsf@concordia.ellerman.id.au> From: Linus Torvalds Date: Wed, 13 Dec 2017 10:21:27 -0800 X-Google-Sender-Auth: hBYIb7SdICKNdYz1NGs4u_Ul3zM Message-ID: Subject: Re: Long live %pK (was Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK) To: Michael Ellerman Cc: Andy Shevchenko , Kees Cook , "Paul E. McKenney" , David Laight , "linux-kernel@vger.kernel.org" , "mingo@kernel.org" , "jiangshanlai@gmail.com" , "dipankar@in.ibm.com" , "akpm@linux-foundation.org" , "mathieu.desnoyers@efficios.com" , "josh@joshtriplett.org" , "tglx@linutronix.de" , "peterz@infradead.org" , "rostedt@goodmis.org" , "dhowells@redhat.com" , "edumazet@google.com" , "fweisbec@gmail.com" , "oleg@redhat.com" , "kernel-hardening@lists.openwall.com" , "Tobin C. Harding" 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, Dec 13, 2017 at 4:59 AM, Michael Ellerman wrote: > > Right. My email was only about the kptr_restrict = 1 case, but I didn't > actually make that clear. > > But that's also sort of my point, it has multiple modes of operation, > which is useful. No it isn't. It's completely useless. Let me count the ways: - it ties a lot of completely unrelated things together in illogical ways. What if you want vmallocinfo for debuggability, but not something else? - we've had it for most of a decade, and few people use it, and it's not actually fixed any real security holes. It has only helped on particular setups, not in general. > OK, that's the piece I was missing - ie. what to do in the case where > %px for all users is too permissive but %p is not useful. Right. THAT IS THE WHOLE POINT OF THE NEW %p BEHAVIOR. Make people actually _think_ about the things they see, and hopefully just remove it entirely. Not the total idiocy that was %pK that never resulted in any actual improvement anywhere. %pK was the "sprinkle some crack on him, let's get out of here" approach to security. It's bogus shit. Don't do it. Seriously. It's been sprinkled around randomly just to make random people feel like they did something. IT DID NOTHING. The 'K' literally stands for "krack". Because spelling wasn't the strong part of the thing either. > I'm still a bit confused by the above. Because kallsyms which is your > example of how to do it right, still uses kptr_restrict. I get that it > also checks kallsyms_for_perf(), but that's only in the > kptr_restrict = 0 case. Yeah, it was probably a mistake, but I didn't want to change the old behavior. > Anyway, I'll do a patch for vmallocinfo to do the CAP_SYSLOG check at > open time, and use that to decide if it should print 0 or the address. .. don't use CAP_SYSLOG, at least without thihnking about it. That was just another mistake of mine in thinking that "let's keep the old behavior" is a good idea. Seriously, what does CAP_SYSLOG have to do with kernel address debugging? Nothing, really. I suspect CAP_SYS_ADMIN is a much saner thing to use. Ask yourself: who really should get access to vmalloc addresses? Linus