Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp574052imm; Thu, 26 Jul 2018 08:24:02 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfh5x6EbOU4JQP/0WsqZxxjeEtFJB5elVnbCK7guMi4pBXL+viXBlDjZGoJsrVs9jhFOO4V X-Received: by 2002:a63:5815:: with SMTP id m21-v6mr2365948pgb.78.1532618642377; Thu, 26 Jul 2018 08:24:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532618642; cv=none; d=google.com; s=arc-20160816; b=CF0/z0aUC9RvDwtb1VZKyHbZK6Xxy/ZfSnUUTmplx0jEWUYBsiiLvxbyK4LeA8hkP9 lgUFxqcJeKmuTwxcuDq0j8sB/KFiQfAcYk6Jk3+6kiUG35bPFriPXtMl6mmSM4F4u6+M ocLtHgqBo4mehpYTtUHzIJDBIfq79XTnv0FqPO9/K6MskmApCC7PEsb3KnQ5bCkNz/AL fCcQ+BE5d7JeXq2F3x8xWss8MEvHkNn9uIlyRNE6edz7yoBAtfzF8C0aqPUBZGB5Rb+D 5sVDMjK/kPBAewEVODE9OxbqdlvnlrJDPh7505qWLjxGxLpovd2h1PI6hh4CsHFQmWXI 0WUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Mc8vf2+U8nNPFCFGIIkuO79pquwTI80FzW1H4RU/DS4=; b=nRcUgoyrNmwMtZ+i6UKg48WD3rVW9KNImd11VIbZtJHiPPJUawm3+2ylkX/7CUZw2t 8Z2dSqdSlc/TZkjviCkEdhCV9t6Fh04cm9WXwpbNKSCHLjZZ01Y/XAAk+so60KY5bqk0 AHXTkN8cyXTMjH1OolwX2wZrh5aJS4o3Aed9SjPpNxLdRMpCvGuSzav3Cr2DKsgQQOo1 T7Wpw4EjCEDk9fmnxVYrt2kkGFTsvmwHAM1UAf2jPcWeYVty8Ba+khCqOAbw5A0H13u3 BMYY4o8RKv1gJnmsJI4VOwwyfTqkCxOQMHZ5XI0uPWbhR87BSXPGERdoywsLpJe0PyvU OoeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h3-v6si1406288pld.114.2018.07.26.08.23.45; Thu, 26 Jul 2018 08:24:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731615AbeGZQkH (ORCPT + 99 others); Thu, 26 Jul 2018 12:40:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:34974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729801AbeGZQkH (ORCPT ); Thu, 26 Jul 2018 12:40:07 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B28A920685; Thu, 26 Jul 2018 15:22:46 +0000 (UTC) Date: Thu, 26 Jul 2018 11:22:45 -0400 From: Steven Rostedt To: Mark Salyzyn Cc: linux-kernel@vger.kernel.org, Nick Desaulniers , Ingo Molnar , kernel-team@android.com, stable@vger.kernel.org Subject: Re: [PATCH] tracing: do not leak kernel addresses Message-ID: <20180726112245.3c1bf91d@gandalf.local.home> In-Reply-To: <11437c3e-5131-7190-c496-7b51eb7fcc2a@android.com> References: <20180725202238.165314-1-salyzyn@android.com> <20180725210717.3b807191@vmware.local.home> <11437c3e-5131-7190-c496-7b51eb7fcc2a@android.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 Jul 2018 08:14:08 -0700 Mark Salyzyn wrote: > Thank you Steve, much appreciated feedback, I have asked the security > developers to keep this in mind and come up with a correct fix. > > The correct fix that meets your guidelines would _not_ be suitable for > stable due to the invasiveness it sounds, only for the latest will such > a rework make sense. As such, the fix proposed in this patch is the only > one that meets the bar for stable patch simplicity, and merely(!) needs > to state that if the fix is taken, perf and trace are broken. > > Posting this patch publicly on the lists, that may never be applied, may > be the limit of our responsibility for a fix to stable kernel releases, > to be optionally applied by vendors concerned with this CVE criteria? > The patch breaks the code it touches. It makes it useless. If you want something for stable, add a command line parameter that just disables the creation of that file. Otherwise you will break usespace and that will be a definitely NAK from Linus, and for stable itself. This is a very minor security issue, and does not justify breaking userspace applications. I would be very upset if a new stable release broke both perf and trace-cmd's ability to read certain trace events. -- Steve