Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937921AbdLRSQN (ORCPT ); Mon, 18 Dec 2017 13:16:13 -0500 Received: from mail-it0-f42.google.com ([209.85.214.42]:41050 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S937438AbdLRSQG (ORCPT ); Mon, 18 Dec 2017 13:16:06 -0500 X-Google-Smtp-Source: ACJfBouaDbDQ7U8At7c/4nTTL90kUCdtlNB8F3AkYVgbMTFb/uLyU+3tNAluTiwm7I4X44ikPzltGVwT/uhzuxYvu+I= MIME-Version: 1.0 In-Reply-To: <20171218125940.117d7696@gandalf.local.home> References: <20171218153225.12192-1-tmricht@linux.vnet.ibm.com> <20171218125940.117d7696@gandalf.local.home> From: Linus Torvalds Date: Mon, 18 Dec 2017 10:16:04 -0800 X-Google-Sender-Auth: uRE79KXzF-GjEKm98n_r8Rfdi40 Message-ID: Subject: Re: [PATCH] trace/uprobes: fix output issue with address randomization To: Steven Rostedt Cc: Thomas Richter , Linux Kernel Mailing List , Ingo Molnar , Heiko Carstens , Martin Schwidefsky , Hendrik Brueckner , "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 Content-Length: 2162 Lines: 49 On Mon, Dec 18, 2017 at 9:59 AM, Steven Rostedt wrote: > > Hmm, since the scrambling of %p is to prevent kernel addresses from > leaking, I wonder if it would be OK to make it only scramble the address > if the address is a kernel address. It should be fine to print user > space addresses unscrambled. Shouldn't it? So %p itself shouldn't have logic like that, because some of those addresses can be sensitive even if they aren't strictly kernel addresses. For example, anything that prints out sensitive physical addresses wouldn't look like a kernel virtual address, but it could still expose very sensitive data. So that check would have to be done by the user of %p, not by %p itself. So generally, the fix for "oops %p hashing now breaks xyz" should generally be to make sure that the protections are correct, and then it can be turned into %px (when it can't just be removed). In this particular case, we already have the magical case of "don't print (null)", and I think _that_ the case that could be just extended to say "don't print sensitive data" and then the %p can be changed into a %px. So one approach would be to simply checking (at _open_ time, not at IO time! That was one of the things that I absolutely detested about %pK - getting that fundamentally wrong) whether the opener could write a kernel address to the file, and if the opener has those permissions, then it obviously can read the values too. But in this case I would suggest just making "uprobe_events" be 0600 rather than 0644. Why the hell should a normal user be able to read whatever events that root has set? Same goes for "uprobe_profile". Is it really sensible that anybody can read that file? It sounds insane to me. Why should a random regular user be able to see what probes are installed? Honestly, very few of the "let's just change %p to %px" has been correct. There is pretty much _always_ some permission problem or other that says "hell no, that data should not have been so widely available before". The only time a pure %p -> %px is warranted is likely for oops reports etc. We did have a couple of those. Linus