From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Budankov Subject: Re: [PATCH v4 8/9] drivers/perf: open access for CAP_SYS_PERFMON privileged process Date: Sat, 18 Jan 2020 00:33:37 +0300 Message-ID: References: <20200117105153.GB6144@willie-the-truck> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200117105153.GB6144@willie-the-truck> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane-mx.org@lists.infradead.org To: Will Deacon Cc: Mark Rutland , Song Liu , Peter Zijlstra , Benjamin Herrenschmidt , "joonas.lahtinen@linux.intel.com" , Will Deacon , Alexei Starovoitov , Stephane Eranian , "james.bottomley@hansenpartnership.com" , Paul Mackerras , Jiri Olsa , Andi Kleen , Michael Ellerman , Igor Lubashev , James Morris , Alexander Shishkin , Ingo Molnar , oprofile-list@lists.sf.net, Serge Hallyn , Robert Richter , Kees Cook , Jann Horn s List-Id: linux-perf-users.vger.kernel.org On 17.01.2020 13:51, Will Deacon wrote: > On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote: >> >> Open access to monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to the monitoring remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> monitoring is discouraged with respect to CAP_SYS_PERFMON capability. >> >> Signed-off-by: Alexey Budankov >> --- >> drivers/perf/arm_spe_pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 4e4984a55cd1..5dff81bc3324 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event) >> if (!attr->exclude_kernel) >> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT); >> >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN)) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); >> >> return reg; >> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> return -EOPNOTSUPP; >> >> reg = arm_spe_event_to_pmscr(event); >> - if (!capable(CAP_SYS_ADMIN) && >> + if (!perfmon_capable() && >> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) | >> BIT(SYS_PMSCR_EL1_CX_SHIFT) | >> BIT(SYS_PMSCR_EL1_PCT_SHIFT)))) > > Acked-by: Will Deacon > > Worth noting that this allows profiling of *physical* addresses used by > memory access instructions and so probably has some security implications > beyond the usual "but perf is buggy" line of reasoning. Good to know. Thank you! The data on physical addresses used by memory access instructions can already be provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you have mentioned are already in place. I believe providing the data under CAP_PERFMON alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the data for harm and makes the monitoring more secure. ~Alexey [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > Will > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A645C33C9E for ; Fri, 17 Jan 2020 21:42:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C78A22072B for ; Fri, 17 Jan 2020 21:42:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C78A22072B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 47zvgD6b97zDqwl for ; Sat, 18 Jan 2020 08:42:48 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.100; helo=mga07.intel.com; envelope-from=alexey.budankov@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.intel.com Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 47zvdB26ZZzDqwb for ; Sat, 18 Jan 2020 08:41:01 +1100 (AEDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2020 13:33:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,331,1574150400"; d="scan'208";a="249381111" Received: from linux.intel.com ([10.54.29.200]) by fmsmga004.fm.intel.com with ESMTP; 17 Jan 2020 13:33:49 -0800 Received: from [10.252.10.77] (abudanko-mobl.ccr.corp.intel.com [10.252.10.77]) by linux.intel.com (Postfix) with ESMTP id 7E2515803DA; Fri, 17 Jan 2020 13:33:38 -0800 (PST) Subject: Re: [PATCH v4 8/9] drivers/perf: open access for CAP_SYS_PERFMON privileged process To: Will Deacon References: <20200117105153.GB6144@willie-the-truck> From: Alexey Budankov Organization: Intel Corp. Message-ID: Date: Sat, 18 Jan 2020 00:33:37 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200117105153.GB6144@willie-the-truck> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Song Liu , Peter Zijlstra , "joonas.lahtinen@linux.intel.com" , Will Deacon , Alexei Starovoitov , Stephane Eranian , "james.bottomley@hansenpartnership.com" , Paul Mackerras , Jiri Olsa , Andi Kleen , Igor Lubashev , James Morris , Alexander Shishkin , Ingo Molnar , oprofile-list@lists.sf.net, Serge Hallyn , Robert Richter , Kees Cook , Jann Horn , "selinux@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "jani.nikula@linux.intel.com" , Arnaldo Carvalho de Melo , "rodrigo.vivi@intel.com" , Namhyung Kim , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Tvrtko Ursulin , "linux-parisc@vger.kernel.org" , linux-kernel , Lionel Landwerlin , "linux-perf-users@vger.kernel.org" , "linux-security-module@vger.kernel.org" , Casey Schaufler , "bpf@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 17.01.2020 13:51, Will Deacon wrote: > On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote: >> >> Open access to monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to the monitoring remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> monitoring is discouraged with respect to CAP_SYS_PERFMON capability. >> >> Signed-off-by: Alexey Budankov >> --- >> drivers/perf/arm_spe_pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 4e4984a55cd1..5dff81bc3324 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event) >> if (!attr->exclude_kernel) >> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT); >> >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN)) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); >> >> return reg; >> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> return -EOPNOTSUPP; >> >> reg = arm_spe_event_to_pmscr(event); >> - if (!capable(CAP_SYS_ADMIN) && >> + if (!perfmon_capable() && >> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) | >> BIT(SYS_PMSCR_EL1_CX_SHIFT) | >> BIT(SYS_PMSCR_EL1_PCT_SHIFT)))) > > Acked-by: Will Deacon > > Worth noting that this allows profiling of *physical* addresses used by > memory access instructions and so probably has some security implications > beyond the usual "but perf is buggy" line of reasoning. Good to know. Thank you! The data on physical addresses used by memory access instructions can already be provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you have mentioned are already in place. I believe providing the data under CAP_PERFMON alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the data for harm and makes the monitoring more secure. ~Alexey [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > Will > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 589B0C33C9E for ; Fri, 17 Jan 2020 21:36:10 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2B6082072E for ; Fri, 17 Jan 2020 21:36:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YDuT3Upo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B6082072E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jdr1xgVjrJvZAibMhgZXlfkM9A5MkQfssRZb+pIAL8k=; b=YDuT3Upo1F6JmP sQD8gR5kvfpBc6LttwDUR8epWjUlrT+bDz5Li0gwsNPMH0XBPG7futZfRlDGK9fIjslUySSqQ8Nfo zBimMUdkUUYeCJO1FA4waEfNWbc5iSsN6h8PPVjj/kpJJB3ageloKlBDJsKSa0mNKx4LrpL166yAK dAKnR5v+brqrC7j6UIp1G8n2+Fm7zIAwRbHIq6nD9OlSBEOsX8k93+vJbB73i724lKin6dnwwf/vW gn9OI2Ik5JD6LWW7V88w51/jH96EW3qJolhLpp03HkD/5gHuZBJBjH4JB4a0YchbwObt1GPluD79g H5EticwKlPLzIVAvWjcA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1isZHl-0006Ah-Id; Fri, 17 Jan 2020 21:36:09 +0000 Received: from mga09.intel.com ([134.134.136.24]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1isZHi-0006A1-GG for linux-arm-kernel@lists.infradead.org; Fri, 17 Jan 2020 21:36:08 +0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2020 13:33:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,331,1574150400"; d="scan'208";a="249381111" Received: from linux.intel.com ([10.54.29.200]) by fmsmga004.fm.intel.com with ESMTP; 17 Jan 2020 13:33:49 -0800 Received: from [10.252.10.77] (abudanko-mobl.ccr.corp.intel.com [10.252.10.77]) by linux.intel.com (Postfix) with ESMTP id 7E2515803DA; Fri, 17 Jan 2020 13:33:38 -0800 (PST) Subject: Re: [PATCH v4 8/9] drivers/perf: open access for CAP_SYS_PERFMON privileged process To: Will Deacon References: <20200117105153.GB6144@willie-the-truck> From: Alexey Budankov Organization: Intel Corp. Message-ID: Date: Sat, 18 Jan 2020 00:33:37 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200117105153.GB6144@willie-the-truck> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200117_133606_591706_A46951D6 X-CRM114-Status: GOOD ( 18.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Song Liu , Peter Zijlstra , Benjamin Herrenschmidt , "joonas.lahtinen@linux.intel.com" , Will Deacon , Alexei Starovoitov , Stephane Eranian , "james.bottomley@hansenpartnership.com" , Paul Mackerras , Jiri Olsa , Andi Kleen , Michael Ellerman , Igor Lubashev , James Morris , Alexander Shishkin , Ingo Molnar , oprofile-list@lists.sf.net, Serge Hallyn , Robert Richter , Kees Cook , Jann Horn , "selinux@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "jani.nikula@linux.intel.com" , Arnaldo Carvalho de Melo , "rodrigo.vivi@intel.com" , Namhyung Kim , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Tvrtko Ursulin , "linux-parisc@vger.kernel.org" , linux-kernel , Lionel Landwerlin , "linux-perf-users@vger.kernel.org" , "linux-security-module@vger.kernel.org" , Casey Schaufler , "bpf@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 17.01.2020 13:51, Will Deacon wrote: > On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote: >> >> Open access to monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to the monitoring remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> monitoring is discouraged with respect to CAP_SYS_PERFMON capability. >> >> Signed-off-by: Alexey Budankov >> --- >> drivers/perf/arm_spe_pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 4e4984a55cd1..5dff81bc3324 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event) >> if (!attr->exclude_kernel) >> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT); >> >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN)) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); >> >> return reg; >> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> return -EOPNOTSUPP; >> >> reg = arm_spe_event_to_pmscr(event); >> - if (!capable(CAP_SYS_ADMIN) && >> + if (!perfmon_capable() && >> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) | >> BIT(SYS_PMSCR_EL1_CX_SHIFT) | >> BIT(SYS_PMSCR_EL1_PCT_SHIFT)))) > > Acked-by: Will Deacon > > Worth noting that this allows profiling of *physical* addresses used by > memory access instructions and so probably has some security implications > beyond the usual "but perf is buggy" line of reasoning. Good to know. Thank you! The data on physical addresses used by memory access instructions can already be provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you have mentioned are already in place. I believe providing the data under CAP_PERFMON alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the data for harm and makes the monitoring more secure. ~Alexey [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > Will > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9427AC33C9E for ; Fri, 17 Jan 2020 21:33:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6F5AF2072E for ; Fri, 17 Jan 2020 21:33:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F5AF2072E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D1FB789EAC; Fri, 17 Jan 2020 21:33:52 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2426789EAC for ; Fri, 17 Jan 2020 21:33:51 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2020 13:33:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,331,1574150400"; d="scan'208";a="249381111" Received: from linux.intel.com ([10.54.29.200]) by fmsmga004.fm.intel.com with ESMTP; 17 Jan 2020 13:33:49 -0800 Received: from [10.252.10.77] (abudanko-mobl.ccr.corp.intel.com [10.252.10.77]) by linux.intel.com (Postfix) with ESMTP id 7E2515803DA; Fri, 17 Jan 2020 13:33:38 -0800 (PST) To: Will Deacon References: <20200117105153.GB6144@willie-the-truck> From: Alexey Budankov Organization: Intel Corp. Message-ID: Date: Sat, 18 Jan 2020 00:33:37 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200117105153.GB6144@willie-the-truck> Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH v4 8/9] drivers/perf: open access for CAP_SYS_PERFMON privileged process X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Song Liu , Peter Zijlstra , Benjamin Herrenschmidt , Will Deacon , Alexei Starovoitov , Stephane Eranian , "james.bottomley@hansenpartnership.com" , Paul Mackerras , Jiri Olsa , Andi Kleen , Michael Ellerman , Igor Lubashev , James Morris , Alexander Shishkin , Ingo Molnar , oprofile-list@lists.sf.net, Serge Hallyn , Robert Richter , Kees Cook , Jann Horn , "selinux@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, "linux-parisc@vger.kernel.org" , linux-kernel , "linux-perf-users@vger.kernel.org" , "linux-security-module@vger.kernel.org" , Casey Schaufler , "bpf@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 17.01.2020 13:51, Will Deacon wrote: > On Wed, Dec 18, 2019 at 12:30:29PM +0300, Alexey Budankov wrote: >> >> Open access to monitoring for CAP_SYS_PERFMON privileged processes. >> For backward compatibility reasons access to the monitoring remains open >> for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for secure >> monitoring is discouraged with respect to CAP_SYS_PERFMON capability. >> >> Signed-off-by: Alexey Budankov >> --- >> drivers/perf/arm_spe_pmu.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 4e4984a55cd1..5dff81bc3324 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -274,7 +274,7 @@ static u64 arm_spe_event_to_pmscr(struct perf_event *event) >> if (!attr->exclude_kernel) >> reg |= BIT(SYS_PMSCR_EL1_E1SPE_SHIFT); >> >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && capable(CAP_SYS_ADMIN)) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> reg |= BIT(SYS_PMSCR_EL1_CX_SHIFT); >> >> return reg; >> @@ -700,7 +700,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> return -EOPNOTSUPP; >> >> reg = arm_spe_event_to_pmscr(event); >> - if (!capable(CAP_SYS_ADMIN) && >> + if (!perfmon_capable() && >> (reg & (BIT(SYS_PMSCR_EL1_PA_SHIFT) | >> BIT(SYS_PMSCR_EL1_CX_SHIFT) | >> BIT(SYS_PMSCR_EL1_PCT_SHIFT)))) > > Acked-by: Will Deacon > > Worth noting that this allows profiling of *physical* addresses used by > memory access instructions and so probably has some security implications > beyond the usual "but perf is buggy" line of reasoning. Good to know. Thank you! The data on physical addresses used by memory access instructions can already be provided under CAP_SYS_ADMIN privileges [1] thus, I suppose, any implications you have mentioned are already in place. I believe providing the data under CAP_PERFMON alone without the rest of CAP_SYS_ADMIN credentials decreases chances to misuse the data for harm and makes the monitoring more secure. ~Alexey [1] https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html > > Will > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx