Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1032440imm; Fri, 28 Sep 2018 10:42:32 -0700 (PDT) X-Google-Smtp-Source: ACcGV62VsFQaQF2s7hD0C/I+gJObW2OMtbwfKPLLmHxn97/MwJD+wspaBPS0lZM7IFLnniUd1gI+ X-Received: by 2002:a17:902:ba95:: with SMTP id k21-v6mr17426278pls.38.1538156552614; Fri, 28 Sep 2018 10:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538156552; cv=none; d=google.com; s=arc-20160816; b=Bjg7nwjYLwR+fYo2/1WPFKq/tPub2hfC+tt+eY+3zqLdv7YBho7u0lMBC5HLcvYutJ +dsc8R1jN0Dc6guG4Z9rxgm6H4bnra8nLBBa/fSJ/Biq9f7Ui/xp+KRRwXMb5TnJEOyZ Q74bihA77iXuItqNKQl8ONOI8Cgy/0AoHnG5xCJnXOxC/6koM9X/T/pAkQK48nTGm0u9 RbqKDxzrQZRoKmSGKJ1u81DDgstVyMWvJx3kdG/zmpNpjbX1OTDEwzNUhWsP49J8YRE5 SeOjpBL2hgvBhEb3eokgspASICQ2qj2Gd8NaxbkFnCcv6Z95DaKa4XK83MVg65V9cq+3 XcQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=0mAbl7GzH0TSl591KJuXFNdUXaGoOfFywfRpHkpLItQ=; b=VYbm9LVm4y6a01wlTbz+s/dKxBV+MqrhKNjDlf/ForKncjllv2yB+rkEnZ455qYYfH THnufnBctqk4urunvlxjRdyxVAO7E7BGQekUPDUJSfkyofo+drbYquBMl/BT79Z9M99z UPNIm3TpkyHJfT0QROMGxhsn9YMEjF19RTJn99BVcnkEI2FqZAFhWBtrxp0nXltHuAfg K1JWlmw6xuwtaByWKc+w0lY6/Cub+F8DoLfmcwCcEHX8Z2pRxKBk5vio1vVtbe6uHgNb vVKqfWIx6xN0erHNfJjXf6eWGBUoxMXXBrShoZ87wqdBgJUyCGpwdFR+PwhdOfKujZcu 4dvQ== 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 b6-v6si1575369pgi.255.2018.09.28.10.42.17; Fri, 28 Sep 2018 10:42:32 -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 S1727069AbeI2AFM (ORCPT + 99 others); Fri, 28 Sep 2018 20:05:12 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:54188 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726100AbeI2AFM (ORCPT ); Fri, 28 Sep 2018 20:05:12 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 71AAD18A; Fri, 28 Sep 2018 10:40:22 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AADB63F5BD; Fri, 28 Sep 2018 10:40:19 -0700 (PDT) Date: Fri, 28 Sep 2018 18:40:17 +0100 From: Mark Rutland To: Andi Kleen Cc: Thomas Gleixner , Tvrtko Ursulin , 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 , Alexey Budankov , Kees Cook , Jann Horn Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting) Message-ID: <20180928174016.i7d24puv7y3jwzf6@lakrids.cambridge.arm.com> References: <20180919122751.12439-1-tvrtko.ursulin@linux.intel.com> <20180928164111.i6nba2j6mnegwslw@lakrids.cambridge.arm.com> <20180928172340.GA32651@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180928172340.GA32651@tassilo.jf.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote: > > There's also been prior discussion on these feature in other contexts > > (e.g. android expoits resulting from out-of-tree drivers). It would be > > nice to see those considered. > > > > IIRC The conclusion from prior discussions (e.g. [1]) was that we wanted > > finer granularity of control such that we could limit PMU access to > > specific users -- e.g. disallow arbitrary android apps from poking *any* > > PMU, while allowing some more trusted apps/users to uses *some* specific > > PMUs. > > > > e.g. we could add /sys/bus/event_source/devices/${PMU}/device, protect > > this via the usual fs ACLs, and pass the fd to perf_event_open() > > somehow. A valid fd would act as a capability, taking precedence over > > perf_event_paranoid. > > That sounds like an orthogonal feature. I don't think the original > patchkit would need to be hold up for this. It would be something > in addition. I have to say that I disagree -- these controls will have to interact somehow, and the fewer of them we have, the less complexity we'll have to deal with longer-term. > BTW can't you already do that with the syscall filter? I assume > the Android sandboxes already use that. Just forbid perf_event_open > for the apps. Note that this was about providing access to *some* PMUs in some cases. IIUC, if that can be done today via a syscall filter, the same is true of per-pmu paranoid settings. Thanks, Mark.