Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp577269imm; Fri, 28 Sep 2018 03:27:53 -0700 (PDT) X-Google-Smtp-Source: ACcGV60IoZzpLR+p5mYVUlScmx2lCzyUhLp6JcEsf0GXLf0/YU451BatNST4LoLTRG+s+R2b1rJW X-Received: by 2002:a17:902:9b84:: with SMTP id y4-v6mr2035674plp.332.1538130473169; Fri, 28 Sep 2018 03:27:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538130473; cv=none; d=google.com; s=arc-20160816; b=rePHt+mBPIldVOljkBt6QLg8eGlRJtBwfPiVyog7LyVOuQBW9o7FTX/N5poUdChZ6a yWWGPy/P4ldU4xz8hohFrrQtcd3E4sk6LAtXiDwZM/pG01T3XO50qCbHvLL63QQmPxN+ SdLs7DovPh29ePuqmCaCPqjlv3FlDQDrC7b8qQm4hWECZDFskTX3YPyGPtbyNSh82sYa JhrpZswYoCcFn3j0FZszm0Mdcju+1dyuvIxOd1aTUZ3A8y2AYrbc4MS5Zn84IE6jRRr4 jOZvOOdZ4pX1JyMZ52srbmzNiWWPp0vdjtV/8dWplN8L+9feCKqU8Cdy/mIfbNzLwVxm MXMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=TraNDyrwGmL+JJrCUuh97lAwPT6BqbOWPWolvpwu+Cg=; b=c54Y5lCW5sbhyYWTVED/pcOX5T4H7Xh0bnHIMA6Z/hbnTuBj4bcYYj4hGwpaYENLmS Xm4yGjHZuy3M8Uj05dL/LH7wO/g1NWZiHJoMY1jQN2zXBzBkqZZ6z8IZXDxY+8qpyDqy 4X9KFqp5j91JaCwYWG3DI8+vqXxirRHK2jPvLbGundZuDmh5kGvUkx8jzufEZbW6Uzla UaS7Qk4aP8YEwGASN3CP3v2uats+d0W+4QTfJGIqX79E5FCNiI16f5lu7QtzP4CGeVko GJdUjJ0OXxjRd241DqU3KYlRmNBHYotMQKmWjB2mJxEKu0VM1nfJHhcL9BxPORZM0n0t KiKw== 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 m10-v6si4410255pgb.101.2018.09.28.03.27.36; Fri, 28 Sep 2018 03:27:53 -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 S1729306AbeI1QuD (ORCPT + 99 others); Fri, 28 Sep 2018 12:50:03 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:54196 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729116AbeI1QuD (ORCPT ); Fri, 28 Sep 2018 12:50:03 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g5pz2-0005eY-Ti; Fri, 28 Sep 2018 12:26:53 +0200 Date: Fri, 28 Sep 2018 12:26:52 +0200 (CEST) From: Thomas Gleixner To: Tvrtko Ursulin cc: LKML , tvrtko.ursulin@linux.intel.com, Peter Zijlstra , x86@kernel.org, "H. Peter Anvin" , Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Madhavan Srinivasan , Andi Kleen , Alexey Budankov , Kees Cook , Jann Horn Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting) In-Reply-To: <20180919122751.12439-1-tvrtko.ursulin@linux.intel.com> Message-ID: References: <20180919122751.12439-1-tvrtko.ursulin@linux.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tvrtko, On Wed, 19 Sep 2018, Tvrtko Ursulin wrote: It would be very helpful if you cc all involved people on the cover letter instead of just cc'ing your own pile of email addresses. CC'ed now. > For situations where sysadmins might want to allow different level of > access control for different PMUs, we start creating per-PMU > perf_event_paranoid controls in sysfs. > > These work in equivalent fashion as the existing perf_event_paranoid > sysctl, which now becomes the parent control for each PMU. > > On PMU registration the global/parent value will be inherited by each PMU, > as it will be propagated to all registered PMUs when the sysctl is > updated. > > At any later point individual PMU access controls, located in > /device//perf_event_paranoid, can be adjusted to achieve > fine grained access control. > > Discussion from previous posting: > https://lkml.org/lkml/2018/5/21/156 This is really not helpful. The cover letter and the change logs should contain a summary of that discussion and a proper justification of the proposed change. Just saying 'sysadmins might want to allow' is not useful at all, it's yet another 'I want a pony' thing. I read through the previous thread and there was a clear request to involve security people into this. Especially those who are deeply involved with hardware side channels. I don't see anyone Cc'ed on the whole series. For the record, I'm not buying the handwavy 'more noise' argument at all. It wants a proper analysis and we need to come up with criteria which PMUs can be exposed at all. All of this want's a proper documentation clearly explaining the risks and scope of these knobs per PMU. Just throwing magic knobs at sysadmins and then saying 'its their problem to figure it out' is not acceptable. Thanks, tglx