From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Z7+l=DW=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT
	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 56581C433DF
	for <linux-kernel@archiver.kernel.org>; Thu, 15 Oct 2020 12:45:43 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 02B7422258
	for <linux-kernel@archiver.kernel.org>; Thu, 15 Oct 2020 12:45:42 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="nhHpg3LS"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1728274AbgJOMpm (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Thu, 15 Oct 2020 08:45:42 -0400
Received: from z5.mailgun.us ([104.130.96.5]:51558 "EHLO z5.mailgun.us"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1728048AbgJOMpl (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 15 Oct 2020 08:45:41 -0400
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1602765940; h=Content-Transfer-Encoding: MIME-Version:
 Message-Id: Date: Subject: Cc: To: From: Sender;
 bh=tUBuuOkOpn8dlBCi3UTRT7w8MbxjgT0dLTMorbW/WKw=; b=nhHpg3LSppvTn1mnowGlHfWmum1X3cd1ATgYfOeSRSQ1h0epb9yLm3Fq8TJdOityX8Quh/c4
 03xtgFNen2Ug17xh3NbMVfCfGpcSyYCJWdBYCwtjnZUuJ2HgonAWQaOi7+lN0JXxA+o5hQAZ
 WCvgzbEsFUiNVzMWDQnLKdjYrow=
X-Mailgun-Sending-Ip: 104.130.96.5
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n04.prod.us-west-2.postgun.com with SMTP id
 5f88447406d81bc48d36fb6e (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 15 Oct 2020 12:45:40
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 398E5C43391; Thu, 15 Oct 2020 12:45:40 +0000 (UTC)
Received: from blr-ubuntu-253.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19])
        (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id 3C7A6C433FE;
        Thu, 15 Oct 2020 12:45:35 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3C7A6C433FE
Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org
Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=saiprakash.ranjan@codeaurora.org
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>
Cc:     coresight@lists.linaro.org, Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Subject: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing
Date:   Thu, 15 Oct 2020 18:15:22 +0530
Message-Id: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
X-Mailer: git-send-email 2.27.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On production systems with ETMs enabled, it is preferred to
exclude kernel mode(NS EL1) tracing for security concerns and
support only userspace(NS EL0) tracing. So provide an option
via kconfig to exclude kernel mode tracing if it is required.
This config is disabled by default and would not affect the
current configuration which has both kernel and userspace
tracing enabled by default.

Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
 drivers/hwtracing/coresight/Kconfig                | 9 +++++++++
 drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
index c1198245461d..52435de8824c 100644
--- a/drivers/hwtracing/coresight/Kconfig
+++ b/drivers/hwtracing/coresight/Kconfig
@@ -110,6 +110,15 @@ config CORESIGHT_SOURCE_ETM4X
 	  To compile this driver as a module, choose M here: the
 	  module will be called coresight-etm4x.
 
+config CORESIGHT_ETM4X_EXCL_KERN
+	bool "Coresight ETM 4.x exclude kernel mode tracing"
+	depends on CORESIGHT_SOURCE_ETM4X
+	help
+	  This will exclude kernel mode(NS EL1) tracing if enabled. This option
+	  will be useful to provide more flexible options on production systems
+	  where only userspace(NS EL0) tracing might be preferred for security
+	  reasons.
+
 config CORESIGHT_STM
 	tristate "CoreSight System Trace Macrocell driver"
 	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
index abd706b216ac..7e5669e5cd1f 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
@@ -832,6 +832,9 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
 {
 	u64 access_type = 0;
 
+	if (IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
+		config->mode |= ETM_MODE_EXCL_KERN;
+
 	/*
 	 * EXLEVEL_NS, bits[15:12]
 	 * The Exception levels are:
@@ -849,7 +852,8 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
 		access_type = ETM_EXLEVEL_NS_HYP;
 	}
 
-	if (config->mode & ETM_MODE_EXCL_USER)
+	if (config->mode & ETM_MODE_EXCL_USER &&
+	    !IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
 		access_type |= ETM_EXLEVEL_NS_APP;
 
 	return access_type;

base-commit: 3477326277451000bc667dfcc4fd0774c039184c
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Z7+l=DW=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-12.3 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 86E43C43457
	for <linux-kernel@archiver.kernel.org>; Thu, 15 Oct 2020 14:27:57 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 465112225C
	for <linux-kernel@archiver.kernel.org>; Thu, 15 Oct 2020 14:27:56 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2388359AbgJOO1z (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Thu, 15 Oct 2020 10:27:55 -0400
Received: from foss.arm.com ([217.140.110.172]:45326 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1730160AbgJOO1z (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 15 Oct 2020 10:27:55 -0400
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
        by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4DAB113D5;
        Thu, 15 Oct 2020 07:27:54 -0700 (PDT)
Received: from [10.57.50.28] (unknown [10.57.50.28])
        by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BBEFA3F719;
        Thu, 15 Oct 2020 07:27:52 -0700 (PDT)
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
To:     saiprakash.ranjan@codeaurora.org, mathieu.poirier@linaro.org,
        mike.leach@linaro.org, peterz@infradead.org
Cc:     coresight@lists.linaro.org, swboyd@chromium.org,
        denik@chromium.org, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
From:   Suzuki K Poulose <suzuki.poulose@arm.com>
Message-ID: <c02be978-5d78-b88d-ea87-b9958b6e3a05@arm.com>
Date:   Thu, 15 Oct 2020 15:27:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Sai,

On 10/15/2020 01:45 PM, Sai Prakash Ranjan wrote:
> On production systems with ETMs enabled, it is preferred to
> exclude kernel mode(NS EL1) tracing for security concerns and
> support only userspace(NS EL0) tracing. So provide an option
> via kconfig to exclude kernel mode tracing if it is required.
> This config is disabled by default and would not affect the
> current configuration which has both kernel and userspace
> tracing enabled by default.

While this solution works for ETM4x, I would prefer if we did
this in a more generic way. There are other hardware tracing
PMUs that provide instruction tracing (e.g, Intel PT, even ETM3x)
and it would be good to have a single option that works everywhere.

Something like EXCLUDE_KERNEL_HW_ITRACE, which can be honored by
all tracing drivers ?
> 
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
>   drivers/hwtracing/coresight/Kconfig                | 9 +++++++++
>   drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++++-
>   2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index c1198245461d..52435de8824c 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -110,6 +110,15 @@ config CORESIGHT_SOURCE_ETM4X
>   	  To compile this driver as a module, choose M here: the
>   	  module will be called coresight-etm4x.
>   
> +config CORESIGHT_ETM4X_EXCL_KERN
> +	bool "Coresight ETM 4.x exclude kernel mode tracing"
> +	depends on CORESIGHT_SOURCE_ETM4X
> +	help
> +	  This will exclude kernel mode(NS EL1) tracing if enabled. This option
> +	  will be useful to provide more flexible options on production systems
> +	  where only userspace(NS EL0) tracing might be preferred for security
> +	  reasons.
> +
>   config CORESIGHT_STM
>   	tristate "CoreSight System Trace Macrocell driver"
>   	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index abd706b216ac..7e5669e5cd1f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -832,6 +832,9 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
>   {
>   	u64 access_type = 0;
>   
> +	if (IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
> +		config->mode |= ETM_MODE_EXCL_KERN;
> +

Rather than hacking the mode behind the back, could we always make sure that
mode is not set in the first place and return this back to the user with
proper errors (see below) ?

>   	/*
>   	 * EXLEVEL_NS, bits[15:12]
>   	 * The Exception levels are:
> @@ -849,7 +852,8 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
>   		access_type = ETM_EXLEVEL_NS_HYP;
>   	}
>   
> -	if (config->mode & ETM_MODE_EXCL_USER)
> +	if (config->mode & ETM_MODE_EXCL_USER &&
> +	    !IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
>   		access_type |= ETM_EXLEVEL_NS_APP;

Why is this needed ?

Also we should return an error if the sysfs mode ever tries to clear the mode bit
for kernel in config->mode.

Suzuki

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Z7+l=DW=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-9.9 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,
	MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED
	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 F36A0C433E7
	for <linux-kernel@archiver.kernel.org>; Thu, 15 Oct 2020 16:03:05 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 8709422210
	for <linux-kernel@archiver.kernel.org>; Thu, 15 Oct 2020 16:03:05 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="WMP4y67p"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2389487AbgJOQDE (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Thu, 15 Oct 2020 12:03:04 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43534 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2388560AbgJOQDE (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 15 Oct 2020 12:03:04 -0400
Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1099CC061755
        for <linux-kernel@vger.kernel.org>; Thu, 15 Oct 2020 09:03:04 -0700 (PDT)
Received: by mail-pj1-x1043.google.com with SMTP id j8so2341955pjy.5
        for <linux-kernel@vger.kernel.org>; Thu, 15 Oct 2020 09:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=Iv2OYAnv0SA23u+SDCrJEFVeIFrM8td2tmeExloIU5M=;
        b=WMP4y67p7K2jBWI8kiEW/1mYKERGeEA8o4azow+B1ckeg5kmfX0f0KUshy0CIDEzvZ
         ECOITkGCaMHeGCe1f8GRrsbhbRh7kEUWzQYYS2HfyontUnA8rPrUcVddem9BHoofetTR
         JDACBNsZUzKEhdFB28TxjiHCL4s0UfHm2lJi/2zD3rYVujTQVpmh8txHyXUM3L/J6ATh
         ZttJ68BfA/++TMOSM5r6ruoOqSiIF4DgLbuOQjfg1SF1mO87JGQJP2mjPJV57v0bKpoS
         tjeejwK48/Ix3bnLBLsGi04q6grhk850aFoW1h1bIOvdChjissWnNXgzk7Wdq4CpnzHZ
         hMWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=Iv2OYAnv0SA23u+SDCrJEFVeIFrM8td2tmeExloIU5M=;
        b=V/iOuEBLRDx2XqRt0kjIdLzgfKViwt6HDSbn67Kgqf2rFhFCSLYYeMo4vR3h2IhTwY
         u5l1cn4Yuq5Uihp9TrgU3n53lAuD7F83NxhbWHoyxt9dmRxV8UXXK+mWK0CTfaTrf2Tl
         clEgHsQovFjiMq8ZCsziS3OfcaOMOQM9roWEkpG2sS07GMFx4oDyyioLctx8Y6wnS/Um
         S/UMlYGx1TQGbN4wzfZH84g5RfUS5kL2/Sb9og65pFXw0+yO0/xLTJ38vSekWeyVZKnW
         0Lf8WD/URExkv+tVjMuVyQET+Gb+FYTOfeVOIdx4OTtcdjsJBQ7R+1dkori9bQkpkaYp
         dXvg==
X-Gm-Message-State: AOAM533msPkynL7Clf6fCKyNmGCnDovWcMUCUc2dgtMs3uz+0b+MtkVy
        RdWKiCD63FvwKMKH77VSuy8G8Q==
X-Google-Smtp-Source: ABdhPJwfIKbf4iP20eUHbQ17ExMMt9lJlaF7boqyuBwhO2o5YDtjBcdTQ4yl+RKs1Dq25HBcaUH+wQ==
X-Received: by 2002:a17:90a:1702:: with SMTP id z2mr5026194pjd.88.1602777780374;
        Thu, 15 Oct 2020 09:03:00 -0700 (PDT)
Received: from xps15 (S0106002369de4dac.cg.shawcable.net. [68.147.8.254])
        by smtp.gmail.com with ESMTPSA id s186sm3920831pfc.171.2020.10.15.09.02.59
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 15 Oct 2020 09:02:59 -0700 (PDT)
Date:   Thu, 15 Oct 2020 10:02:57 -0600
From:   Mathieu Poirier <mathieu.poirier@linaro.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc:     Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Message-ID: <20201015160257.GA1450102@xps15>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
> On production systems with ETMs enabled, it is preferred to
> exclude kernel mode(NS EL1) tracing for security concerns and
> support only userspace(NS EL0) tracing. So provide an option
> via kconfig to exclude kernel mode tracing if it is required.
> This config is disabled by default and would not affect the
> current configuration which has both kernel and userspace
> tracing enabled by default.
>

One requires root access (or be part of a special trace group) to be able to use
the cs_etm PMU.  With this kind of elevated access restricting tracing at EL1
provides little in terms of security.

Thanks,
Mathieu
 
> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> ---
>  drivers/hwtracing/coresight/Kconfig                | 9 +++++++++
>  drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index c1198245461d..52435de8824c 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -110,6 +110,15 @@ config CORESIGHT_SOURCE_ETM4X
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called coresight-etm4x.
>  
> +config CORESIGHT_ETM4X_EXCL_KERN
> +	bool "Coresight ETM 4.x exclude kernel mode tracing"
> +	depends on CORESIGHT_SOURCE_ETM4X
> +	help
> +	  This will exclude kernel mode(NS EL1) tracing if enabled. This option
> +	  will be useful to provide more flexible options on production systems
> +	  where only userspace(NS EL0) tracing might be preferred for security
> +	  reasons.
> +
>  config CORESIGHT_STM
>  	tristate "CoreSight System Trace Macrocell driver"
>  	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index abd706b216ac..7e5669e5cd1f 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -832,6 +832,9 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
>  {
>  	u64 access_type = 0;
>  
> +	if (IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
> +		config->mode |= ETM_MODE_EXCL_KERN;
> +
>  	/*
>  	 * EXLEVEL_NS, bits[15:12]
>  	 * The Exception levels are:
> @@ -849,7 +852,8 @@ static u64 etm4_get_ns_access_type(struct etmv4_config *config)
>  		access_type = ETM_EXLEVEL_NS_HYP;
>  	}
>  
> -	if (config->mode & ETM_MODE_EXCL_USER)
> +	if (config->mode & ETM_MODE_EXCL_USER &&
> +	    !IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
>  		access_type |= ETM_EXLEVEL_NS_APP;
>  
>  	return access_type;
> 
> base-commit: 3477326277451000bc667dfcc4fd0774c039184c
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-10.3 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	MENTIONS_GIT_HOSTING,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 11617C433E7
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 07:24:10 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 9D7F32073A
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 07:24:09 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="QJSTV0vm"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2404571AbgJPHYI (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 03:24:08 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44656 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2404529AbgJPHYI (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 03:24:08 -0400
Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F74EC061755
        for <linux-kernel@vger.kernel.org>; Fri, 16 Oct 2020 00:24:07 -0700 (PDT)
Received: by mail-pf1-x444.google.com with SMTP id j18so983526pfa.0
        for <linux-kernel@vger.kernel.org>; Fri, 16 Oct 2020 00:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to:user-agent;
        bh=6rJmZWsTC3tZunlzMkeAL6DveINrC2rCniEtmBwJZXY=;
        b=QJSTV0vmxfvJQ+ezN1zSW/4ZDFdXSn2/+t4oCXg78Y1zZrCuNGLvyPvs9iYf5Qvx/i
         XMcFDmFUdD72lSwDB+vrYJlCQ1+m2nqMPTMJtWGnSmHs4kmyOqARDhMCz3LZ7kj0ceyH
         61aR5GkEGi8OxyNjWNiGLyrooObfSzr4GflwEZfLibA1wtZSb/muQx7Ps6I50NdiDTzp
         aUCWio+mlTbSbDIZdjOTg7Qzf6N8CrYvhxJDkn34SvbIAO1CKnlDyCb8dHLwECrp0to7
         Iibo76lGBXZyYe9WQMixuMZo6TqOAqA3+EOlzrPzrcCIEEPmhjUUUS2A9iHctYSmMD7o
         k6tQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to:user-agent;
        bh=6rJmZWsTC3tZunlzMkeAL6DveINrC2rCniEtmBwJZXY=;
        b=ENCXHmciiJVDGfUHlsgRxig3ustb8+NZV8MwATe/rpQ3vwVwNJuBhnk3QDR5ZGOYn3
         HiMJ/m7NsRh/5VGTSX7vDrVm6n9z+3TIeKSvO3TzTzsSVteYuJ374zIkwUzfe9KNkafa
         oOzVXvFdRnJpFCqfZlfZ5NI3D2we0v7aBSglj6pa+E/0eWxAsIjXi1nrcpZTQlnKlfU2
         7ITNMPGHSC+loTb8uc6VT33dgacJc4h+x9txtSS15LCYMTxqvIZ6nCVN4Ra0tq5+FZSn
         JA4Jhw/68wXku/quNjQHLVRZV76lkGh7iRLlzTFEs/OFxwmeOMqd2+cRDkZho5gX6Qvr
         dXew==
X-Gm-Message-State: AOAM5314R2i5PCA/9gP6uTmYKJUtyWFvds6hPVAMVPiEYiQcgb6j/tUZ
        HV+7fPmHNaFDFWvEopfK33SFt1vDmCW+ULHk
X-Google-Smtp-Source: ABdhPJwUWPGICoFq9SFicWYImHXUPoyuhFpWAGUJwIWPJ+ED/XYFz6/H/JF/bR5CuhfixOWgV5UDqw==
X-Received: by 2002:a62:37c4:0:b029:155:ebd8:304c with SMTP id e187-20020a6237c40000b0290155ebd8304cmr2585815pfa.73.1602833046302;
        Fri, 16 Oct 2020 00:24:06 -0700 (PDT)
Received: from leoy-ThinkPad-X240s ([64.120.119.108])
        by smtp.gmail.com with ESMTPSA id c15sm1586586pgg.77.2020.10.16.00.24.03
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Fri, 16 Oct 2020 00:24:05 -0700 (PDT)
Date:   Fri, 16 Oct 2020 15:24:01 +0800
From:   Leo Yan <leo.yan@linaro.org>
To:     Denis Nikitin <denik@chromium.org>
Cc:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Message-ID: <20201016072401.GC4646@leoy-ThinkPad-X240s>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 15, 2020 at 11:40:05PM -0700, Denis Nikitin wrote:
> Hi Mathieu,
> 
> I think one of the use cases could be VMs.
> Is there isolation between EL1 guest kernels which we can control from perf
> in a system wide mode?

Sorry for suddenly jumping in.

For KVM, I think we need to implement mechanism for saving/restoring
CoreSight context for every guest OS, the CPU PMUs has implemented
related features [1].

Thanks,
Leo

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/pmu.c

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-9.7 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BD0F6C43457
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 08:32:20 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 5DDB32084C
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 08:32:20 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="OIsS0nMr"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2394633AbgJPIcT (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 04:32:19 -0400
Received: from z5.mailgun.us ([104.130.96.5]:60353 "EHLO z5.mailgun.us"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2394597AbgJPIcS (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 04:32:18 -0400
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1602837137; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=RmmYpioX2izB6QWy7vq8wVEGZecfk4p8IlN8BmlChlE=;
 b=OIsS0nMrAM2i1geYKv4Pdlzzo6Jg1XDV4fv2NJ6MeCTXAQOIUGkauSkROofB11B7M6VChDwC
 7Z7azQrSsY2v0qjqWc0WDq6PWoQO57+fqXYjjaMtpuXaefXtnhcz9YGH99iF52w35aIcYktX
 GCzrcLVTtt37AG2mLwD5NguHMaA=
X-Mailgun-Sending-Ip: 104.130.96.5
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n01.prod.us-east-1.postgun.com with SMTP id
 5f895a3f588858a304563355 (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 16 Oct 2020 08:30:55
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 732FDC43385; Fri, 16 Oct 2020 08:30:54 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id 770DCC433CB;
        Fri, 16 Oct 2020 08:30:53 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 16 Oct 2020 14:00:53 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Suzuki K Poulose <suzuki.poulose@arm.com>
Cc:     mathieu.poirier@linaro.org, mike.leach@linaro.org,
        peterz@infradead.org, coresight@lists.linaro.org,
        swboyd@chromium.org, denik@chromium.org,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <c02be978-5d78-b88d-ea87-b9958b6e3a05@arm.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <c02be978-5d78-b88d-ea87-b9958b6e3a05@arm.com>
Message-ID: <2b5c14ca55b57430ac1d7aac533d45de@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Suzuki,

On 2020-10-15 19:57, Suzuki K Poulose wrote:
> Hi Sai,
> 
> On 10/15/2020 01:45 PM, Sai Prakash Ranjan wrote:
>> On production systems with ETMs enabled, it is preferred to
>> exclude kernel mode(NS EL1) tracing for security concerns and
>> support only userspace(NS EL0) tracing. So provide an option
>> via kconfig to exclude kernel mode tracing if it is required.
>> This config is disabled by default and would not affect the
>> current configuration which has both kernel and userspace
>> tracing enabled by default.
> 
> While this solution works for ETM4x, I would prefer if we did
> this in a more generic way. There are other hardware tracing
> PMUs that provide instruction tracing (e.g, Intel PT, even ETM3x)
> and it would be good to have a single option that works everywhere.
> 
> Something like EXCLUDE_KERNEL_HW_ITRACE, which can be honored by
> all tracing drivers ?

I can add this for ETM3x as well but I have zero idea regarding
Intel PTs, is there any code in those hwtracing PMUs actually
excluding kernel mode tracing currently?

>> 
>> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
>> ---
>>   drivers/hwtracing/coresight/Kconfig                | 9 +++++++++
>>   drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++++-
>>   2 files changed, 14 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/hwtracing/coresight/Kconfig 
>> b/drivers/hwtracing/coresight/Kconfig
>> index c1198245461d..52435de8824c 100644
>> --- a/drivers/hwtracing/coresight/Kconfig
>> +++ b/drivers/hwtracing/coresight/Kconfig
>> @@ -110,6 +110,15 @@ config CORESIGHT_SOURCE_ETM4X
>>   	  To compile this driver as a module, choose M here: the
>>   	  module will be called coresight-etm4x.
>>   +config CORESIGHT_ETM4X_EXCL_KERN
>> +	bool "Coresight ETM 4.x exclude kernel mode tracing"
>> +	depends on CORESIGHT_SOURCE_ETM4X
>> +	help
>> +	  This will exclude kernel mode(NS EL1) tracing if enabled. This 
>> option
>> +	  will be useful to provide more flexible options on production 
>> systems
>> +	  where only userspace(NS EL0) tracing might be preferred for 
>> security
>> +	  reasons.
>> +
>>   config CORESIGHT_STM
>>   	tristate "CoreSight System Trace Macrocell driver"
>>   	depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) || ARM64
>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c 
>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> index abd706b216ac..7e5669e5cd1f 100644
>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>> @@ -832,6 +832,9 @@ static u64 etm4_get_ns_access_type(struct 
>> etmv4_config *config)
>>   {
>>   	u64 access_type = 0;
>>   +	if (IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
>> +		config->mode |= ETM_MODE_EXCL_KERN;
>> +
> 
> Rather than hacking the mode behind the back, could we always make sure 
> that
> mode is not set in the first place and return this back to the user 
> with
> proper errors (see below) ?
> 

Sure, this was the minimal change with which I could keep the
check in one place which would work for both sysfs and perf,
but I'll change as you suggested and move the check to
etm4_parse_event_config() and etm4_config_trace_mode() and
return errors properly.

>>   	/*
>>   	 * EXLEVEL_NS, bits[15:12]
>>   	 * The Exception levels are:
>> @@ -849,7 +852,8 @@ static u64 etm4_get_ns_access_type(struct 
>> etmv4_config *config)
>>   		access_type = ETM_EXLEVEL_NS_HYP;
>>   	}
>>   -	if (config->mode & ETM_MODE_EXCL_USER)
>> +	if (config->mode & ETM_MODE_EXCL_USER &&
>> +	    !IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
>>   		access_type |= ETM_EXLEVEL_NS_APP;
> 
> Why is this needed ?
> 

Yes this will not be required as excluding both doesn't make
sense and we print warning in that case already, will drop
this.

> Also we should return an error if the sysfs mode ever tries to clear
> the mode bit
> for kernel in config->mode.
> 

Yes will change as explained in above comment.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS 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 4C749C433DF
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 08:40:51 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id CC7EE20848
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 08:40:50 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="n9oHo5Py"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2394689AbgJPIku (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 04:40:50 -0400
Received: from m42-4.mailgun.net ([69.72.42.4]:48025 "EHLO m42-4.mailgun.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2394681AbgJPIkt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 04:40:49 -0400
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1602837648; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=ustTZbEcMftmhOslkOBYdaqAQIg6oVuX//5E6Jl/XX0=;
 b=n9oHo5Py32FjgxQ4hPi1z6qlhlHB3fZICZRsWgD9vlmXtbWYdY8yDpUYrqWdzQf/GZ4Z6K/A
 /2WxOgpIs/fdzOs76IlhIABopiDLmwt8tKuLBuaGcU7xeLYXZQZIi1N5uOAM1SUrEVRHb+L2
 gEfCgVRSxydzjvEaloNqzhDEQZ4=
X-Mailgun-Sending-Ip: 69.72.42.4
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n03.prod.us-west-2.postgun.com with SMTP id
 5f895c9057b88ccb561d24bf (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 16 Oct 2020 08:40:48
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 6E2EDC433CB; Fri, 16 Oct 2020 08:40:48 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id D9BD3C433F1;
        Fri, 16 Oct 2020 08:40:47 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 16 Oct 2020 14:10:47 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Leo Yan <leo.yan@linaro.org>
Cc:     Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <20201016072401.GC4646@leoy-ThinkPad-X240s>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
 <20201016072401.GC4646@leoy-ThinkPad-X240s>
Message-ID: <f73ba98c345161f1835458182e6a0002@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Leo,

On 2020-10-16 12:54, Leo Yan wrote:
> On Thu, Oct 15, 2020 at 11:40:05PM -0700, Denis Nikitin wrote:
>> Hi Mathieu,
>> 
>> I think one of the use cases could be VMs.
>> Is there isolation between EL1 guest kernels which we can control from 
>> perf
>> in a system wide mode?
> 
> Sorry for suddenly jumping in.
> 
> For KVM, I think we need to implement mechanism for saving/restoring
> CoreSight context for every guest OS, the CPU PMUs has implemented
> related features [1].
> 
> Thanks,
> Leo
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/pmu.c
> 

What happens to the sysfs mode of tracing? For that we would still
need a config right to exclude kernel mode tracing completely.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-10.3 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	MENTIONS_GIT_HOSTING,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 610D6C433E7
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 09:25:01 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id E4A85206DD
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 09:25:00 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="wzdkmbDG"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2394993AbgJPJY7 (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 05:24:59 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35278 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2394577AbgJPJY7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 05:24:59 -0400
Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 060BFC0613D3
        for <linux-kernel@vger.kernel.org>; Fri, 16 Oct 2020 02:24:58 -0700 (PDT)
Received: by mail-pf1-x444.google.com with SMTP id k8so1157353pfk.2
        for <linux-kernel@vger.kernel.org>; Fri, 16 Oct 2020 02:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to:user-agent;
        bh=zUCInfHS0mVdMXYgMLxUEzU7i2cHgkPuhsJxyPPWk3M=;
        b=wzdkmbDGJ8WM/c871lKIy/n2CWoGNITb8anKX9mwnSiMvz4uZA3Eu4AlN7gjQ1L0/P
         9xB4UOcUzt3iOXH3WVOZqVwNAz51/iSPqkhq4E9J6b968A1qYiWYmyXmItQttTZ2yyhf
         +9hCgHyO8tBxL1Mh9+x09CrWzs0+uARAs4r39zxxJwNOxxG1/YsSLzSGLm+C+2a1a3IE
         1kePFELYRzPMeuIEpVyF63dTjnGLxjfy/fzESSrHxRRi031uQv4mPfLSGAhhSjXGmjCN
         I+8zBDS8uCiwhLwOJ5cWoybMM0aZjOKgb2WZqL+ChN4gB8ysRXt1r05YyT/mAkmdA43w
         VRQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to:user-agent;
        bh=zUCInfHS0mVdMXYgMLxUEzU7i2cHgkPuhsJxyPPWk3M=;
        b=qnobIoekrEqcBZBNqlE7VKfokwIFGQgBoGeeEKjFgvgjidX9LTo3sG4fvPZAtj7ziJ
         Z7a94Khh9YUsihcCKwVxNoI605hmUBlCdm/ONIlKQuofTgvV4ZEvZOOVVgV09nUPEQrj
         7rcpdj/Byk2gCJyxU9k1sYck+mpsA6fIt3Hs8cNJVGQpv4vIYCDYTvEqgrtUH0jx7qc7
         OZCoqj0iARw+0Z7SEWbwOg0nSiv9Z/153IK2KKxb2p979FikJJVPoKFfyZpvdRgiYb7W
         t6B8doQ1Smv5ZWiVTkZgXzawu9xwy0VHdXFgSObwycBjCQXhbH3uPL9Bkj7UItUTF6nh
         AP0w==
X-Gm-Message-State: AOAM531lBgxX/Zi17kw291HQ3HjASnAUybT5cpCywOBH/i7GJg7iZ1la
        rCpBHfeSKc1a+Xf3OIW5N+Kvcg==
X-Google-Smtp-Source: ABdhPJx9/QEdjE8/prY2e//ZI1Z6zzyHO7GWBJr4pvSy3DfYUsGiiAcutarYbBieWsmbOwEtb3g4iA==
X-Received: by 2002:a63:a51a:: with SMTP id n26mr2270647pgf.1.1602840297362;
        Fri, 16 Oct 2020 02:24:57 -0700 (PDT)
Received: from leoy-ThinkPad-X240s ([64.120.119.108])
        by smtp.gmail.com with ESMTPSA id o15sm2447398pfp.91.2020.10.16.02.24.53
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Fri, 16 Oct 2020 02:24:55 -0700 (PDT)
Date:   Fri, 16 Oct 2020 17:24:50 +0800
From:   Leo Yan <leo.yan@linaro.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc:     Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Message-ID: <20201016092450.GG4646@leoy-ThinkPad-X240s>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
 <20201016072401.GC4646@leoy-ThinkPad-X240s>
 <f73ba98c345161f1835458182e6a0002@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f73ba98c345161f1835458182e6a0002@codeaurora.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Sai,

On Fri, Oct 16, 2020 at 02:10:47PM +0530, Sai Prakash Ranjan wrote:
> Hi Leo,
> 
> On 2020-10-16 12:54, Leo Yan wrote:
> > On Thu, Oct 15, 2020 at 11:40:05PM -0700, Denis Nikitin wrote:
> > > Hi Mathieu,
> > > 
> > > I think one of the use cases could be VMs.
> > > Is there isolation between EL1 guest kernels which we can control
> > > from perf
> > > in a system wide mode?
> > 
> > Sorry for suddenly jumping in.
> > 
> > For KVM, I think we need to implement mechanism for saving/restoring
> > CoreSight context for every guest OS, the CPU PMUs has implemented
> > related features [1].
> > 
> > Thanks,
> > Leo
> > 
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/pmu.c
> > 
> 
> What happens to the sysfs mode of tracing? For that we would still
> need a config right to exclude kernel mode tracing completely.

IIUC, sysfs mode and perf mode both can apply the same approach, the
guest OS runs a thread context for the host, so when a guest OS is
switched in or out, the hypervisor can save/restore the context for
the guest OS; thus every guest OS will have its dedicated context and
trace data ideally.

Thanks,
Leo

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS 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 CD6BBC43457
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 10:30:51 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 682332084C
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 10:30:51 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="ZynXNCMs"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2395303AbgJPKau (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 06:30:50 -0400
Received: from m42-4.mailgun.net ([69.72.42.4]:12297 "EHLO m42-4.mailgun.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2389536AbgJPKas (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 06:30:48 -0400
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1602844247; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=MBBTz+wbATBpIcOHVoqb2HLcX9i5i5/HpFr5H1lz7UY=;
 b=ZynXNCMsxqq6J7M8zHHNFObXUdjvX7MGXV9KnZwXJ5NevORKTV8G7gFhtKLQi38qn75mcPaX
 WL6FaewAhdgU1lK2sBi7Vupok3ChrYNSE8NpVsg+C4U6le4gOmGtbmDiGJ2j3/nlLbp1NSSK
 aFY60KeKCmSWJQjwK6MKSMATN/A=
X-Mailgun-Sending-Ip: 69.72.42.4
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n01.prod.us-west-2.postgun.com with SMTP id
 5f89765706d81bc48d016215 (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 16 Oct 2020 10:30:47
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 60C47C43382; Fri, 16 Oct 2020 10:30:47 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id C25CFC433CB;
        Fri, 16 Oct 2020 10:30:46 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 16 Oct 2020 16:00:46 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Leo Yan <leo.yan@linaro.org>
Cc:     Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <20201016092450.GG4646@leoy-ThinkPad-X240s>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
 <20201016072401.GC4646@leoy-ThinkPad-X240s>
 <f73ba98c345161f1835458182e6a0002@codeaurora.org>
 <20201016092450.GG4646@leoy-ThinkPad-X240s>
Message-ID: <f4fff311015e45214e07606fcf33e8e4@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Leo,

On 2020-10-16 14:54, Leo Yan wrote:
> Hi Sai,
> 
> On Fri, Oct 16, 2020 at 02:10:47PM +0530, Sai Prakash Ranjan wrote:
>> Hi Leo,
>> 
>> On 2020-10-16 12:54, Leo Yan wrote:
>> > On Thu, Oct 15, 2020 at 11:40:05PM -0700, Denis Nikitin wrote:
>> > > Hi Mathieu,
>> > >
>> > > I think one of the use cases could be VMs.
>> > > Is there isolation between EL1 guest kernels which we can control
>> > > from perf
>> > > in a system wide mode?
>> >
>> > Sorry for suddenly jumping in.
>> >
>> > For KVM, I think we need to implement mechanism for saving/restoring
>> > CoreSight context for every guest OS, the CPU PMUs has implemented
>> > related features [1].
>> >
>> > Thanks,
>> > Leo
>> >
>> > [1]
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/pmu.c
>> >
>> 
>> What happens to the sysfs mode of tracing? For that we would still
>> need a config right to exclude kernel mode tracing completely.
> 
> IIUC, sysfs mode and perf mode both can apply the same approach, the
> guest OS runs a thread context for the host, so when a guest OS is
> switched in or out, the hypervisor can save/restore the context for
> the guest OS; thus every guest OS will have its dedicated context and
> trace data ideally.
> 

Thanks for the explanation, so for this usecase then we would have to
implement something as you suggested, not sure how hard would that be
looking at my KVM knowledge(which at the moment is almost nil) when
compared to a kconfig ;)

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-11.5 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,
	SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 866FFC43457
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 11:11:55 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 34B53207F7
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 11:11:55 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2406789AbgJPLLy (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 07:11:54 -0400
Received: from foss.arm.com ([217.140.110.172]:34678 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2391033AbgJPLLy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 07:11:54 -0400
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
        by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 12107D6E;
        Fri, 16 Oct 2020 04:11:53 -0700 (PDT)
Received: from [10.57.50.28] (unknown [10.57.50.28])
        by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0E7A43F719;
        Fri, 16 Oct 2020 04:11:50 -0700 (PDT)
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
To:     Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>
Cc:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
From:   Suzuki Poulose <suzuki.poulose@arm.com>
Message-ID: <fcfd6a92-de94-e318-5715-23b97fb9724e@arm.com>
Date:   Fri, 16 Oct 2020 12:11:40 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/16/20 7:40 AM, Denis Nikitin wrote:
> Hi Mathieu,
> 
> I think one of the use cases could be VMs.
> Is there isolation between EL1 guest kernels which we can control from 
> perf in a system wide mode?

The proposed solution doesn't solve this for VMs anyway. It only
excludes EL1 *OR* EL2, depending on the host kernel's running  EL.
We cannot support Virtual ETM access for VMs with memory mapped
accesses.

Unforutnately, trace filtering is the solution for preventing tracing
for EL1 guest/kernel (available from v8.4 Self Hosted extensions). Other
option is to add support for "exclude_guest" support for CoreSight for perf.
But again this can't be controlled by sysfs. And it can't be enforced 
for perf, if not specified. Again it all goes back to the root
permission hammer lock which Mathieu pointed out.


With the v8.4 Self hosted trace extensions, Guest and Host both could
control individually if they can be traced (both EL0 and EL1/2).

Suzuki

> 
> Thanks,
> Denis
> 
> On Thu, Oct 15, 2020 at 9:03 AM Mathieu Poirier 
> <mathieu.poirier@linaro.org <mailto:mathieu.poirier@linaro.org>> wrote:
> 
>     On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>      > On production systems with ETMs enabled, it is preferred to
>      > exclude kernel mode(NS EL1) tracing for security concerns and
>      > support only userspace(NS EL0) tracing. So provide an option
>      > via kconfig to exclude kernel mode tracing if it is required.
>      > This config is disabled by default and would not affect the
>      > current configuration which has both kernel and userspace
>      > tracing enabled by default.
>      >
> 
>     One requires root access (or be part of a special trace group) to be
>     able to use
>     the cs_etm PMU.  With this kind of elevated access restricting
>     tracing at EL1
>     provides little in terms of security.
> 
>     Thanks,
>     Mathieu
> 
>      > Signed-off-by: Sai Prakash Ranjan
>     <saiprakash.ranjan@codeaurora.org
>     <mailto:saiprakash.ranjan@codeaurora.org>>
>      > ---
>      >  drivers/hwtracing/coresight/Kconfig                | 9 +++++++++
>      >  drivers/hwtracing/coresight/coresight-etm4x-core.c | 6 +++++-
>      >  2 files changed, 14 insertions(+), 1 deletion(-)
>      >
>      > diff --git a/drivers/hwtracing/coresight/Kconfig
>     b/drivers/hwtracing/coresight/Kconfig
>      > index c1198245461d..52435de8824c 100644
>      > --- a/drivers/hwtracing/coresight/Kconfig
>      > +++ b/drivers/hwtracing/coresight/Kconfig
>      > @@ -110,6 +110,15 @@ config CORESIGHT_SOURCE_ETM4X
>      >         To compile this driver as a module, choose M here: the
>      >         module will be called coresight-etm4x.
>      >
>      > +config CORESIGHT_ETM4X_EXCL_KERN
>      > +     bool "Coresight ETM 4.x exclude kernel mode tracing"
>      > +     depends on CORESIGHT_SOURCE_ETM4X
>      > +     help
>      > +       This will exclude kernel mode(NS EL1) tracing if enabled.
>     This option
>      > +       will be useful to provide more flexible options on
>     production systems
>      > +       where only userspace(NS EL0) tracing might be preferred
>     for security
>      > +       reasons.
>      > +
>      >  config CORESIGHT_STM
>      >       tristate "CoreSight System Trace Macrocell driver"
>      >       depends on (ARM && !(CPU_32v3 || CPU_32v4 || CPU_32v4T)) ||
>     ARM64
>      > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>     b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>      > index abd706b216ac..7e5669e5cd1f 100644
>      > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
>      > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
>      > @@ -832,6 +832,9 @@ static u64 etm4_get_ns_access_type(struct
>     etmv4_config *config)
>      >  {
>      >       u64 access_type = 0;
>      >
>      > +     if (IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
>      > +             config->mode |= ETM_MODE_EXCL_KERN;
>      > +
>      >       /*
>      >        * EXLEVEL_NS, bits[15:12]
>      >        * The Exception levels are:
>      > @@ -849,7 +852,8 @@ static u64 etm4_get_ns_access_type(struct
>     etmv4_config *config)
>      >               access_type = ETM_EXLEVEL_NS_HYP;
>      >       }
>      >
>      > -     if (config->mode & ETM_MODE_EXCL_USER)
>      > +     if (config->mode & ETM_MODE_EXCL_USER &&
>      > +         !IS_ENABLED(CONFIG_CORESIGHT_ETM4X_EXCL_KERN))
>      >               access_type |= ETM_EXLEVEL_NS_APP;
>      >
>      >       return access_type;
>      >
>      > base-commit: 3477326277451000bc667dfcc4fd0774c039184c
>      > --
>      > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is
>     a member
>      > of Code Aurora Forum, hosted by The Linux Foundation
>      >
> 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-10.5 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,
	NICE_REPLY_A,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 0966EC433DF
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 11:38:54 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id B1D052084C
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 11:38:53 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2406842AbgJPLix (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 07:38:53 -0400
Received: from foss.arm.com ([217.140.110.172]:35278 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2404884AbgJPLiw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 07:38:52 -0400
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
        by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BEBBDD6E;
        Fri, 16 Oct 2020 04:38:51 -0700 (PDT)
Received: from [10.57.50.28] (unknown [10.57.50.28])
        by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 972553F719;
        Fri, 16 Oct 2020 04:38:49 -0700 (PDT)
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
To:     Leo Yan <leo.yan@linaro.org>,
        Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc:     Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
 <20201016072401.GC4646@leoy-ThinkPad-X240s>
 <f73ba98c345161f1835458182e6a0002@codeaurora.org>
 <20201016092450.GG4646@leoy-ThinkPad-X240s>
From:   Suzuki Poulose <suzuki.poulose@arm.com>
Message-ID: <f6ee4156-664c-7bff-8e35-5cd1acdbaa84@arm.com>
Date:   Fri, 16 Oct 2020 12:38:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <20201016092450.GG4646@leoy-ThinkPad-X240s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/16/20 10:24 AM, Leo Yan wrote:
> Hi Sai,
> 
> On Fri, Oct 16, 2020 at 02:10:47PM +0530, Sai Prakash Ranjan wrote:
>> Hi Leo,
>>
>> On 2020-10-16 12:54, Leo Yan wrote:
>>> On Thu, Oct 15, 2020 at 11:40:05PM -0700, Denis Nikitin wrote:
>>>> Hi Mathieu,
>>>>
>>>> I think one of the use cases could be VMs.
>>>> Is there isolation between EL1 guest kernels which we can control
>>>> from perf
>>>> in a system wide mode?
>>>
>>> Sorry for suddenly jumping in.
>>>
>>> For KVM, I think we need to implement mechanism for saving/restoring
>>> CoreSight context for every guest OS, the CPU PMUs has implemented
>>> related features [1].
>>>
>>> Thanks,
>>> Leo
>>>
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kvm/pmu.c
>>>

Its not as easy as the CPU PMU for virtualizing the ETMs (with memory
mapped access only), i.e supporting ETMs from VMs.
We could definitely stop/resume on guest entry/exit, to support 
attr.exclude_guest.

>>
>> What happens to the sysfs mode of tracing? For that we would still
>> need a config right to exclude kernel mode tracing completely.
> 
> IIUC, sysfs mode and perf mode both can apply the same approach, the
> guest OS runs a thread context for the host, so when a guest OS is
> switched in or out, the hypervisor can save/restore the context for
> the guest OS; thus every guest OS will have its dedicated context and
> trace data ideally.

I don't think Guest Context is something we can support as mentioned
above, at least for systems without sysreg access for ETMs (and 
virtualizing ETRs is a different story !)

Cheers
Suzuki

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 8D3A6C433E7
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 13:14:26 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 321FE2084C
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 13:14:26 +0000 (UTC)
Authentication-Results: mail.kernel.org;
	dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="CpB0A1qL"
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2407026AbgJPNOX (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 09:14:23 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42628 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2395334AbgJPNON (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 09:14:13 -0400
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D3F3C0613D3
        for <linux-kernel@vger.kernel.org>; Fri, 16 Oct 2020 06:14:13 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id y14so1465896pfp.13
        for <linux-kernel@vger.kernel.org>; Fri, 16 Oct 2020 06:14:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to:user-agent;
        bh=2v//XZb9addO+YnQGTuZ1rtYAQE5PbqfnjEF9yMyDoc=;
        b=CpB0A1qLkDsgmfvKFlr7UWapLdP1M00owIA2ts+xR/6P+6yK9aTnPfr/6RsH0lcJ+l
         rX5wPDmXPApN0QW7GUw/tRwsktOJgkS2wcU59h0u8CN8GJnM/Jtowgu1lUiN63H8RIKc
         wx3+f+RTXRcFKXiqmhSmnjdxEoPbQN1uj5++a3/5ThnGYl42h1HmtPI3AcKCgMbUrAjb
         vIIfwN2kfj2evVmwQ/OaNQDq4nl+TmJaTRNxpwtggZR8txOeD9QdwZhx2n1ZlKVL4k2R
         Gx3S4zpiFqE7TM9VVfbXNrvpt3gpBIWZeiJmmYFzZstDxfviyixPE2I7Gn+DXEbmaFli
         3tcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to:user-agent;
        bh=2v//XZb9addO+YnQGTuZ1rtYAQE5PbqfnjEF9yMyDoc=;
        b=K/BWq56so8ct9CuP0ci0XA9srpSLZ8ZG7WwmtQ80e/MVoLJSvlV5+rlwyLsVuql65P
         zhjRHzrbeLk8Pjf8QBx/m/magKzYJdl0b4UzH0yvpTpsLvGNsX/Y6qrnqzULurQK6Vq5
         NnCmlf62Fm24yMI7tvMQHWyA2GhWIg8c+JqsOyVDI2uKfSfqpDXrmetjY7RrCX2SrcT8
         Yenq77l0ueVts6DhbnYC+a4gVGFvl6+bjFE/ed1sy1X/njIoQ+mDYSH52BmcjIrC9AM3
         FxnLG/iZ0k7p3xmmIzGZS0fo1RSClA0Nc/uqyLLGBY4GktWCut9Ak62yMDAflg4jv3f9
         0ieg==
X-Gm-Message-State: AOAM533VEQ3/hyHXE+nD9033/PbC7krrRraTKeSxuGsNLG8T+50LAdTX
        7XiiRlABSzdwraeMLIH17bjLUQ==
X-Google-Smtp-Source: ABdhPJwpBt1lWaerL/zTVz8TqRFSN2H2X1ZaeEtayOXScEJOTVGGH1v+RUnnCnoUuu2gcA9u1B5ljg==
X-Received: by 2002:a63:1865:: with SMTP id 37mr3186358pgy.322.1602854052978;
        Fri, 16 Oct 2020 06:14:12 -0700 (PDT)
Received: from leoy-ThinkPad-X240s ([64.120.119.108])
        by smtp.gmail.com with ESMTPSA id e5sm3587979pjd.0.2020.10.16.06.14.09
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Fri, 16 Oct 2020 06:14:12 -0700 (PDT)
Date:   Fri, 16 Oct 2020 21:14:07 +0800
From:   Leo Yan <leo.yan@linaro.org>
To:     Suzuki Poulose <suzuki.poulose@arm.com>
Cc:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Message-ID: <20201016131407.GA31839@leoy-ThinkPad-X240s>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
 <20201016072401.GC4646@leoy-ThinkPad-X240s>
 <f73ba98c345161f1835458182e6a0002@codeaurora.org>
 <20201016092450.GG4646@leoy-ThinkPad-X240s>
 <f6ee4156-664c-7bff-8e35-5cd1acdbaa84@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f6ee4156-664c-7bff-8e35-5cd1acdbaa84@arm.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Oct 16, 2020 at 12:38:47PM +0100, Suzuki Kuruppassery Poulose wrote:

[...]

> > > What happens to the sysfs mode of tracing? For that we would still
> > > need a config right to exclude kernel mode tracing completely.
> > 
> > IIUC, sysfs mode and perf mode both can apply the same approach, the
> > guest OS runs a thread context for the host, so when a guest OS is
> > switched in or out, the hypervisor can save/restore the context for
> > the guest OS; thus every guest OS will have its dedicated context and
> > trace data ideally.
> 
> I don't think Guest Context is something we can support as mentioned
> above, at least for systems without sysreg access for ETMs (and virtualizing
> ETRs is a different story !)

Thanks for sharing thoughts, Suzuki.

I missed the device virtulisation.  Here should virtualize all devices
(includes CoreSight ETM/funnel/ETR/ETF)?  Or only need to virtualize
ETRs?

Obviously, this is a difficult task :)

Thanks,
Leo

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Fh6n=DX=vger.kernel.org=linux-kernel-owner@kernel.org>
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=-5.5 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,
	SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 7BA8FC433DF
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 13:17:58 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 202AC2083B
	for <linux-kernel@archiver.kernel.org>; Fri, 16 Oct 2020 13:17:58 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2407391AbgJPNR5 (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 16 Oct 2020 09:17:57 -0400
Received: from foss.arm.com ([217.140.110.172]:37216 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2407363AbgJPNR5 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 16 Oct 2020 09:17:57 -0400
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
        by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 79AEC1FB;
        Fri, 16 Oct 2020 06:17:56 -0700 (PDT)
Received: from [10.57.50.28] (unknown [10.57.50.28])
        by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 87CB73F71F;
        Fri, 16 Oct 2020 06:17:53 -0700 (PDT)
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
To:     Leo Yan <leo.yan@linaro.org>
Cc:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
 <20201016072401.GC4646@leoy-ThinkPad-X240s>
 <f73ba98c345161f1835458182e6a0002@codeaurora.org>
 <20201016092450.GG4646@leoy-ThinkPad-X240s>
 <f6ee4156-664c-7bff-8e35-5cd1acdbaa84@arm.com>
 <20201016131407.GA31839@leoy-ThinkPad-X240s>
From:   Suzuki Poulose <suzuki.poulose@arm.com>
Message-ID: <16b3be3a-0d2d-0d0f-24a5-020480ed980c@arm.com>
Date:   Fri, 16 Oct 2020 14:17:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <20201016131407.GA31839@leoy-ThinkPad-X240s>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/16/20 2:14 PM, Leo Yan wrote:
> On Fri, Oct 16, 2020 at 12:38:47PM +0100, Suzuki Kuruppassery Poulose wrote:
> 
> [...]
> 
>>>> What happens to the sysfs mode of tracing? For that we would still
>>>> need a config right to exclude kernel mode tracing completely.
>>>
>>> IIUC, sysfs mode and perf mode both can apply the same approach, the
>>> guest OS runs a thread context for the host, so when a guest OS is
>>> switched in or out, the hypervisor can save/restore the context for
>>> the guest OS; thus every guest OS will have its dedicated context and
>>> trace data ideally.
>>
>> I don't think Guest Context is something we can support as mentioned
>> above, at least for systems without sysreg access for ETMs (and virtualizing
>> ETRs is a different story !)
> 
> Thanks for sharing thoughts, Suzuki.
> 
> I missed the device virtulisation.  Here should virtualize all devices
> (includes CoreSight ETM/funnel/ETR/ETF)?  Or only need to virtualize
> ETRs?

I wouldn't even think of virtualizing the components without sysreg
access. So let us not worry about it :-)

Cheers
Suzuki

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no 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 6734CC433DB
	for <linux-kernel@archiver.kernel.org>; Fri, 15 Jan 2021 05:47:44 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 1B250239FC
	for <linux-kernel@archiver.kernel.org>; Fri, 15 Jan 2021 05:47:44 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1732312AbhAOFrc (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Fri, 15 Jan 2021 00:47:32 -0500
Received: from m43-15.mailgun.net ([69.72.43.15]:62399 "EHLO
        m43-15.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1730872AbhAOFra (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 15 Jan 2021 00:47:30 -0500
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1610689627; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=uKd60FvtWU74hmbEb+xSaAfRXFvIDWXHtourTMrbpIg=;
 b=Qub5SiFrK91He6a55DbzZfxC8QpBU2oQhsV8e3e+NgPhsrmtZz//a+k6ZwGuhS49lHENDD9q
 /YLbxOrA7Ilgqnz8xTsUF9VMOtHJFFapkFzT88vF4HedYEGck7jeoDqQ+gYimEUnfBFV3wCZ
 Hh1O1iUhk0Y1pZw+saH6KjKA/zM=
X-Mailgun-Sending-Ip: 69.72.43.15
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n10.prod.us-west-2.postgun.com with SMTP id
 60012c323b6dceb1329ae0df (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 15 Jan 2021 05:46:26
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id ADD34C43461; Fri, 15 Jan 2021 05:46:25 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id 17304C433CA;
        Fri, 15 Jan 2021 05:46:25 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 15 Jan 2021 11:16:24 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>
Cc:     Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, Al Grant <al.grant@arm.com>,
        leo.yan@linaro.org, mnissler@google.com
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <20201015160257.GA1450102@xps15>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
Message-ID: <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Mathieu, Suzuki

On 2020-10-15 21:32, Mathieu Poirier wrote:
> On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>> On production systems with ETMs enabled, it is preferred to
>> exclude kernel mode(NS EL1) tracing for security concerns and
>> support only userspace(NS EL0) tracing. So provide an option
>> via kconfig to exclude kernel mode tracing if it is required.
>> This config is disabled by default and would not affect the
>> current configuration which has both kernel and userspace
>> tracing enabled by default.
>> 
> 
> One requires root access (or be part of a special trace group) to be 
> able to use
> the cs_etm PMU.  With this kind of elevated access restricting tracing 
> at EL1
> provides little in terms of security.
> 

Apart from the VM usecase discussed, I am told there are other
security concerns here regarding need to exclude kernel mode tracing
even for the privileged users/root. One such case being the ability
to analyze cryptographic code execution since ETMs can record all
branch instructions including timestamps in the kernel and there may
be other cases as well which I may not be aware of and hence have
added Denis and Mattias. Please let us know if you have any questions
further regarding this not being a security concern.

After this discussion, I would like to post a v2 based on Suzuki's
feedback earlier. @Suzuki, I have a common config for ETM3 and ETM4
but couldn't get much idea on how to implement it for Intel PTs, if
you have any suggestions there, please do share or we can have this
only for Coresight ETMs.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no
	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 0A0C8C433DB
	for <linux-kernel@archiver.kernel.org>; Mon, 18 Jan 2021 14:50:02 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id CC7A322B40
	for <linux-kernel@archiver.kernel.org>; Mon, 18 Jan 2021 14:50:01 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2405260AbhAROuA (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 18 Jan 2021 09:50:00 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57876 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2405179AbhAROsR (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 18 Jan 2021 09:48:17 -0500
Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88122C0613C1
        for <linux-kernel@vger.kernel.org>; Mon, 18 Jan 2021 06:47:36 -0800 (PST)
Received: by mail-ua1-x92a.google.com with SMTP id v23so1307004uam.8
        for <linux-kernel@vger.kernel.org>; Mon, 18 Jan 2021 06:47:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=chromium.org; s=google;
        h=mime-version:references:in-reply-to:from:date:message-id:subject:to
         :cc;
        bh=tYITA3Yxe+LNUEBbIjMhLMDLo8Pr6qOWRiVR9QOc69o=;
        b=WBp4BQ4iS/nMuJHj2dRCYS1FOe1q70UMadKm9plqyvTpqfBAye6UbGn+Szu9OK2C9t
         /sL8U2B/SyzKpzYyfD/PA0RseoBzXrBcf12M4EFyJMxQXw3jeGXo1UhmVOCddHRiGoax
         Xyfns6tQ10yiERfST33vIWqybEqEXPJWFcPbE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=tYITA3Yxe+LNUEBbIjMhLMDLo8Pr6qOWRiVR9QOc69o=;
        b=d6aL5oPAgp4ND6SMzEPqcX49+UdWK6q/AMpaZ5yKUx4mGSVKpcTDKsP/9mgG7P21QS
         Nrd49pz9IFLHuQQEbOIMmJrVqDTLgtfaEGz2GT8kBz/7TLCL/lsDOF3UjM9MsrPLwfKw
         5KDJ53nJzY7dxu6fMeoDFYZWkD1HLgMTvGyH088ywTBReKR4a3ZinSRaiO2FnrABxq5m
         G8GzE6lP7H1oKB53SAr9TzcxykiBEQoBTuyqlwLOkYF/lUibVtcLgsostETDTwoBF7b0
         EjnmjSN7ivcfMvIv8T9e5EjBqz2FgAKYftR6bueF8yuUDrsl0Mpke4QJVprBqagUAY71
         MLRA==
X-Gm-Message-State: AOAM533YQWRpsb8PfOTMP77YxbMkk5EVB3HcpYrcPItI6I7DyAMySTVC
        MZgzSttyQpDUhEPuCWFAViFUdiOg61Qm7uB5m2wtSw==
X-Google-Smtp-Source: ABdhPJwMOdZBQVMFI+wOY4prWcda+5x/AEFNDfgLueyLCfRiRaIBomu6uUxWpvmwEP1qgrXX6LiK2JHjkjI2sbTLjFs=
X-Received: by 2002:ab0:7193:: with SMTP id l19mr2785323uao.84.1610981255465;
 Mon, 18 Jan 2021 06:47:35 -0800 (PST)
MIME-Version: 1.0
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15> <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
In-Reply-To: <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
From:   Mattias Nissler <mnissler@chromium.org>
Date:   Mon, 18 Jan 2021 15:47:23 +0100
Message-ID: <CAKUbbx+ZC9cLvcaJnrDYYsrUhfO3dOXJGoLswL30nRzChjwn-w@mail.gmail.com>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, Al Grant <al.grant@arm.com>,
        leo.yan@linaro.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jan 15, 2021 at 6:46 AM Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> Hello Mathieu, Suzuki
>
> On 2020-10-15 21:32, Mathieu Poirier wrote:
> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
> >> On production systems with ETMs enabled, it is preferred to
> >> exclude kernel mode(NS EL1) tracing for security concerns and
> >> support only userspace(NS EL0) tracing. So provide an option
> >> via kconfig to exclude kernel mode tracing if it is required.
> >> This config is disabled by default and would not affect the
> >> current configuration which has both kernel and userspace
> >> tracing enabled by default.
> >>
> >
> > One requires root access (or be part of a special trace group) to be
> > able to use
> > the cs_etm PMU.  With this kind of elevated access restricting tracing
> > at EL1
> > provides little in terms of security.
> >
>
> Apart from the VM usecase discussed, I am told there are other
> security concerns here regarding need to exclude kernel mode tracing
> even for the privileged users/root. One such case being the ability
> to analyze cryptographic code execution since ETMs can record all
> branch instructions including timestamps in the kernel and there may
> be other cases as well which I may not be aware of and hence have
> added Denis and Mattias. Please let us know if you have any questions
> further regarding this not being a security concern.

Well, the idea that root privileges != full control over the kernel
isn't new and at the very least since lockdown became part of mainline
[1] no longer an esoteric edge case. Regarding the use case Sai hints
at (namely protection of secrets in the kernel), Matthew Garret
actually has some more thoughts about confidentiality mode for
lockdown for secret protection [2]. And thus, unless someone can make
a compelling case that instruction-level tracing will not leak secrets
held by the kernel, I think an option for the kernel to prevent itself
from being traced (even by root) is valuable.

Finally, to sketch a practical use case scenario: Consider a system
where disk contents are encrypted and the encryption key is set up by
the user when mounting the file system. From that point on the
encryption key resides in the kernel. It seems reasonable to expect
that the disk encryption key be protected from exfiltration even if
the system later suffers a root compromise (or even against insiders
that have root access), at least as long as the attacker doesn't
manage to compromise the kernel.

[1] https://lwn.net/Articles/796866/
[2] https://mjg59.dreamwidth.org/55105.html

>
> After this discussion, I would like to post a v2 based on Suzuki's
> feedback earlier. @Suzuki, I have a common config for ETM3 and ETM4
> but couldn't get much idea on how to implement it for Intel PTs, if
> you have any suggestions there, please do share or we can have this
> only for Coresight ETMs.
>
> Thanks,
> Sai
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS autolearn=no 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 F2F87C433E6
	for <linux-kernel@archiver.kernel.org>; Mon, 18 Jan 2021 20:25:05 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 9E4E422D08
	for <linux-kernel@archiver.kernel.org>; Mon, 18 Jan 2021 20:25:05 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2437893AbhARUYu (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Mon, 18 Jan 2021 15:24:50 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45926 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1728901AbhARUYh (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 18 Jan 2021 15:24:37 -0500
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D558C061574
        for <linux-kernel@vger.kernel.org>; Mon, 18 Jan 2021 12:23:57 -0800 (PST)
Received: by mail-pf1-x436.google.com with SMTP id h10so10837533pfo.9
        for <linux-kernel@vger.kernel.org>; Mon, 18 Jan 2021 12:23:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=PRwPVFLZbO3DnAQ42ccV130KeMHAu1TzeUayWROwv/U=;
        b=D2VzllMwI2rSMF3fX1njbMFiKbfDpQ3IXRCYQgDbNGdf1yPZ150jNDDBeTZ+3rw+P2
         5FnicS/fv346tnbPPjPFrElvpO4GK/EpxP39jG8NBTLBAGGP/hPE33tHcwGdcEesVXlt
         G8liJ4Y7tDRNrqjMdNcP4RQoQ5Oytb2eoShFWME3gd1RaE8PrsGULM+jnSEOK3HIZce4
         JmbvAKFS56TNaJj6y6eUWun9j6i2uLH9fusqwr9RscqhgmF5FGkyhquxgXrAaDb8k6y4
         MAuYwzp0Myr0wGHUZzPbT4Nb1OU3+szJhcUoaMr+09LjodIERu1H1iPD84VKmY8eg4gN
         lTfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=PRwPVFLZbO3DnAQ42ccV130KeMHAu1TzeUayWROwv/U=;
        b=YFke1H/sAqgIrAvwNGBR19XpHcci6oO4FyMSDZO/xjRNAcQo/yPjhfOHW11kS/xYOD
         R0mhVS1OZvZxpA7BXHEpnEmrluuS2BWTjq0hDYORTxOq42ddDopt05BJSF5zaKZ+Kd7G
         DL+SYg0QaS6rUUaS2SCUD4Hu0McmbNDDGCQT0/lCHnz1ncUJxAUP508O+irSO3+eZ3Oi
         pgikogUI1JYgR5E8VKJykzeJDe4LMZeb6BdRk9SJcPy4q6AB8K655tUs6nP6Acn9INCw
         ufox3JAjjumwmwPJj2Dr8ZvgbSGADvqma3tfmDbFcw+E26qtd+YoCTH5Tkb7lXkp7mha
         zM0g==
X-Gm-Message-State: AOAM530dy2tK7tKuUfUPgz1uIK7u+N5bL6zKcJhWAYyufpmuVagTeICb
        xHuZJi+zCILrEEIM7cs0p7nhJQ==
X-Google-Smtp-Source: ABdhPJy+XiAne7fTflPqmQNXkPVAJW9nmT50Uu+iH1IjIiuVrMWcUoQzrZt24boa3WoZAdDT6VX/dg==
X-Received: by 2002:a63:c441:: with SMTP id m1mr1233168pgg.353.1611001437058;
        Mon, 18 Jan 2021 12:23:57 -0800 (PST)
Received: from xps15 (S0106889e681aac74.cg.shawcable.net. [68.147.0.187])
        by smtp.gmail.com with ESMTPSA id br21sm259184pjb.9.2021.01.18.12.23.55
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 18 Jan 2021 12:23:56 -0800 (PST)
Date:   Mon, 18 Jan 2021 13:23:54 -0700
From:   Mathieu Poirier <mathieu.poirier@linaro.org>
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc:     Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, Al Grant <al.grant@arm.com>,
        leo.yan@linaro.org, mnissler@google.com
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Message-ID: <20210118202354.GC464579@xps15>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
> Hello Mathieu, Suzuki
> 
> On 2020-10-15 21:32, Mathieu Poirier wrote:
> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
> > > On production systems with ETMs enabled, it is preferred to
> > > exclude kernel mode(NS EL1) tracing for security concerns and
> > > support only userspace(NS EL0) tracing. So provide an option
> > > via kconfig to exclude kernel mode tracing if it is required.
> > > This config is disabled by default and would not affect the
> > > current configuration which has both kernel and userspace
> > > tracing enabled by default.
> > > 
> > 
> > One requires root access (or be part of a special trace group) to be
> > able to use
> > the cs_etm PMU.  With this kind of elevated access restricting tracing
> > at EL1
> > provides little in terms of security.
> > 
> 
> Apart from the VM usecase discussed, I am told there are other
> security concerns here regarding need to exclude kernel mode tracing
> even for the privileged users/root. One such case being the ability
> to analyze cryptographic code execution since ETMs can record all
> branch instructions including timestamps in the kernel and there may
> be other cases as well which I may not be aware of and hence have
> added Denis and Mattias. Please let us know if you have any questions
> further regarding this not being a security concern.

Even if we were to apply this patch there are many ways to compromise a system
or get the kernel to reveal important information using the perf subsystem.  I
would perfer to tackle the problem at that level rather than concentrating on
coresight.

> 
> After this discussion, I would like to post a v2 based on Suzuki's
> feedback earlier. @Suzuki, I have a common config for ETM3 and ETM4
> but couldn't get much idea on how to implement it for Intel PTs, if
> you have any suggestions there, please do share or we can have this
> only for Coresight ETMs.
> 
> Thanks,
> Sai
> 
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no 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 22184C433DB
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 05:59:35 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id DF5E322ADF
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 05:59:34 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1731635AbhASF4S (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 00:56:18 -0500
Received: from m42-8.mailgun.net ([69.72.42.8]:43442 "EHLO m42-8.mailgun.net"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2388458AbhASFUI (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 00:20:08 -0500
X-Greylist: delayed 351 seconds by postgrey-1.27 at vger.kernel.org; Tue, 19 Jan 2021 00:19:53 EST
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1611033562; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=TsmWni2lFqo/KCTp9v2otaejvUeB6CXmbavuS8alcYo=;
 b=aJd8YwPQ07dp5pXrPp+peV4sduXBFqrTskVPVyOVfRlcn2g6anOE9MWIHV5VGHb6UdZvTkRN
 2MTHzB5t4caxSaNR+lVwpQmvkftJThCUoX9vtlyZcBb4bvjRrG4dS6GPn4U4OJStbfLEIUB1
 BT65b82c5qwRLU/837n2eACmegw=
X-Mailgun-Sending-Ip: 69.72.42.8
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n01.prod.us-east-1.postgun.com with SMTP id
 60066a51ba7f868506e7285d (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 19 Jan 2021 05:12:49
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 82D11C43463; Tue, 19 Jan 2021 05:12:48 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id 84544C433C6;
        Tue, 19 Jan 2021 05:12:47 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Tue, 19 Jan 2021 10:42:47 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Mattias Nissler <mnissler@chromium.org>
Cc:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, Al Grant <al.grant@arm.com>,
        leo.yan@linaro.org
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <CAKUbbx+ZC9cLvcaJnrDYYsrUhfO3dOXJGoLswL30nRzChjwn-w@mail.gmail.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <CAKUbbx+ZC9cLvcaJnrDYYsrUhfO3dOXJGoLswL30nRzChjwn-w@mail.gmail.com>
Message-ID: <6a3a876e9877322cb46c246a86312fbe@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2021-01-18 20:17, Mattias Nissler wrote:
> On Fri, Jan 15, 2021 at 6:46 AM Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>> 
>> Hello Mathieu, Suzuki
>> 
>> On 2020-10-15 21:32, Mathieu Poirier wrote:
>> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>> >> On production systems with ETMs enabled, it is preferred to
>> >> exclude kernel mode(NS EL1) tracing for security concerns and
>> >> support only userspace(NS EL0) tracing. So provide an option
>> >> via kconfig to exclude kernel mode tracing if it is required.
>> >> This config is disabled by default and would not affect the
>> >> current configuration which has both kernel and userspace
>> >> tracing enabled by default.
>> >>
>> >
>> > One requires root access (or be part of a special trace group) to be
>> > able to use
>> > the cs_etm PMU.  With this kind of elevated access restricting tracing
>> > at EL1
>> > provides little in terms of security.
>> >
>> 
>> Apart from the VM usecase discussed, I am told there are other
>> security concerns here regarding need to exclude kernel mode tracing
>> even for the privileged users/root. One such case being the ability
>> to analyze cryptographic code execution since ETMs can record all
>> branch instructions including timestamps in the kernel and there may
>> be other cases as well which I may not be aware of and hence have
>> added Denis and Mattias. Please let us know if you have any questions
>> further regarding this not being a security concern.
> 
> Well, the idea that root privileges != full control over the kernel
> isn't new and at the very least since lockdown became part of mainline
> [1] no longer an esoteric edge case. Regarding the use case Sai hints
> at (namely protection of secrets in the kernel), Matthew Garret
> actually has some more thoughts about confidentiality mode for
> lockdown for secret protection [2]. And thus, unless someone can make
> a compelling case that instruction-level tracing will not leak secrets
> held by the kernel, I think an option for the kernel to prevent itself
> from being traced (even by root) is valuable.
> 
> Finally, to sketch a practical use case scenario: Consider a system
> where disk contents are encrypted and the encryption key is set up by
> the user when mounting the file system. From that point on the
> encryption key resides in the kernel. It seems reasonable to expect
> that the disk encryption key be protected from exfiltration even if
> the system later suffers a root compromise (or even against insiders
> that have root access), at least as long as the attacker doesn't
> manage to compromise the kernel.
> 
> [1] https://lwn.net/Articles/796866/
> [2] https://mjg59.dreamwidth.org/55105.html
> 

Thanks for the detailed description, it is way better put than my crude
explanation.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	PDS_BAD_THREAD_QP_64,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=no
	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 18E92C433DB
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 08:37:58 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id C45C623139
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 08:37:57 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1731489AbhASIhr (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 03:37:47 -0500
Received: from mail-eopbgr80081.outbound.protection.outlook.com ([40.107.8.81]:40674
        "EHLO EUR04-VI1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1729440AbhASIhW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 03:37:22 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k1Z/Z8DWuv9RsWkWOq28tZfVUVGuk0qY7bH4FNTgryI=;
 b=GEUxBKBx9QQyKjZLk7/jsXmZmdzyvq6uEDYTkCFSZTlf3MKUuYg/ueKU8nCepdVjaro95iNlXZZH8iggLrq7mtKnpS0lAcib+09G2uiPTo3kkvNYGQGfWZlG6VnBqydH13ffpm+ps2RZQt7qy+3e47Y6lUzisQ9cUxSzZO34Hfc=
Received: from AM0PR03CA0037.eurprd03.prod.outlook.com (2603:10a6:208::14) by
 VE1PR08MB4638.eurprd08.prod.outlook.com (2603:10a6:802:b1::16) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3763.11; Tue, 19 Jan 2021 08:36:31 +0000
Received: from AM5EUR03FT058.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:208:0:cafe::af) by AM0PR03CA0037.outlook.office365.com
 (2603:10a6:208::14) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend
 Transport; Tue, 19 Jan 2021 08:36:31 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; vger.kernel.org; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;vger.kernel.org; dmarc=pass action=none
 header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 AM5EUR03FT058.mail.protection.outlook.com (10.152.17.48) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3763.12 via Frontend Transport; Tue, 19 Jan 2021 08:36:30 +0000
Received: ("Tessian outbound 8418c949a3fa:v71"); Tue, 19 Jan 2021 08:36:30 +0000
X-CR-MTA-TID: 64aa7808
Received: from 332cb9da62ee.2
        by 64aa7808-outbound-1.mta.getcheckrecipient.com id E93C7A9A-A08B-4029-B885-0828580590ED.1;
        Tue, 19 Jan 2021 08:36:25 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com
    by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 332cb9da62ee.2
    (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
    Tue, 19 Jan 2021 08:36:25 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Mz9PFiTNa/1LTd5OjgIPvAF9l8k6zwpf5nuQAv8IE1MiOjN9NDIZR0OpmpOmr9qnR3lB/C9+7ARvEIuATr6uLe1YwS/WYxqgsoDkNRGl+F1n6R0rbumic47e2cpyYe3GeQyyjYlghDhxGY3rI4s+HVuCSczN1i4zV0Ee+kf5Nk65bfnVYVK8Hz00WyNX2mgLyTkyBjsJEBhzbPybZhxsWGxry8cdrRp3ej//TAc0mG7TWbnbojHm3i+rh5PUNu+mc/WWt20gKOcqx8iQi0Wtx9Yu1HkLN3OsUCLmfhL/TJeUEJFBMsRVtMJ/e2gPAMIurQNWb1gMVEOK2cQGXhqe/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k1Z/Z8DWuv9RsWkWOq28tZfVUVGuk0qY7bH4FNTgryI=;
 b=CdGQXPcYF31mYGpwJQOSiz+nRRQWYWY5hR3zIzStC2LbjafFYx//MHUPP6SGhaEulXdzNcny0N8HlxJjHtWfAE8DvcxWScF91+lQmKHllZrmRIKwvxYtTCxQxuZ5D+nRm4hinhizzSQ+sosmWmGf5/fyK2NGLj7krJlLUFj0Fz3CkvBLT4VSdHP67NMN70eB3nsxPH3YSbR7t+An7Wd7enqJidI1CWh5IBNkE+DffkfpkZ+vK63YqQHeQwfhtQOhN60vthYREbVbqozmI9M0H7TzwGYgVxlOjK2ZfcPkPVGEgJ78L1QgUK4hY2vY9BovVRZCUsUxc053B6OMZycqgg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=k1Z/Z8DWuv9RsWkWOq28tZfVUVGuk0qY7bH4FNTgryI=;
 b=GEUxBKBx9QQyKjZLk7/jsXmZmdzyvq6uEDYTkCFSZTlf3MKUuYg/ueKU8nCepdVjaro95iNlXZZH8iggLrq7mtKnpS0lAcib+09G2uiPTo3kkvNYGQGfWZlG6VnBqydH13ffpm+ps2RZQt7qy+3e47Y6lUzisQ9cUxSzZO34Hfc=
Received: from DB7PR08MB3355.eurprd08.prod.outlook.com (2603:10a6:5:18::18) by
 DB6PR08MB2662.eurprd08.prod.outlook.com (2603:10a6:6:24::30) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3763.14; Tue, 19 Jan 2021 08:36:22 +0000
Received: from DB7PR08MB3355.eurprd08.prod.outlook.com
 ([fe80::54aa:8448:7c5a:c39d]) by DB7PR08MB3355.eurprd08.prod.outlook.com
 ([fe80::54aa:8448:7c5a:c39d%7]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021
 08:36:22 +0000
From:   Al Grant <Al.Grant@arm.com>
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>
CC:     Suzuki Poulose <Suzuki.Poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>,
        "coresight@lists.linaro.org" <coresight@lists.linaro.org>,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "leo.yan@linaro.org" <leo.yan@linaro.org>,
        "mnissler@google.com" <mnissler@google.com>
Subject: RE: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Thread-Topic: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Thread-Index: AQHWovEvsWZ+JnYi7kC5fouEuMJbYqmY02mAgI/qOQCABawqAIAAlh2AgAAzA3A=
Date:   Tue, 19 Jan 2021 08:36:22 +0000
Message-ID: <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
In-Reply-To: <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ts-tracking-id: 310BCE6E07DBDA47ADB4C4FA5FF2DE09.0
x-checkrecipientchecked: true
Authentication-Results-Original: codeaurora.org; dkim=none (message not
 signed) header.d=none;codeaurora.org; dmarc=none action=none
 header.from=arm.com;
x-originating-ip: [81.148.244.174]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: b801f8ff-7cd2-496f-3196-08d8bc55521e
x-ms-traffictypediagnostic: DB6PR08MB2662:|VE1PR08MB4638:
x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <VE1PR08MB4638553EA635D43E84D577A486A30@VE1PR08MB4638.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: SRFonN8ST9KhisOiYj6wiq8nzkBUqkMaMvCnbmM801kHV9lEK0BNDjEbzIGr82vgqfTa8GX/WbfKg8l68lGttJtEt9a5K4rLPXxhlAMCYy1XG1x0VPaHHO8Ayry3WzBgpA4/3S3PIx8g2nqveV8rAMRNM3Zpw/+DWrKEr1MJ8xac8ATu8/FQdnykWa+ePKPtnDd5oGzeGzNxVE0LoYbHvJnrvKZ6l+0DnnZGaX40mzx2a7rFe6ngwUEzxH2ST6WOHW4Q/QkjbDMlVlRywpj3TpynL9NJ53lySKBEsyu9KxpAwnvCJRt+fTk71V/LIFNcQc+/nqpgt/j45pRdRtdL+1wTA5ei15lmcPhk0E7kEGmKKUMZ22FMIzhGQMZgWxftR613s9ZVv9f9cHgggqwyULyBY2EVWdvylOjPY0cnMPhh/dnPy0mvFgxIHttgHGgw
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB3355.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(39860400002)(346002)(376002)(396003)(136003)(366004)(7696005)(110136005)(8676002)(52536014)(53546011)(2906002)(5660300002)(83380400001)(6506007)(316002)(54906003)(71200400001)(86362001)(7416002)(76116006)(4001150100001)(66476007)(66946007)(66556008)(26005)(186003)(8936002)(478600001)(9686003)(4326008)(55016002)(66446008)(33656002)(64756008)(32563001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?bzC3vhNuWiIaw2+LoK+LC/SejdsOHQkWl4b5j8bBYGbihByKSk9/ZjCw9Uwj?=
 =?us-ascii?Q?WY0ZQY3uZ/pUy1p6+VpnyhS+Dsv2UNCrlVtP2ND9Ve49Ms1BeAKGvzkSJZmV?=
 =?us-ascii?Q?/uxR8Y9z8l3l7/rnTCKcQ5i3f81WQphzkIPazaBfjECu6GOyFJQqGpIg1Sg8?=
 =?us-ascii?Q?TtprFSEpM01a4iEGbUqbKHYadDrWWQojC0bthNpWrIL7P3mzXz8/IXT2Z5g1?=
 =?us-ascii?Q?FM6UOA4reIFg8B40AYnT5RcA0dWF3TLiFxscIIjAuwHHwyYU1rXHxQaM0ABw?=
 =?us-ascii?Q?t9OigOqXlS3pRAulB17ScT74Cuz6tEHYHWi8b8j3jeeCc4jDoGTf8svJxmro?=
 =?us-ascii?Q?/fXyaLIJNxrx9hWaeK+H09+w6Ytz2eaLkZG18BCxgWbuo0EIUPPp4imj1EdI?=
 =?us-ascii?Q?Fb2V2H5r4v7fPbFqV7kaMs2NS/arZ/EWe7JSBikPtWxjH+4r9i5fBdNKBYU1?=
 =?us-ascii?Q?W2GzA9WMEK9lUFXEfjtduGKciAAPnTqKgmDLqfg0/6fphkDEF6cIZLjNH+rH?=
 =?us-ascii?Q?p5OM4TBLfHiJP8ndxpOKkKwVxOKOpbbuhDPe/S8NihhloYhgXa6nFS6o4uJj?=
 =?us-ascii?Q?chA/qH3m9NGOwAntOMzIOAwvVACyo7YB0kqVIgbFGmcxPBP8xVnAXnGqLCck?=
 =?us-ascii?Q?KOe+5Z7TsxYVy0qxxHwMwHh2zqOs6owV3/pl3EMQ1f+UUPdDqGuihwnpeP6M?=
 =?us-ascii?Q?wtpCKMH7IyCsq6uJnXIZYmwmHHssCc7wg8E552QH9UbcmaA/74kKo4gnmNo0?=
 =?us-ascii?Q?OzwFxH8GIX6doxttDMwBBwYbFevNbiAjA9nSWol01anAymJ3R5HsEGwvZts7?=
 =?us-ascii?Q?hrsWeCDvPG/3fuqiJrNkLCLyRxmTqN202ELN1Nl5VSduRSv/u6mJsaXEZKdK?=
 =?us-ascii?Q?ErCAWXniFVIs192Z0M5v79Nktvb5p17JDlrK5A+tAC4YgAQCKu1YrNbSn1BP?=
 =?us-ascii?Q?n+5vkt1ukV/LHWKtHL3Rm7uzhJgX+zUFDJyXxkT1+0U=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2662
Original-Authentication-Results: codeaurora.org; dkim=none (message not signed)
 header.d=none;codeaurora.org; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT058.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 81e50597-b340-41bc-c7bd-08d8bc554d0b
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 9scBirjcWmy3CvekKjTxwAg6bosJuxQWLUyJaFPOuhCkBZ7YaXXiG5J32b1Zhs++dZdVGXFNNlOWikpeprGJkQr0Xxy8RaHJISOlELR+/b7k97ZjIzvD2rT4xhXMk/PntxRzAgRlpRzPTylu6pRQMA5BiQGlLNMBq7cYCLT0z/jYhm6OOYLwbo47F7tc7aVDDWKlcTklkOmAKJlAjbn9q1QDfxh4zeZL1320Hi1miJmCQ/55EV3QgAWGH5IThtB3csNOxgmt+LylBWhlEopVqzLhs6hhg5UbFYaNlunNlSFZZO8FDhXDXv7GXblx7WCGFI9FLnVnEuNtQ8QoBjoIXO01uSshac0VVp7d2KS1V2DmlE8EkXR77LvNvxnItOFsW9D2yel9whEyUhazwRsqAOdByI3iNFYXYD8VrVb/+bNqA7CL1+upWe7q1djHfGD1iv8NKGo+qTy3nE/Ew52fe5teeaBgWHNcV+lGjMtOcU4=
X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(4636009)(376002)(39850400004)(396003)(346002)(136003)(46966006)(33656002)(55016002)(5660300002)(70586007)(81166007)(70206006)(2906002)(356005)(6506007)(9686003)(52536014)(53546011)(8676002)(82740400003)(86362001)(7696005)(8936002)(4001150100001)(450100002)(54906003)(47076005)(336012)(186003)(4326008)(83380400001)(26005)(82310400003)(478600001)(316002)(107886003)(110136005)(32563001);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 08:36:30.8128
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b801f8ff-7cd2-496f-3196-08d8bc55521e
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT058.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB4638
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Sai,

> From: saiprakash.ranjan=3Dcodeaurora.org@mg.codeaurora.org
> Hi Mathieu,
>=20
> On 2021-01-19 01:53, Mathieu Poirier wrote:
> > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
> >> Hello Mathieu, Suzuki
> >>
> >> On 2020-10-15 21:32, Mathieu Poirier wrote:
> >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
> >> > > On production systems with ETMs enabled, it is preferred to
> >> > > exclude kernel mode(NS EL1) tracing for security concerns and
> >> > > support only userspace(NS EL0) tracing. So provide an option via
> >> > > kconfig to exclude kernel mode tracing if it is required.
> >> > > This config is disabled by default and would not affect the
> >> > > current configuration which has both kernel and userspace tracing
> >> > > enabled by default.
> >> > >
> >> >
> >> > One requires root access (or be part of a special trace group) to
> >> > be able to use the cs_etm PMU.  With this kind of elevated access
> >> > restricting tracing at EL1 provides little in terms of security.
> >> >
> >>
> >> Apart from the VM usecase discussed, I am told there are other
> >> security concerns here regarding need to exclude kernel mode tracing
> >> even for the privileged users/root. One such case being the ability
> >> to analyze cryptographic code execution since ETMs can record all
> >> branch instructions including timestamps in the kernel and there may
> >> be other cases as well which I may not be aware of and hence have
> >> added Denis and Mattias. Please let us know if you have any questions
> >> further regarding this not being a security concern.
> >
> > Even if we were to apply this patch there are many ways to compromise
> > a system or get the kernel to reveal important information using the
> > perf subsystem.  I would perfer to tackle the problem at that level
> > rather than concentrating on coresight.
> >
>=20
> Sorry but I did not understand your point. We are talking about the capab=
ilities
> of coresight etm tracing which has the instruction level tracing and a lo=
t more.
> Perf subsystem is just the framework used for it.
> In other words, its not the perf subsystem which does instruction level t=
racing,
> its the coresight etm. Why the perf subsystem should be modified to lockd=
own
> kernel mode? If we were to let perf handle all the trace filtering for di=
fferent
> exception levels, then why do we need the register settings in coresight =
etm
> driver to filter out NS EL* tracing? And more importantly, how do you sup=
pose
> we handle sysfs mode of coresight tracing with perf subsystem?

You both have good points. Mathieu is right that this is not a CoreSight
issue specifically, it is a matter of kernel security policy, and other har=
dware
tracing mechanisms ought to be within its scope. There should be a general
"anti kernel exfiltration" config that applies to all mechanisms within
its scope, and we'd definitely expect that to include Intel PT as well as E=
TM.

A kernel config that forced exclude_kernel on all perf events would deal wi=
th
ETM and PT in one place, but miss the sysfs interface to ETM.

On the other hand, doing it in the ETM drivers would cover the perf and sys=
fs
interfaces to ETM, but would miss Intel PT.

So I think what is needed is a general config option that is both implement=
ed
in perf (excluding all kernel tracing events) and by any drivers that provi=
de
an alternative interface to hardware tracing events.

Al


>=20
> Thanks,
> Sai
>=20
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no 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 041B3C433DB
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 08:41:29 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id D1F1E23121
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 08:41:28 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1731534AbhASIlF (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 03:41:05 -0500
Received: from a1.mail.mailgun.net ([198.61.254.60]:34877 "EHLO
        a1.mail.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1732835AbhASFWR (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 00:22:17 -0500
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1611033702; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=owAz9SChLf2AQ/0SsPcDtcQ+DGoWx6RjBqzLaNzFg1M=;
 b=iBa/+hXoa7E94qtbbKDHYPBUsEiamcJTgP7XEh0e3zbs+L6C7uWJkod2s4y9MP/50/0AhHIW
 JmBBvwjd615BOcfhAEJgj5Ubg+WgINCj+NQh18tNI2eB6KY06WsPpSNgShwmlJ7cGnTBg+aL
 LbeU4hilQ8EvrT0TLgDVeap0doE=
X-Mailgun-Sending-Ip: 198.61.254.60
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n01.prod.us-east-1.postgun.com with SMTP id
 60066c49ba7f868506ea07ba (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 19 Jan 2021 05:21:13
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 602E9C43463; Tue, 19 Jan 2021 05:21:12 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id C3A71C433ED;
        Tue, 19 Jan 2021 05:21:11 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Tue, 19 Jan 2021 10:51:11 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Mathieu Poirier <mathieu.poirier@linaro.org>
Cc:     Suzuki K Poulose <suzuki.poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, Al Grant <al.grant@arm.com>,
        leo.yan@linaro.org, mnissler@google.com
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <20210118202354.GC464579@xps15>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
Message-ID: <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Mathieu,

On 2021-01-19 01:53, Mathieu Poirier wrote:
> On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
>> Hello Mathieu, Suzuki
>> 
>> On 2020-10-15 21:32, Mathieu Poirier wrote:
>> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>> > > On production systems with ETMs enabled, it is preferred to
>> > > exclude kernel mode(NS EL1) tracing for security concerns and
>> > > support only userspace(NS EL0) tracing. So provide an option
>> > > via kconfig to exclude kernel mode tracing if it is required.
>> > > This config is disabled by default and would not affect the
>> > > current configuration which has both kernel and userspace
>> > > tracing enabled by default.
>> > >
>> >
>> > One requires root access (or be part of a special trace group) to be
>> > able to use
>> > the cs_etm PMU.  With this kind of elevated access restricting tracing
>> > at EL1
>> > provides little in terms of security.
>> >
>> 
>> Apart from the VM usecase discussed, I am told there are other
>> security concerns here regarding need to exclude kernel mode tracing
>> even for the privileged users/root. One such case being the ability
>> to analyze cryptographic code execution since ETMs can record all
>> branch instructions including timestamps in the kernel and there may
>> be other cases as well which I may not be aware of and hence have
>> added Denis and Mattias. Please let us know if you have any questions
>> further regarding this not being a security concern.
> 
> Even if we were to apply this patch there are many ways to compromise a 
> system
> or get the kernel to reveal important information using the perf 
> subsystem.  I
> would perfer to tackle the problem at that level rather than 
> concentrating on
> coresight.
> 

Sorry but I did not understand your point. We are talking about the
capabilities of coresight etm tracing which has the instruction level
tracing and a lot more. Perf subsystem is just the framework used for 
it.
In other words, its not the perf subsystem which does instruction level
tracing, its the coresight etm. Why the perf subsystem should be
modified to lockdown kernel mode? If we were to let perf handle all the
trace filtering for different exception levels, then why do we need
the register settings in coresight etm driver to filter out NS EL*
tracing? And more importantly, how do you suppose we handle sysfs mode
of coresight tracing with perf subsystem?

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no 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 98031C433E0
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 10:13:44 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 4C03523110
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 10:13:44 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2389444AbhASKEe (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 05:04:34 -0500
Received: from a1.mail.mailgun.net ([198.61.254.60]:58703 "EHLO
        a1.mail.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2389152AbhASJwM (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 04:52:12 -0500
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1611049915; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=IqeHm+djSYXGS6nhOsGbWQeydkemPXwx6MDMvUpsZlU=;
 b=T2Y75fKzi8Ypj6JPA+r4oowR5uZXn+00rxMJueFPk0/6zvOKlFmDnArLa0FN7jgawOOzUnxa
 2kLfgMokC7ZxZj9C/oCD3OYbH+ZAdkYO2s7AhV0ErjBWgIL1wb34WiCmdn1ceyMAafGdBzSU
 SROsoZng/kOXJaFw0ws53PXtKcY=
X-Mailgun-Sending-Ip: 198.61.254.60
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n06.prod.us-west-2.postgun.com with SMTP id
 6006ab9721210999ed6440bb (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 19 Jan 2021 09:51:19
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id E0DACC433C6; Tue, 19 Jan 2021 09:51:18 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id C7113C433CA;
        Tue, 19 Jan 2021 09:51:17 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Tue, 19 Jan 2021 15:21:17 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Al Grant <Al.Grant@arm.com>
Cc:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Suzuki Poulose <Suzuki.Poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, leo.yan@linaro.org,
        mnissler@google.com
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
Message-ID: <03b893801841f732a25072b4e62f8e0b@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Al,

On 2021-01-19 14:06, Al Grant wrote:
> Hi Sai,
> 
>> From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
>> Hi Mathieu,
>> 
>> On 2021-01-19 01:53, Mathieu Poirier wrote:
>> > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
>> >> Hello Mathieu, Suzuki
>> >>
>> >> On 2020-10-15 21:32, Mathieu Poirier wrote:
>> >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>> >> > > On production systems with ETMs enabled, it is preferred to
>> >> > > exclude kernel mode(NS EL1) tracing for security concerns and
>> >> > > support only userspace(NS EL0) tracing. So provide an option via
>> >> > > kconfig to exclude kernel mode tracing if it is required.
>> >> > > This config is disabled by default and would not affect the
>> >> > > current configuration which has both kernel and userspace tracing
>> >> > > enabled by default.
>> >> > >
>> >> >
>> >> > One requires root access (or be part of a special trace group) to
>> >> > be able to use the cs_etm PMU.  With this kind of elevated access
>> >> > restricting tracing at EL1 provides little in terms of security.
>> >> >
>> >>
>> >> Apart from the VM usecase discussed, I am told there are other
>> >> security concerns here regarding need to exclude kernel mode tracing
>> >> even for the privileged users/root. One such case being the ability
>> >> to analyze cryptographic code execution since ETMs can record all
>> >> branch instructions including timestamps in the kernel and there may
>> >> be other cases as well which I may not be aware of and hence have
>> >> added Denis and Mattias. Please let us know if you have any questions
>> >> further regarding this not being a security concern.
>> >
>> > Even if we were to apply this patch there are many ways to compromise
>> > a system or get the kernel to reveal important information using the
>> > perf subsystem.  I would perfer to tackle the problem at that level
>> > rather than concentrating on coresight.
>> >
>> 
>> Sorry but I did not understand your point. We are talking about the 
>> capabilities
>> of coresight etm tracing which has the instruction level tracing and a 
>> lot more.
>> Perf subsystem is just the framework used for it.
>> In other words, its not the perf subsystem which does instruction 
>> level tracing,
>> its the coresight etm. Why the perf subsystem should be modified to 
>> lockdown
>> kernel mode? If we were to let perf handle all the trace filtering for 
>> different
>> exception levels, then why do we need the register settings in 
>> coresight etm
>> driver to filter out NS EL* tracing? And more importantly, how do you 
>> suppose
>> we handle sysfs mode of coresight tracing with perf subsystem?
> 
> You both have good points. Mathieu is right that this is not a 
> CoreSight
> issue specifically, it is a matter of kernel security policy, and other 
> hardware
> tracing mechanisms ought to be within its scope. There should be a 
> general
> "anti kernel exfiltration" config that applies to all mechanisms within
> its scope, and we'd definitely expect that to include Intel PT as well 
> as ETM.
> 

I agree with this part where there should be a generic config for all
hardware tracing families(atleast for Intel PT and ARM Coresight),
Suzuki suggested that as well. I am under the impression that Mathieu
didn't like adding such a config and wanted perf subsystem to handle
it since initial discussion was around whether root compromise meant
everything is lost already and such a kconfig would not help, but
Mattias already gave some good examples where that is not true.

> A kernel config that forced exclude_kernel on all perf events would 
> deal with
> ETM and PT in one place, but miss the sysfs interface to ETM.
> 
> On the other hand, doing it in the ETM drivers would cover the perf and 
> sysfs
> interfaces to ETM, but would miss Intel PT.
> 
> So I think what is needed is a general config option that is both 
> implemented
> in perf (excluding all kernel tracing events) and by any drivers that 
> provide
> an alternative interface to hardware tracing events.
> 

I am good with this approach, once Mathieu confirms, I can add a kernel
wide kconfig as Suzuki suggested earlier and make ETM{3,4}x as the
initial users. Someone more familiar with Intel PTs can then make use
of this kconfig.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-5.3 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,
	SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 96461C43331
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 10:49:47 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 58F0023133
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 10:49:47 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2404474AbhASKmq (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 05:42:46 -0500
Received: from foss.arm.com ([217.140.110.172]:49554 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2404298AbhASKet (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 05:34:49 -0500
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
        by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3F3381042;
        Tue, 19 Jan 2021 02:34:03 -0800 (PST)
Received: from [10.57.40.145] (unknown [10.57.40.145])
        by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F05033F66E;
        Tue, 19 Jan 2021 02:33:59 -0800 (PST)
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
To:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        Al Grant <Al.Grant@arm.com>
Cc:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, leo.yan@linaro.org,
        mnissler@google.com, Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
 <03b893801841f732a25072b4e62f8e0b@codeaurora.org>
From:   Suzuki K Poulose <suzuki.poulose@arm.com>
Message-ID: <de2487eb-ddb9-589a-8093-fae31235c884@arm.com>
Date:   Tue, 19 Jan 2021 10:33:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <03b893801841f732a25072b4e62f8e0b@codeaurora.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/19/21 9:51 AM, Sai Prakash Ranjan wrote:
> Hi Al,
> 
> On 2021-01-19 14:06, Al Grant wrote:
>> Hi Sai,
>>
>>> From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
>>> Hi Mathieu,
>>>
>>> On 2021-01-19 01:53, Mathieu Poirier wrote:
>>> > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
>>> >> Hello Mathieu, Suzuki
>>> >>
>>> >> On 2020-10-15 21:32, Mathieu Poirier wrote:
>>> >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>>> >> > > On production systems with ETMs enabled, it is preferred to
>>> >> > > exclude kernel mode(NS EL1) tracing for security concerns and
>>> >> > > support only userspace(NS EL0) tracing. So provide an option via
>>> >> > > kconfig to exclude kernel mode tracing if it is required.
>>> >> > > This config is disabled by default and would not affect the
>>> >> > > current configuration which has both kernel and userspace tracing
>>> >> > > enabled by default.
>>> >> > >
>>> >> >
>>> >> > One requires root access (or be part of a special trace group) to
>>> >> > be able to use the cs_etm PMU.  With this kind of elevated access
>>> >> > restricting tracing at EL1 provides little in terms of security.
>>> >> >
>>> >>
>>> >> Apart from the VM usecase discussed, I am told there are other
>>> >> security concerns here regarding need to exclude kernel mode tracing
>>> >> even for the privileged users/root. One such case being the ability
>>> >> to analyze cryptographic code execution since ETMs can record all
>>> >> branch instructions including timestamps in the kernel and there may
>>> >> be other cases as well which I may not be aware of and hence have
>>> >> added Denis and Mattias. Please let us know if you have any questions
>>> >> further regarding this not being a security concern.
>>> >
>>> > Even if we were to apply this patch there are many ways to compromise
>>> > a system or get the kernel to reveal important information using the
>>> > perf subsystem.  I would perfer to tackle the problem at that level
>>> > rather than concentrating on coresight.
>>> >
>>>
>>> Sorry but I did not understand your point. We are talking about the capabilities
>>> of coresight etm tracing which has the instruction level tracing and a lot more.
>>> Perf subsystem is just the framework used for it.
>>> In other words, its not the perf subsystem which does instruction level tracing,
>>> its the coresight etm. Why the perf subsystem should be modified to lockdown
>>> kernel mode? If we were to let perf handle all the trace filtering for different
>>> exception levels, then why do we need the register settings in coresight etm
>>> driver to filter out NS EL* tracing? And more importantly, how do you suppose
>>> we handle sysfs mode of coresight tracing with perf subsystem?
>>
>> You both have good points. Mathieu is right that this is not a CoreSight
>> issue specifically, it is a matter of kernel security policy, and other hardware
>> tracing mechanisms ought to be within its scope. There should be a general
>> "anti kernel exfiltration" config that applies to all mechanisms within
>> its scope, and we'd definitely expect that to include Intel PT as well as ETM.
>>
> 
> I agree with this part where there should be a generic config for all
> hardware tracing families(atleast for Intel PT and ARM Coresight),
> Suzuki suggested that as well. I am under the impression that Mathieu
> didn't like adding such a config and wanted perf subsystem to handle
> it since initial discussion was around whether root compromise meant
> everything is lost already and such a kconfig would not help, but
> Mattias already gave some good examples where that is not true.
> 
>> A kernel config that forced exclude_kernel on all perf events would deal with
>> ETM and PT in one place, but miss the sysfs interface to ETM.
>>
>> On the other hand, doing it in the ETM drivers would cover the perf and sysfs
>> interfaces to ETM, but would miss Intel PT.
>>
>> So I think what is needed is a general config option that is both implemented
>> in perf (excluding all kernel tracing events) and by any drivers that provide
>> an alternative interface to hardware tracing events.
>>
> 
> I am good with this approach, once Mathieu confirms, I can add a kernel
> wide kconfig as Suzuki suggested earlier and make ETM{3,4}x as the
> initial users. Someone more familiar with Intel PTs can then make use
> of this kconfig.

Instead of adding the support for individual drivers, you could handle this
in the generic perf layer. e.g, Fail perf_event create with an attribute
which allows kernel tracing ?

if (!attr.exclude_kernel)
	return -EINVAL;

Or even exclude the kernel silently always.

This could also be limited to PMUs with PERF_PMU_CAP_ITRACE, if you
want to limit this to PMUs that instruction level tracing.

Suzuki

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,UNPARSEABLE_RELAY autolearn=no 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 862ECC43381
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 12:07:21 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 46B1720754
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 12:07:21 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2392361AbhASMEx (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 07:04:53 -0500
Received: from mail-eopbgr20058.outbound.protection.outlook.com ([40.107.2.58]:12454
        "EHLO EUR02-VE1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S2392017AbhASL5r (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 06:57:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZSWIleQwnhCEZ2p/PoXOyZkuXedHPu91kO19dkAz6G0=;
 b=Qdntlk3n2KEFYq3Be6YsUXJE516sYMsYvqRVQ0WkVbiQmXZp1UYhQ+MXgAnbC2bK5Lb9n0srG1UcQr+H+vYP7FD0/7HJwNnyutCrGAinMFYfbjR53uquPg9VByEwY1jXRIJPSwVS47UWgsmmG1R/Wmh98i/Cn/2UpRmfWa0RA64=
Received: from AM5P194CA0017.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::27)
 by PR3PR08MB5739.eurprd08.prod.outlook.com (2603:10a6:102:8e::8) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Tue, 19 Jan
 2021 11:56:55 +0000
Received: from VE1EUR03FT021.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:203:8f:cafe::a3) by AM5P194CA0017.outlook.office365.com
 (2603:10a6:203:8f::27) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9 via Frontend
 Transport; Tue, 19 Jan 2021 11:56:55 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123)
 smtp.mailfrom=arm.com; vger.kernel.org; dkim=pass (signature was verified)
 header.d=armh.onmicrosoft.com;vger.kernel.org; dmarc=pass action=none
 header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by
 VE1EUR03FT021.mail.protection.outlook.com (10.152.18.117) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3763.12 via Frontend Transport; Tue, 19 Jan 2021 11:56:55 +0000
Received: ("Tessian outbound f362b81824dc:v71"); Tue, 19 Jan 2021 11:56:54 +0000
X-CR-MTA-TID: 64aa7808
Received: from a665fd549df4.1
        by 64aa7808-outbound-1.mta.getcheckrecipient.com id 76081B28-AADF-49A9-8096-44D2B2FFA83E.1;
        Tue, 19 Jan 2021 11:56:49 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com
    by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a665fd549df4.1
    (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384);
    Tue, 19 Jan 2021 11:56:49 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=ZEBtdw5SnjrQSj/iQzKYxAZ+bf1wL8XNH4pJPbzJfrNp9GGGrXpne9EvQyWFZ/m83Ab8DUn3xhTr/t0aFyCpysukW7CUah2RBvBBEgghykqM9+d6ONAqVBvowLj6GlwTekkGdzs/puGfMa7iTr9J9hkAIWyBemi1YJPseF6/z24W9QDdthFriqVTffA7Z2MHdSFIxsFBhRA85bP01kWbkW1WuhRcYF2SRGRg3uUm+bOtNvP8hR2IqBYG2sV5UCz6bbEceo5TPAajRu4tgjTUxo10To0xLQQsxPi4duuZWRgPbRoqFi7pa9xMxKTf9NPbLUrgxIvNzZxQFFLOhU8QAA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZSWIleQwnhCEZ2p/PoXOyZkuXedHPu91kO19dkAz6G0=;
 b=a3sUABSVu84DDW/6XlnkSd1wI3nVw87CalTKMohIXp+KjV2vbeCVGl8DiAkVpSx8Dn25kWOEI4DqC/bADJNMlsXRMRBmxY0BcwMP+ZlDIwuGgB6Y+K2P1s8ocfTGMvgUGeqDshyl4wkCPjPvNYssnR/VJwvNXxIS69W/POJhMCXRgxmRlh6t8Q/a6gK+CVODI/QXzXhLRlxpk3swLpFXZ3sSGtzUkrROLxGot9DdiHBBlrCO84+DugSTs6BwAl63owsziD4UrP2DlZv+EzHJO9GfKvHP6eJ+tImS49WBXf+aQYkSTgIRyQxwMYf3D9xvTWx3sXaBM/w6KrwvjbomXA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
 header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com;
 s=selector2-armh-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=ZSWIleQwnhCEZ2p/PoXOyZkuXedHPu91kO19dkAz6G0=;
 b=Qdntlk3n2KEFYq3Be6YsUXJE516sYMsYvqRVQ0WkVbiQmXZp1UYhQ+MXgAnbC2bK5Lb9n0srG1UcQr+H+vYP7FD0/7HJwNnyutCrGAinMFYfbjR53uquPg9VByEwY1jXRIJPSwVS47UWgsmmG1R/Wmh98i/Cn/2UpRmfWa0RA64=
Received: from DB7PR08MB3355.eurprd08.prod.outlook.com (2603:10a6:5:18::18) by
 DB8PR08MB5516.eurprd08.prod.outlook.com (2603:10a6:10:f9::11) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.3784.11; Tue, 19 Jan 2021 11:56:45 +0000
Received: from DB7PR08MB3355.eurprd08.prod.outlook.com
 ([fe80::54aa:8448:7c5a:c39d]) by DB7PR08MB3355.eurprd08.prod.outlook.com
 ([fe80::54aa:8448:7c5a:c39d%7]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021
 11:56:45 +0000
From:   Al Grant <Al.Grant@arm.com>
To:     Suzuki Poulose <Suzuki.Poulose@arm.com>,
        Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
CC:     Mathieu Poirier <mathieu.poirier@linaro.org>,
        Mike Leach <mike.leach@linaro.org>,
        "coresight@lists.linaro.org" <coresight@lists.linaro.org>,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "leo.yan@linaro.org" <leo.yan@linaro.org>,
        "mnissler@google.com" <mnissler@google.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Mark Rutland <Mark.Rutland@arm.com>
Subject: RE: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Thread-Topic: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Thread-Index: AQHWovEvsWZ+JnYi7kC5fouEuMJbYqmY02mAgI/qOQCABawqAIAAlh2AgAAzA3CAABh0gIAAC+YAgAAK/1A=
Date:   Tue, 19 Jan 2021 11:56:44 +0000
Message-ID: <DB7PR08MB3355472BF00A47087E0130CA86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
 <03b893801841f732a25072b4e62f8e0b@codeaurora.org>
 <de2487eb-ddb9-589a-8093-fae31235c884@arm.com>
In-Reply-To: <de2487eb-ddb9-589a-8093-fae31235c884@arm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ts-tracking-id: DC46597AA52C484E8A485E6204D0CA74.0
x-checkrecipientchecked: true
Authentication-Results-Original: arm.com; dkim=none (message not signed)
 header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [81.148.244.174]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: ac267e80-5d4f-40be-ab8d-08d8bc715147
x-ms-traffictypediagnostic: DB8PR08MB5516:|PR3PR08MB5739:
x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <PR3PR08MB5739272332A44C2B722FBE0D86A30@PR3PR08MB5739.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:538;OLM:538;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: KNlrvIjHPGz1jPK/d75asmsdGrvkmSw/credFEVhatWJIWmm/jgUSUIG36nJPWDkzbJi5+i/PM8xKSD5+4US8A5gjz8WtjzWDmUvmAJFvBDdFkJuJgAoa4iG8nnfX7W7EVjsK16X8Ng0fTMv5rN4izunuTN/O70eRY5VtLqA4BFNJH3xR3Qagb8pmwmXK19wu4XhqB77gB66+Y99CZhH0gs6heA5HY/eJgMIP+PWA3+Z+iLhmmg+an+UnJobrW0FSq15clq4r/0T4NNZiA7us0J7wwptZ+4wPxYn9ngpCNAdNLZBeP3WV8gOP5UpBQ8Xwg6rxoj/Cbs2KL6mh0nVR9CFO3Kv7ZYur6y5sPyCI/0Enr/+nZyLA3ErXgB00AXdjpCUmOMXpSuFsJscTwF7se21uGYLoBTu1DmajBFLuOIDPLDdORJcrwbcVCfkfbUi
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DB7PR08MB3355.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(9686003)(66446008)(4001150100001)(76116006)(64756008)(186003)(66556008)(55016002)(66946007)(83380400001)(66476007)(26005)(8936002)(53546011)(33656002)(86362001)(6506007)(7696005)(316002)(110136005)(2906002)(4326008)(8676002)(71200400001)(52536014)(7416002)(478600001)(54906003)(5660300002)(32563001);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MllPRGlKaGkrOVFteEVEaHlibUdERHJjbHN5Vjh5V3NNcjFMZXhISUV6OUti?=
 =?utf-8?B?MXBPeFlqZUVRSWJNRTdYQytGKy9JN0pBempHbkM0b3U4aXVWbmdIK0NNNERI?=
 =?utf-8?B?NUVwRHI0aTRxUDJCcit4dkV0czgzWERnYUROaEN2Mk8rdEowYXRzUjBoMzNh?=
 =?utf-8?B?aWhlMVJjelJ4TlFjNXcyUFhMd05sVmwrL29OQjVxMHpDcFNJdUhlZlBQc2ZJ?=
 =?utf-8?B?RUJuWVJTN2thYmEyNHhSbEtGTkVoQUpZdk0ySzc4S2xDK1BDSU1sU042ZDR1?=
 =?utf-8?B?TzJVN2tIdUxVY1B3T00xZUtVcUxQeldNby9FeUEvaXlFM1RJOFBIejRmdUVI?=
 =?utf-8?B?OUg4cnlIQ0tMdUhWbzNUZ1ZOK0k4QldUVVNzTStEM1pWRFBGV3kvaHN0Ukto?=
 =?utf-8?B?R2NoOEtUa2NQcDlDcCtETmdhQzVuZldtaXl2YVZBOG9hM3Q1ZUxmODA4Uml5?=
 =?utf-8?B?SlRiVEs4ZmcreS9LT1lkMjN4Q3JRZGtsVldLTjRyY2lYeUpOMlBKZWVCSmdi?=
 =?utf-8?B?TkZoVzFOZHZEVE01L05jZi94MStMVUtIWU1XbG5BVTZ3N2owcU1DdmJldFQw?=
 =?utf-8?B?Vko1MHdtL0cvM3MvYU5SaHZReFB0RWxwTlorUDlZcnJaY2dYemJHSENsTmsr?=
 =?utf-8?B?bE80MkplNmk0ZWxQTEtvcXd2SXVGOE9TR0hndlR0MkMveWxMZ0lvZEVEekNz?=
 =?utf-8?B?UFZ2eVFtN3hFTUNMeGVOQmJ6Q04zM0krdi9hdDBLc0FrN0JPY3NxYldCQW5J?=
 =?utf-8?B?NnpzYjBGMzBzVTVsNGNlMzF0Z21kRmxjL3BhcTBFYXVXUmdOQ09qSCtBcmxr?=
 =?utf-8?B?dEpQVDJDZ3BtaGRlTXZzQlBSUHZ1WkdEbkYrRmMzVXo1N3lMYlBmSmJZYlhW?=
 =?utf-8?B?MjFvZFBtWk1jLy9VZWN0SzhSTEd2U25IUG0zcmxJYk8zVDkrNFd3bHVwVDd1?=
 =?utf-8?B?a1o4UXJPK3FFZWdxd1N2M1ptWE11bWY5VWRVZHFTcEdTWWFZa0hEdlJKbEFt?=
 =?utf-8?B?Sy93YnBJZ1QremFLR0ROVGJnZjFXb0R3SmtvRG1hb1QrWFBKWURqTjhNejM2?=
 =?utf-8?B?ektUNjFROVBxM0xLK2I1NExJSXVQQm1BUnhzNmthNmxOczRDRmlHZEg2dExu?=
 =?utf-8?B?VU4xWUhCZWM1R0FLSlI0aG1nVVR6bkhDMEJlMnF6QjdsczVjWUtBcW16QTQy?=
 =?utf-8?B?YWJuaXdoWHlIcWpuZHU4czNDUFdGRlBVQnVxVDQ5NUZVVkI4Q20zNzQ4RUZW?=
 =?utf-8?B?OTVFSk1HMmlvakRHeFdQSHVwQ3BiTkprM1F2ZnEzdTNSYmhVNEFWSURXMVZj?=
 =?utf-8?Q?PzRByIYGKUijg=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5516
Original-Authentication-Results: arm.com; dkim=none (message not signed)
 header.d=none;arm.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT021.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 13ad1983-1177-4892-9445-08d8bc714b33
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: VVJ5ufgGbc7Os7wEiqDiO+Daom2hXpMBrNNnUcd8SDXD1v0Q6LWjxHZQcN0N79bpvzrSsGqLVa+8YSlx6BZ8qzusR8ozywm8NSWYjbxDY8V9kApNa+Lm9LR/5Py8lOQVLBqxT905ErkIcj0/zPutcpnUls2KEKnKL5MJzZaL/7tfoR4NknSc6DdbdZUYlGYVR2PwfaSFl6kmjkqGFTvDOmOQ00QPLYzSLzr9UmuZUI339/2mbCRB6rtzuS5smEtsyI8/YobkgupWuxChbvuxiiq3nU6zyld9tyWjK/yUVBeDkjNY2zoPfJrRFFSE508++EE4/gEPWMdy5s3wKG1OMnhl4O4R9XpN2uuVHf0iA6CA5lZXRLeBxDbpDK6OUmcys0PQ/WyTH+A3ttbwcPwli0ZYn102lrrRe4IWXRkHaTcAClMh6TbnZOt013/B9VFntgsJXJvjoJ7OZuooeVOqV+RajJiq8Hk5DhHSonPD8EE=
X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(4636009)(376002)(39860400002)(346002)(136003)(396003)(46966006)(2906002)(82740400003)(8676002)(7696005)(82310400003)(70586007)(55016002)(54906003)(53546011)(4326008)(316002)(6506007)(186003)(47076005)(33656002)(26005)(110136005)(9686003)(5660300002)(356005)(70206006)(450100002)(4001150100001)(52536014)(336012)(478600001)(81166007)(8936002)(86362001)(83380400001)(32563001);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 11:56:55.2053
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ac267e80-5d4f-40be-ab8d-08d8bc715147
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT021.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR08MB5739
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

PiBGcm9tOiBTdXp1a2kgSyBQb3Vsb3NlIDxzdXp1a2kucG91bG9zZUBhcm0uY29tPg0KPiBPbiAx
LzE5LzIxIDk6NTEgQU0sIFNhaSBQcmFrYXNoIFJhbmphbiB3cm90ZToNCj4gPiBIaSBBbCwNCj4g
Pg0KPiA+IE9uIDIwMjEtMDEtMTkgMTQ6MDYsIEFsIEdyYW50IHdyb3RlOg0KPiA+PiBIaSBTYWks
DQo+ID4+DQo+ID4+PiBGcm9tOiBzYWlwcmFrYXNoLnJhbmphbj1jb2RlYXVyb3JhLm9yZ0BtZy5j
b2RlYXVyb3JhLm9yZw0KPiA+Pj4gSGkgTWF0aGlldSwNCj4gPj4+DQo+ID4+PiBPbiAyMDIxLTAx
LTE5IDAxOjUzLCBNYXRoaWV1IFBvaXJpZXIgd3JvdGU6DQo+ID4+PiA+IE9uIEZyaSwgSmFuIDE1
LCAyMDIxIGF0IDExOjE2OjI0QU0gKzA1MzAsIFNhaSBQcmFrYXNoIFJhbmphbiB3cm90ZToNCj4g
Pj4+ID4+IEhlbGxvIE1hdGhpZXUsIFN1enVraQ0KPiA+Pj4gPj4NCj4gPj4+ID4+IE9uIDIwMjAt
MTAtMTUgMjE6MzIsIE1hdGhpZXUgUG9pcmllciB3cm90ZToNCj4gPj4+ID4+ID4gT24gVGh1LCBP
Y3QgMTUsIDIwMjAgYXQgMDY6MTU6MjJQTSArMDUzMCwgU2FpIFByYWthc2ggUmFuamFuIHdyb3Rl
Og0KPiA+Pj4gPj4gPiA+IE9uIHByb2R1Y3Rpb24gc3lzdGVtcyB3aXRoIEVUTXMgZW5hYmxlZCwg
aXQgaXMgcHJlZmVycmVkIHRvDQo+ID4+PiA+PiA+ID4gZXhjbHVkZSBrZXJuZWwgbW9kZShOUyBF
TDEpIHRyYWNpbmcgZm9yIHNlY3VyaXR5IGNvbmNlcm5zIGFuZA0KPiA+Pj4gPj4gPiA+IHN1cHBv
cnQgb25seSB1c2Vyc3BhY2UoTlMgRUwwKSB0cmFjaW5nLiBTbyBwcm92aWRlIGFuIG9wdGlvbg0K
PiA+Pj4gPj4gPiA+IHZpYSBrY29uZmlnIHRvIGV4Y2x1ZGUga2VybmVsIG1vZGUgdHJhY2luZyBp
ZiBpdCBpcyByZXF1aXJlZC4NCj4gPj4+ID4+ID4gPiBUaGlzIGNvbmZpZyBpcyBkaXNhYmxlZCBi
eSBkZWZhdWx0IGFuZCB3b3VsZCBub3QgYWZmZWN0IHRoZQ0KPiA+Pj4gPj4gPiA+IGN1cnJlbnQg
Y29uZmlndXJhdGlvbiB3aGljaCBoYXMgYm90aCBrZXJuZWwgYW5kIHVzZXJzcGFjZQ0KPiA+Pj4g
Pj4gPiA+IHRyYWNpbmcgZW5hYmxlZCBieSBkZWZhdWx0Lg0KPiA+Pj4gPj4gPiA+DQo+ID4+PiA+
PiA+DQo+ID4+PiA+PiA+IE9uZSByZXF1aXJlcyByb290IGFjY2VzcyAob3IgYmUgcGFydCBvZiBh
IHNwZWNpYWwgdHJhY2UgZ3JvdXApDQo+ID4+PiA+PiA+IHRvIGJlIGFibGUgdG8gdXNlIHRoZSBj
c19ldG0gUE1VLsKgIFdpdGggdGhpcyBraW5kIG9mIGVsZXZhdGVkDQo+ID4+PiA+PiA+IGFjY2Vz
cyByZXN0cmljdGluZyB0cmFjaW5nIGF0IEVMMSBwcm92aWRlcyBsaXR0bGUgaW4gdGVybXMgb2Yg
c2VjdXJpdHkuDQo+ID4+PiA+PiA+DQo+ID4+PiA+Pg0KPiA+Pj4gPj4gQXBhcnQgZnJvbSB0aGUg
Vk0gdXNlY2FzZSBkaXNjdXNzZWQsIEkgYW0gdG9sZCB0aGVyZSBhcmUgb3RoZXINCj4gPj4+ID4+
IHNlY3VyaXR5IGNvbmNlcm5zIGhlcmUgcmVnYXJkaW5nIG5lZWQgdG8gZXhjbHVkZSBrZXJuZWwg
bW9kZQ0KPiA+Pj4gPj4gdHJhY2luZyBldmVuIGZvciB0aGUgcHJpdmlsZWdlZCB1c2Vycy9yb290
LiBPbmUgc3VjaCBjYXNlIGJlaW5nDQo+ID4+PiA+PiB0aGUgYWJpbGl0eSB0byBhbmFseXplIGNy
eXB0b2dyYXBoaWMgY29kZSBleGVjdXRpb24gc2luY2UgRVRNcw0KPiA+Pj4gPj4gY2FuIHJlY29y
ZCBhbGwgYnJhbmNoIGluc3RydWN0aW9ucyBpbmNsdWRpbmcgdGltZXN0YW1wcyBpbiB0aGUNCj4g
Pj4+ID4+IGtlcm5lbCBhbmQgdGhlcmUgbWF5IGJlIG90aGVyIGNhc2VzIGFzIHdlbGwgd2hpY2gg
SSBtYXkgbm90IGJlDQo+ID4+PiA+PiBhd2FyZSBvZiBhbmQgaGVuY2UgaGF2ZSBhZGRlZCBEZW5p
cyBhbmQgTWF0dGlhcy4gUGxlYXNlIGxldCB1cw0KPiA+Pj4gPj4ga25vdyBpZiB5b3UgaGF2ZSBh
bnkgcXVlc3Rpb25zIGZ1cnRoZXIgcmVnYXJkaW5nIHRoaXMgbm90IGJlaW5nIGEgc2VjdXJpdHkN
Cj4gY29uY2Vybi4NCj4gPj4+ID4NCj4gPj4+ID4gRXZlbiBpZiB3ZSB3ZXJlIHRvIGFwcGx5IHRo
aXMgcGF0Y2ggdGhlcmUgYXJlIG1hbnkgd2F5cyB0bw0KPiA+Pj4gPiBjb21wcm9taXNlIGEgc3lz
dGVtIG9yIGdldCB0aGUga2VybmVsIHRvIHJldmVhbCBpbXBvcnRhbnQNCj4gPj4+ID4gaW5mb3Jt
YXRpb24gdXNpbmcgdGhlIHBlcmYgc3Vic3lzdGVtLsKgIEkgd291bGQgcGVyZmVyIHRvIHRhY2ts
ZQ0KPiA+Pj4gPiB0aGUgcHJvYmxlbSBhdCB0aGF0IGxldmVsIHJhdGhlciB0aGFuIGNvbmNlbnRy
YXRpbmcgb24gY29yZXNpZ2h0Lg0KPiA+Pj4gPg0KPiA+Pj4NCj4gPj4+IFNvcnJ5IGJ1dCBJIGRp
ZCBub3QgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBXZSBhcmUgdGFsa2luZyBhYm91dCB0aGUNCj4g
Pj4+IGNhcGFiaWxpdGllcyBvZiBjb3Jlc2lnaHQgZXRtIHRyYWNpbmcgd2hpY2ggaGFzIHRoZSBp
bnN0cnVjdGlvbiBsZXZlbCB0cmFjaW5nDQo+IGFuZCBhIGxvdCBtb3JlLg0KPiA+Pj4gUGVyZiBz
dWJzeXN0ZW0gaXMganVzdCB0aGUgZnJhbWV3b3JrIHVzZWQgZm9yIGl0Lg0KPiA+Pj4gSW4gb3Ro
ZXIgd29yZHMsIGl0cyBub3QgdGhlIHBlcmYgc3Vic3lzdGVtIHdoaWNoIGRvZXMgaW5zdHJ1Y3Rp
b24NCj4gPj4+IGxldmVsIHRyYWNpbmcsIGl0cyB0aGUgY29yZXNpZ2h0IGV0bS4gV2h5IHRoZSBw
ZXJmIHN1YnN5c3RlbSBzaG91bGQNCj4gPj4+IGJlIG1vZGlmaWVkIHRvIGxvY2tkb3duIGtlcm5l
bCBtb2RlPyBJZiB3ZSB3ZXJlIHRvIGxldCBwZXJmIGhhbmRsZQ0KPiA+Pj4gYWxsIHRoZSB0cmFj
ZSBmaWx0ZXJpbmcgZm9yIGRpZmZlcmVudCBleGNlcHRpb24gbGV2ZWxzLCB0aGVuIHdoeSBkbw0K
PiA+Pj4gd2UgbmVlZCB0aGUgcmVnaXN0ZXIgc2V0dGluZ3MgaW4gY29yZXNpZ2h0IGV0bSBkcml2
ZXIgdG8gZmlsdGVyIG91dA0KPiA+Pj4gTlMgRUwqIHRyYWNpbmc/IEFuZCBtb3JlIGltcG9ydGFu
dGx5LCBob3cgZG8geW91IHN1cHBvc2Ugd2UgaGFuZGxlIHN5c2ZzDQo+IG1vZGUgb2YgY29yZXNp
Z2h0IHRyYWNpbmcgd2l0aCBwZXJmIHN1YnN5c3RlbT8NCj4gPj4NCj4gPj4gWW91IGJvdGggaGF2
ZSBnb29kIHBvaW50cy4gTWF0aGlldSBpcyByaWdodCB0aGF0IHRoaXMgaXMgbm90IGENCj4gPj4g
Q29yZVNpZ2h0IGlzc3VlIHNwZWNpZmljYWxseSwgaXQgaXMgYSBtYXR0ZXIgb2Yga2VybmVsIHNl
Y3VyaXR5DQo+ID4+IHBvbGljeSwgYW5kIG90aGVyIGhhcmR3YXJlIHRyYWNpbmcgbWVjaGFuaXNt
cyBvdWdodCB0byBiZSB3aXRoaW4gaXRzDQo+ID4+IHNjb3BlLiBUaGVyZSBzaG91bGQgYmUgYSBn
ZW5lcmFsICJhbnRpIGtlcm5lbCBleGZpbHRyYXRpb24iIGNvbmZpZw0KPiA+PiB0aGF0IGFwcGxp
ZXMgdG8gYWxsIG1lY2hhbmlzbXMgd2l0aGluIGl0cyBzY29wZSwgYW5kIHdlJ2QgZGVmaW5pdGVs
eSBleHBlY3QNCj4gdGhhdCB0byBpbmNsdWRlIEludGVsIFBUIGFzIHdlbGwgYXMgRVRNLg0KPiA+
Pg0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIHRoaXMgcGFydCB3aGVyZSB0aGVyZSBzaG91bGQgYmUg
YSBnZW5lcmljIGNvbmZpZyBmb3IgYWxsDQo+ID4gaGFyZHdhcmUgdHJhY2luZyBmYW1pbGllcyhh
dGxlYXN0IGZvciBJbnRlbCBQVCBhbmQgQVJNIENvcmVzaWdodCksDQo+ID4gU3V6dWtpIHN1Z2dl
c3RlZCB0aGF0IGFzIHdlbGwuIEkgYW0gdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBNYXRoaWV1
DQo+ID4gZGlkbid0IGxpa2UgYWRkaW5nIHN1Y2ggYSBjb25maWcgYW5kIHdhbnRlZCBwZXJmIHN1
YnN5c3RlbSB0byBoYW5kbGUNCj4gPiBpdCBzaW5jZSBpbml0aWFsIGRpc2N1c3Npb24gd2FzIGFy
b3VuZCB3aGV0aGVyIHJvb3QgY29tcHJvbWlzZSBtZWFudA0KPiA+IGV2ZXJ5dGhpbmcgaXMgbG9z
dCBhbHJlYWR5IGFuZCBzdWNoIGEga2NvbmZpZyB3b3VsZCBub3QgaGVscCwgYnV0DQo+ID4gTWF0
dGlhcyBhbHJlYWR5IGdhdmUgc29tZSBnb29kIGV4YW1wbGVzIHdoZXJlIHRoYXQgaXMgbm90IHRy
dWUuDQo+ID4NCj4gPj4gQSBrZXJuZWwgY29uZmlnIHRoYXQgZm9yY2VkIGV4Y2x1ZGVfa2VybmVs
IG9uIGFsbCBwZXJmIGV2ZW50cyB3b3VsZA0KPiA+PiBkZWFsIHdpdGggRVRNIGFuZCBQVCBpbiBv
bmUgcGxhY2UsIGJ1dCBtaXNzIHRoZSBzeXNmcyBpbnRlcmZhY2UgdG8gRVRNLg0KPiA+Pg0KPiA+
PiBPbiB0aGUgb3RoZXIgaGFuZCwgZG9pbmcgaXQgaW4gdGhlIEVUTSBkcml2ZXJzIHdvdWxkIGNv
dmVyIHRoZSBwZXJmDQo+ID4+IGFuZCBzeXNmcyBpbnRlcmZhY2VzIHRvIEVUTSwgYnV0IHdvdWxk
IG1pc3MgSW50ZWwgUFQuDQo+ID4+DQo+ID4+IFNvIEkgdGhpbmsgd2hhdCBpcyBuZWVkZWQgaXMg
YSBnZW5lcmFsIGNvbmZpZyBvcHRpb24gdGhhdCBpcyBib3RoDQo+ID4+IGltcGxlbWVudGVkIGlu
IHBlcmYgKGV4Y2x1ZGluZyBhbGwga2VybmVsIHRyYWNpbmcgZXZlbnRzKSBhbmQgYnkgYW55DQo+
ID4+IGRyaXZlcnMgdGhhdCBwcm92aWRlIGFuIGFsdGVybmF0aXZlIGludGVyZmFjZSB0byBoYXJk
d2FyZSB0cmFjaW5nIGV2ZW50cy4NCj4gPj4NCj4gPg0KPiA+IEkgYW0gZ29vZCB3aXRoIHRoaXMg
YXBwcm9hY2gsIG9uY2UgTWF0aGlldSBjb25maXJtcywgSSBjYW4gYWRkIGENCj4gPiBrZXJuZWwg
d2lkZSBrY29uZmlnIGFzIFN1enVraSBzdWdnZXN0ZWQgZWFybGllciBhbmQgbWFrZSBFVE17Myw0
fXggYXMNCj4gPiB0aGUgaW5pdGlhbCB1c2Vycy4gU29tZW9uZSBtb3JlIGZhbWlsaWFyIHdpdGgg
SW50ZWwgUFRzIGNhbiB0aGVuIG1ha2UNCj4gPiB1c2Ugb2YgdGhpcyBrY29uZmlnLg0KPiANCj4g
SW5zdGVhZCBvZiBhZGRpbmcgdGhlIHN1cHBvcnQgZm9yIGluZGl2aWR1YWwgZHJpdmVycywgeW91
IGNvdWxkIGhhbmRsZSB0aGlzIGluIHRoZQ0KPiBnZW5lcmljIHBlcmYgbGF5ZXIuIGUuZywgRmFp
bCBwZXJmX2V2ZW50IGNyZWF0ZSB3aXRoIGFuIGF0dHJpYnV0ZSB3aGljaCBhbGxvd3MNCj4ga2Vy
bmVsIHRyYWNpbmcgPw0KPiANCj4gaWYgKCFhdHRyLmV4Y2x1ZGVfa2VybmVsKQ0KPiAJcmV0dXJu
IC1FSU5WQUw7DQo+IA0KPiBPciBldmVuIGV4Y2x1ZGUgdGhlIGtlcm5lbCBzaWxlbnRseSBhbHdh
eXMuDQo+IA0KPiBUaGlzIGNvdWxkIGFsc28gYmUgbGltaXRlZCB0byBQTVVzIHdpdGggUEVSRl9Q
TVVfQ0FQX0lUUkFDRSwgaWYgeW91IHdhbnQgdG8NCj4gbGltaXQgdGhpcyB0byBQTVVzIHRoYXQg
aW5zdHJ1Y3Rpb24gbGV2ZWwgdHJhY2luZy4NCg0KVGhlIHN5c2ZzIGludGVyZmFjZSB0byBFVE0g
YWxzbyBuZWVkcyB0byBkZW55IGFjY2VzcyB0byBrZXJuZWwgdHJhY2UsIHNvIGl0J3MNCnNhZmVz
dCB0byBlbmZvcmNlIGl0IGluIHRoZSBkcml2ZXJzIGluIGFkZGl0aW9uIHRvIGFueSBlbmZvcmNl
bWVudCBkb25lIGluIHBlcmYuDQoNCkFsc28sIGZvcmNpbmcgZXhjbHVkZV9rZXJuZWwgb24gYWxs
IHBlcmYgZXZlbnRzIG1heSBiZSB0b28gc3Ryb25nLiBJbmNsdWRpbmcNCnRoZSBrZXJuZWwgaW4g
Y291bnRlZCBldmVudHMgZS5nLiBjYWNoZSBtaXNzZXMgY2FuIGhlbHAgdW5kZXJzdGFuZCB0aGUg
ZWZmZWN0DQpvZiBzeXN0ZW0gY2FsbHMgb24gcGVyZm9ybWFuY2UsIGFuZCBpc24ndCBhIGJpZyBz
aWRlIGNoYW5uZWwgY29tcGFyZWQgdG8NCnVzZXJzcGFjZSBldmVudCBjb3VudHMuIEl0IGRvZXNu
J3QgcmV2ZWFsIGRldGFpbGVkIHRpbWluZ3MgaW4gdGhlIHdheSB0cmFjZSBkb2VzLg0KDQpTbyB0
aGVyZSdzIGFuIGFyZ3VtZW50IGZvciBsb2NraW5nIG91dCBrZXJuZWwgdHJhY2Ugc3BlY2lmaWNh
bGx5IChFVE0gb3IgUFQNCm9uIHRoZSBrZXJuZWwpOyBvciBldmVuLCBmb3IgbG9ja2luZyBvdXQg
dGltZWQgdHJhY2Ugd2l0aCB0aW1lc3RhbXBzIGFuZA0KY3ljbGUgY291bnRzLCBhbmQgYWxsb3dp
bmcgdW50aW1lZCB0cmFjZS4gU28sIHRoYXQgY291bGQgYmUgZG9uZSBpbiBwZXJmLCB3aXRoDQph
IG1vcmUgc3BlY2lmaWMgdGVzdCBvbiB0aGUgdHlwZSBvZiBldmVudCwgYmVmb3JlIGl0IGZvcmNl
ZCBleGNsdWRlX2tlcm5lbC4NCg0KQWwNCg0KDQo+IA0KPiBTdXp1a2kNCg==

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS autolearn=no 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 82A73C43381
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 12:13:38 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 4DEEE23104
	for <linux-kernel@archiver.kernel.org>; Tue, 19 Jan 2021 12:13:38 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2392441AbhASMKY (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 19 Jan 2021 07:10:24 -0500
Received: from a1.mail.mailgun.net ([198.61.254.60]:25387 "EHLO
        a1.mail.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2392175AbhASMC1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Jan 2021 07:02:27 -0500
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1611057709; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=T3sxeKkhmH8yFA4smvGRqtMhL0615rN/nOGoqsVelOY=;
 b=CYckzdLwRFZu4DAPGTzmsiDBiIR0ZzIpOppnmlWPz9rt4oet6rnRDzTcX89i3R2DLXeP1jtG
 yFQr5qPc/ylBHUICqq8dvel0RiZJLrheTt3z57GIMXd6tB3ejRPm9HzpbSnhHkTIIzNwJ3j/
 sHLWjkcwniave/qadk3TnLQzC2Y=
X-Mailgun-Sending-Ip: 198.61.254.60
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n06.prod.us-west-2.postgun.com with SMTP id
 6006c9d721210999ed939b71 (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Tue, 19 Jan 2021 12:00:23
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id D6372C43469; Tue, 19 Jan 2021 12:00:22 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id 3C8E8C433ED;
        Tue, 19 Jan 2021 12:00:21 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date:   Tue, 19 Jan 2021 17:30:21 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Suzuki K Poulose <suzuki.poulose@arm.com>
Cc:     Al Grant <Al.Grant@arm.com>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, leo.yan@linaro.org,
        mnissler@google.com, Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <de2487eb-ddb9-589a-8093-fae31235c884@arm.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
 <03b893801841f732a25072b4e62f8e0b@codeaurora.org>
 <de2487eb-ddb9-589a-8093-fae31235c884@arm.com>
Message-ID: <58bb6cfbfc9c30246fa8e2aba0964dc6@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Suzuki,

On 2021-01-19 16:03, Suzuki K Poulose wrote:
> On 1/19/21 9:51 AM, Sai Prakash Ranjan wrote:
>> Hi Al,
>> 
>> On 2021-01-19 14:06, Al Grant wrote:
>>> Hi Sai,
>>> 
>>>> From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
>>>> Hi Mathieu,
>>>> 
>>>> On 2021-01-19 01:53, Mathieu Poirier wrote:
>>>> > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
>>>> >> Hello Mathieu, Suzuki
>>>> >>
>>>> >> On 2020-10-15 21:32, Mathieu Poirier wrote:
>>>> >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>>>> >> > > On production systems with ETMs enabled, it is preferred to
>>>> >> > > exclude kernel mode(NS EL1) tracing for security concerns and
>>>> >> > > support only userspace(NS EL0) tracing. So provide an option via
>>>> >> > > kconfig to exclude kernel mode tracing if it is required.
>>>> >> > > This config is disabled by default and would not affect the
>>>> >> > > current configuration which has both kernel and userspace tracing
>>>> >> > > enabled by default.
>>>> >> > >
>>>> >> >
>>>> >> > One requires root access (or be part of a special trace group) to
>>>> >> > be able to use the cs_etm PMU.  With this kind of elevated access
>>>> >> > restricting tracing at EL1 provides little in terms of security.
>>>> >> >
>>>> >>
>>>> >> Apart from the VM usecase discussed, I am told there are other
>>>> >> security concerns here regarding need to exclude kernel mode tracing
>>>> >> even for the privileged users/root. One such case being the ability
>>>> >> to analyze cryptographic code execution since ETMs can record all
>>>> >> branch instructions including timestamps in the kernel and there may
>>>> >> be other cases as well which I may not be aware of and hence have
>>>> >> added Denis and Mattias. Please let us know if you have any questions
>>>> >> further regarding this not being a security concern.
>>>> >
>>>> > Even if we were to apply this patch there are many ways to compromise
>>>> > a system or get the kernel to reveal important information using the
>>>> > perf subsystem.  I would perfer to tackle the problem at that level
>>>> > rather than concentrating on coresight.
>>>> >
>>>> 
>>>> Sorry but I did not understand your point. We are talking about the 
>>>> capabilities
>>>> of coresight etm tracing which has the instruction level tracing and 
>>>> a lot more.
>>>> Perf subsystem is just the framework used for it.
>>>> In other words, its not the perf subsystem which does instruction 
>>>> level tracing,
>>>> its the coresight etm. Why the perf subsystem should be modified to 
>>>> lockdown
>>>> kernel mode? If we were to let perf handle all the trace filtering 
>>>> for different
>>>> exception levels, then why do we need the register settings in 
>>>> coresight etm
>>>> driver to filter out NS EL* tracing? And more importantly, how do 
>>>> you suppose
>>>> we handle sysfs mode of coresight tracing with perf subsystem?
>>> 
>>> You both have good points. Mathieu is right that this is not a 
>>> CoreSight
>>> issue specifically, it is a matter of kernel security policy, and 
>>> other hardware
>>> tracing mechanisms ought to be within its scope. There should be a 
>>> general
>>> "anti kernel exfiltration" config that applies to all mechanisms 
>>> within
>>> its scope, and we'd definitely expect that to include Intel PT as 
>>> well as ETM.
>>> 
>> 
>> I agree with this part where there should be a generic config for all
>> hardware tracing families(atleast for Intel PT and ARM Coresight),
>> Suzuki suggested that as well. I am under the impression that Mathieu
>> didn't like adding such a config and wanted perf subsystem to handle
>> it since initial discussion was around whether root compromise meant
>> everything is lost already and such a kconfig would not help, but
>> Mattias already gave some good examples where that is not true.
>> 
>>> A kernel config that forced exclude_kernel on all perf events would 
>>> deal with
>>> ETM and PT in one place, but miss the sysfs interface to ETM.
>>> 
>>> On the other hand, doing it in the ETM drivers would cover the perf 
>>> and sysfs
>>> interfaces to ETM, but would miss Intel PT.
>>> 
>>> So I think what is needed is a general config option that is both 
>>> implemented
>>> in perf (excluding all kernel tracing events) and by any drivers that 
>>> provide
>>> an alternative interface to hardware tracing events.
>>> 
>> 
>> I am good with this approach, once Mathieu confirms, I can add a 
>> kernel
>> wide kconfig as Suzuki suggested earlier and make ETM{3,4}x as the
>> initial users. Someone more familiar with Intel PTs can then make use
>> of this kconfig.
> 
> Instead of adding the support for individual drivers, you could handle 
> this
> in the generic perf layer. e.g, Fail perf_event create with an 
> attribute
> which allows kernel tracing ?
> 
> if (!attr.exclude_kernel)
> 	return -EINVAL;
> 
> Or even exclude the kernel silently always.
> 
> This could also be limited to PMUs with PERF_PMU_CAP_ITRACE, if you
> want to limit this to PMUs that instruction level tracing.
> 

Ah nice, wasn't aware of such a flag for instruction level tracing.
This sounds really good to me, I will use this in generic perf layer
and will have a config EXCLUDE_KERNEL_HW_ITRACE as you suggested
earlier.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,URIBL_BLOCKED autolearn=no 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 06813C43381
	for <linux-kernel@archiver.kernel.org>; Wed, 20 Jan 2021 05:27:49 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id C1C982311C
	for <linux-kernel@archiver.kernel.org>; Wed, 20 Jan 2021 05:27:48 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1729827AbhATFVh (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Wed, 20 Jan 2021 00:21:37 -0500
Received: from a1.mail.mailgun.net ([198.61.254.60]:27859 "EHLO
        a1.mail.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1729781AbhATFOy (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 20 Jan 2021 00:14:54 -0500
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1611119665; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=ORUMplqyK6IaDqFhTEvsF33PBH35b7H9236CHedemic=;
 b=e+wTX6PW7QbeVmw1ltyxm1gYjT9UnUIfJRy5n0ulChof/oXQX45bFXAP+w8Y9reTVvXzXMyw
 QnoDxQXj5huoqHRU8crF2bB9f/LnmuLxvF5KRxgO7QiavOqbd8qcQVU1q2x31ZHRDR2Zpccb
 iFEcGrARXIDZWTQuVtUSZ2UFisQ=
X-Mailgun-Sending-Ip: 198.61.254.60
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n03.prod.us-east-1.postgun.com with SMTP id
 6007bc17e23dedcc3a11fe5c (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Wed, 20 Jan 2021 05:13:59
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id 84062C4331D; Wed, 20 Jan 2021 05:13:57 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id AB88DC43464;
        Wed, 20 Jan 2021 05:13:54 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date:   Wed, 20 Jan 2021 10:43:54 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Al Grant <Al.Grant@arm.com>
Cc:     Suzuki Poulose <Suzuki.Poulose@arm.com>,
        Mark Rutland <Mark.Rutland@arm.com>,
        Denis Nikitin <denik@chromium.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-arm-msm@vger.kernel.org, coresight@lists.linaro.org,
        linux-kernel@vger.kernel.org, Stephen Boyd <swboyd@chromium.org>,
        Will Deacon <will@kernel.org>, Ingo Molnar <mingo@redhat.com>,
        leo.yan@linaro.org, mnissler@google.com,
        linux-arm-kernel@lists.infradead.org,
        Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <DB7PR08MB3355472BF00A47087E0130CA86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
 <03b893801841f732a25072b4e62f8e0b@codeaurora.org>
 <de2487eb-ddb9-589a-8093-fae31235c884@arm.com>
 <DB7PR08MB3355472BF00A47087E0130CA86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
Message-ID: <a8377f54c68361ba1aba948704e631ac@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Al,

On 2021-01-19 17:26, Al Grant wrote:
>> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>> On 1/19/21 9:51 AM, Sai Prakash Ranjan wrote:
>> > Hi Al,
>> >
>> > On 2021-01-19 14:06, Al Grant wrote:
>> >> Hi Sai,
>> >>
>> >>> From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
>> >>> Hi Mathieu,
>> >>>
>> >>> On 2021-01-19 01:53, Mathieu Poirier wrote:
>> >>> > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
>> >>> >> Hello Mathieu, Suzuki
>> >>> >>
>> >>> >> On 2020-10-15 21:32, Mathieu Poirier wrote:
>> >>> >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>> >>> >> > > On production systems with ETMs enabled, it is preferred to
>> >>> >> > > exclude kernel mode(NS EL1) tracing for security concerns and
>> >>> >> > > support only userspace(NS EL0) tracing. So provide an option
>> >>> >> > > via kconfig to exclude kernel mode tracing if it is required.
>> >>> >> > > This config is disabled by default and would not affect the
>> >>> >> > > current configuration which has both kernel and userspace
>> >>> >> > > tracing enabled by default.
>> >>> >> > >
>> >>> >> >
>> >>> >> > One requires root access (or be part of a special trace group)
>> >>> >> > to be able to use the cs_etm PMU.  With this kind of elevated
>> >>> >> > access restricting tracing at EL1 provides little in terms of security.
>> >>> >> >
>> >>> >>
>> >>> >> Apart from the VM usecase discussed, I am told there are other
>> >>> >> security concerns here regarding need to exclude kernel mode
>> >>> >> tracing even for the privileged users/root. One such case being
>> >>> >> the ability to analyze cryptographic code execution since ETMs
>> >>> >> can record all branch instructions including timestamps in the
>> >>> >> kernel and there may be other cases as well which I may not be
>> >>> >> aware of and hence have added Denis and Mattias. Please let us
>> >>> >> know if you have any questions further regarding this not being a security
>> concern.
>> >>> >
>> >>> > Even if we were to apply this patch there are many ways to
>> >>> > compromise a system or get the kernel to reveal important
>> >>> > information using the perf subsystem.  I would perfer to tackle
>> >>> > the problem at that level rather than concentrating on coresight.
>> >>> >
>> >>>
>> >>> Sorry but I did not understand your point. We are talking about the
>> >>> capabilities of coresight etm tracing which has the instruction level tracing
>> and a lot more.
>> >>> Perf subsystem is just the framework used for it.
>> >>> In other words, its not the perf subsystem which does instruction
>> >>> level tracing, its the coresight etm. Why the perf subsystem should
>> >>> be modified to lockdown kernel mode? If we were to let perf handle
>> >>> all the trace filtering for different exception levels, then why do
>> >>> we need the register settings in coresight etm driver to filter out
>> >>> NS EL* tracing? And more importantly, how do you suppose we handle sysfs
>> mode of coresight tracing with perf subsystem?
>> >>
>> >> You both have good points. Mathieu is right that this is not a
>> >> CoreSight issue specifically, it is a matter of kernel security
>> >> policy, and other hardware tracing mechanisms ought to be within its
>> >> scope. There should be a general "anti kernel exfiltration" config
>> >> that applies to all mechanisms within its scope, and we'd definitely expect
>> that to include Intel PT as well as ETM.
>> >>
>> >
>> > I agree with this part where there should be a generic config for all
>> > hardware tracing families(atleast for Intel PT and ARM Coresight),
>> > Suzuki suggested that as well. I am under the impression that Mathieu
>> > didn't like adding such a config and wanted perf subsystem to handle
>> > it since initial discussion was around whether root compromise meant
>> > everything is lost already and such a kconfig would not help, but
>> > Mattias already gave some good examples where that is not true.
>> >
>> >> A kernel config that forced exclude_kernel on all perf events would
>> >> deal with ETM and PT in one place, but miss the sysfs interface to ETM.
>> >>
>> >> On the other hand, doing it in the ETM drivers would cover the perf
>> >> and sysfs interfaces to ETM, but would miss Intel PT.
>> >>
>> >> So I think what is needed is a general config option that is both
>> >> implemented in perf (excluding all kernel tracing events) and by any
>> >> drivers that provide an alternative interface to hardware tracing events.
>> >>
>> >
>> > I am good with this approach, once Mathieu confirms, I can add a
>> > kernel wide kconfig as Suzuki suggested earlier and make ETM{3,4}x as
>> > the initial users. Someone more familiar with Intel PTs can then make
>> > use of this kconfig.
>> 
>> Instead of adding the support for individual drivers, you could handle 
>> this in the
>> generic perf layer. e.g, Fail perf_event create with an attribute 
>> which allows
>> kernel tracing ?
>> 
>> if (!attr.exclude_kernel)
>> 	return -EINVAL;
>> 
>> Or even exclude the kernel silently always.
>> 
>> This could also be limited to PMUs with PERF_PMU_CAP_ITRACE, if you 
>> want to
>> limit this to PMUs that instruction level tracing.
> 
> The sysfs interface to ETM also needs to deny access to kernel trace, 
> so it's
> safest to enforce it in the drivers in addition to any enforcement done 
> in perf.
> 

Yes, it will be done in drivers for sysfs interface as well based on the
same kconfig.

> Also, forcing exclude_kernel on all perf events may be too strong. 
> Including
> the kernel in counted events e.g. cache misses can help understand the 
> effect
> of system calls on performance, and isn't a big side channel compared 
> to
> userspace event counts. It doesn't reveal detailed timings in the way
> trace does.
> 
> So there's an argument for locking out kernel trace specifically (ETM 
> or PT
> on the kernel); or even, for locking out timed trace with timestamps 
> and
> cycle counts, and allowing untimed trace. So, that could be done in 
> perf, with
> a more specific test on the type of event, before it forced 
> exclude_kernel.
> 

Yes exclude_kernel for all events might not be possible, so it would be
better if it is initially applied for PMUs with PERF_PMU_CAP_ITRACE as
Suzuki suggested.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 6FFD1C433E0
	for <linux-kernel@archiver.kernel.org>; Wed, 20 Jan 2021 19:02:42 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 2B6C323403
	for <linux-kernel@archiver.kernel.org>; Wed, 20 Jan 2021 19:02:42 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2392403AbhATTCi (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Wed, 20 Jan 2021 14:02:38 -0500
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52586 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S2392045AbhATSt1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 20 Jan 2021 13:49:27 -0500
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99475C061575
        for <linux-kernel@vger.kernel.org>; Wed, 20 Jan 2021 10:48:42 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id w18so3772242pfu.9
        for <linux-kernel@vger.kernel.org>; Wed, 20 Jan 2021 10:48:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=linaro.org; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=/5Cv4pHDEwpFya1ca/ZpRFyUHE65qa5G41oFQpNl5GM=;
        b=jdVSJVKMHHUgt8ZELkdJI4HkFNZQ6l+Q0tIo6UhH7DGbLLRcbPKjW/hUUhWO0vL2oe
         kUj4kbV0jJXfbI0ebRY83BT5r1o7FthIIkRHB0vj44nEKpGdQmZIU3Ee1bQRl+AAH7vI
         5O1++uzkiWCST2JS0lLeFaRNNC21lxtdCKRP2mzI/m7Smugcka75qzj1s46llPrj3J87
         SyoMVfxFz96KMbtiWCCJ1HHTJ5Dln8KOckWKDoyD1tUd1kJ6uy3iJit3n7+6WpbWSGpJ
         QHk2CIBqqW1zSGTBUvbb5UNpsd6CrMp83lr70O//4e2AOXUJNw8F1qmiEnnwZ7aYjmOg
         CQWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=/5Cv4pHDEwpFya1ca/ZpRFyUHE65qa5G41oFQpNl5GM=;
        b=lTe8f3ngStwqLgdeZxVzdtAi6P1smy3mRSRerueM5uBBrTfNaySXa34l9YSmEhaef0
         /+katXgddsz3YnKHHFSnSQg8vqfiYqTVoXxA09BZle6ve2u0y8B0q4wcY1jUHg2zIkLB
         K1RLSdnm2Z3BLWHwxp14FVHxxLnNjJyb/BVfFWZLhFofug7+vo3ZrsStIJnVTgu+b4l5
         g8dH+gp9N0uEQ7fjOVs1gvd/Z/5hXUL9F8ikwBwJTxWRjWOlXY6IvqbzMJb1+2G/DLTZ
         qWr5prQR1Ddo/1VlO1JDJwZqyCUcc2YYCB6xx3jFTXJxFYjHfhNUSoHTHPZPXJIsFu/M
         r6cA==
X-Gm-Message-State: AOAM533kxt0Iq9/I6zA4bEyI110raEH0uqSP+9QipWLZtKTPoD4WZHWk
        T9ZdtJbYQ/ytc02lFvRsp21CTA==
X-Google-Smtp-Source: ABdhPJyEQ2ymKJwR0ANDgbelj0tESM662YjzuAKu99FKpAtwQK1t8zooyZ5dMArZCGIWt8TxlBoR4g==
X-Received: by 2002:a05:6a00:1393:b029:1b4:7938:ff1d with SMTP id t19-20020a056a001393b02901b47938ff1dmr10494530pfg.31.1611168522092;
        Wed, 20 Jan 2021 10:48:42 -0800 (PST)
Received: from xps15 (S0106889e681aac74.cg.shawcable.net. [68.147.0.187])
        by smtp.gmail.com with ESMTPSA id x23sm3195933pgk.14.2021.01.20.10.48.40
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 20 Jan 2021 10:48:41 -0800 (PST)
Date:   Wed, 20 Jan 2021 11:48:39 -0700
From:   Mathieu Poirier <mathieu.poirier@linaro.org>
To:     Al Grant <Al.Grant@arm.com>
Cc:     Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>,
        Suzuki Poulose <Suzuki.Poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>,
        "coresight@lists.linaro.org" <coresight@lists.linaro.org>,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "leo.yan@linaro.org" <leo.yan@linaro.org>,
        "mnissler@google.com" <mnissler@google.com>
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
Message-ID: <20210120184839.GB708905@xps15>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jan 19, 2021 at 08:36:22AM +0000, Al Grant wrote:
> Hi Sai,
> 
> > From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
> > Hi Mathieu,
> > 
> > On 2021-01-19 01:53, Mathieu Poirier wrote:
> > > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
> > >> Hello Mathieu, Suzuki
> > >>
> > >> On 2020-10-15 21:32, Mathieu Poirier wrote:
> > >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
> > >> > > On production systems with ETMs enabled, it is preferred to
> > >> > > exclude kernel mode(NS EL1) tracing for security concerns and
> > >> > > support only userspace(NS EL0) tracing. So provide an option via
> > >> > > kconfig to exclude kernel mode tracing if it is required.
> > >> > > This config is disabled by default and would not affect the
> > >> > > current configuration which has both kernel and userspace tracing
> > >> > > enabled by default.
> > >> > >
> > >> >
> > >> > One requires root access (or be part of a special trace group) to
> > >> > be able to use the cs_etm PMU.  With this kind of elevated access
> > >> > restricting tracing at EL1 provides little in terms of security.
> > >> >
> > >>
> > >> Apart from the VM usecase discussed, I am told there are other
> > >> security concerns here regarding need to exclude kernel mode tracing
> > >> even for the privileged users/root. One such case being the ability
> > >> to analyze cryptographic code execution since ETMs can record all
> > >> branch instructions including timestamps in the kernel and there may
> > >> be other cases as well which I may not be aware of and hence have
> > >> added Denis and Mattias. Please let us know if you have any questions
> > >> further regarding this not being a security concern.
> > >
> > > Even if we were to apply this patch there are many ways to compromise
> > > a system or get the kernel to reveal important information using the
> > > perf subsystem.  I would perfer to tackle the problem at that level
> > > rather than concentrating on coresight.
> > >
> > 
> > Sorry but I did not understand your point. We are talking about the capabilities
> > of coresight etm tracing which has the instruction level tracing and a lot more.
> > Perf subsystem is just the framework used for it.
> > In other words, its not the perf subsystem which does instruction level tracing,
> > its the coresight etm. Why the perf subsystem should be modified to lockdown
> > kernel mode? If we were to let perf handle all the trace filtering for different
> > exception levels, then why do we need the register settings in coresight etm
> > driver to filter out NS EL* tracing? And more importantly, how do you suppose
> > we handle sysfs mode of coresight tracing with perf subsystem?
> 
> You both have good points. Mathieu is right that this is not a CoreSight
> issue specifically, it is a matter of kernel security policy, and other hardware
> tracing mechanisms ought to be within its scope. There should be a general
> "anti kernel exfiltration" config that applies to all mechanisms within
> its scope, and we'd definitely expect that to include Intel PT as well as ETM.
> 
> A kernel config that forced exclude_kernel on all perf events would deal with
> ETM and PT in one place, but miss the sysfs interface to ETM.
> 
> On the other hand, doing it in the ETM drivers would cover the perf and sysfs
> interfaces to ETM, but would miss Intel PT.
> 
> So I think what is needed is a general config option that is both implemented
> in perf (excluding all kernel tracing events) and by any drivers that provide
> an alternative interface to hardware tracing events.
>

I also think this is the right solution.

Thanks,
Mathieu
 
> Al
> 
> 
> > 
> > Thanks,
> > Sai
> > 
> > --
> > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> > of Code Aurora Forum, hosted by The Linux Foundation

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,URIBL_BLOCKED autolearn=no 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 BCB6BC433DB
	for <linux-kernel@archiver.kernel.org>; Thu, 21 Jan 2021 06:06:52 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id 781D82389B
	for <linux-kernel@archiver.kernel.org>; Thu, 21 Jan 2021 06:06:52 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1725874AbhAUGFk (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Thu, 21 Jan 2021 01:05:40 -0500
Received: from a1.mail.mailgun.net ([198.61.254.60]:61813 "EHLO
        a1.mail.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726513AbhAUGEa (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 21 Jan 2021 01:04:30 -0500
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt;
 s=smtp; t=1611209032; h=Message-ID: References: In-Reply-To: Subject:
 Cc: To: From: Date: Content-Transfer-Encoding: Content-Type:
 MIME-Version: Sender; bh=vMMS0y9cspIupZ5HdJuclFp1qJwYkuG3sETR3tQ2Syg=;
 b=MJ7LiTpv0xap6xaU1VQ4Xk5sKH1T9LYbhC19//GTGLiZBotBXRIucUt/H9Wce/7eVdCFlljf
 SGUoDxphMwS1i0v3ztA+bjBHmrOR24zFvnOBNruVBOB6iZhIN5oemt+pwH6mqIxIiJyY8cU+
 WijihSVChgMdLdRbVCMXRuO/Rsg=
X-Mailgun-Sending-Ip: 198.61.254.60
X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd
Received: from smtp.codeaurora.org
 (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by
 smtp-out-n01.prod.us-east-1.postgun.com with SMTP id
 6009192ad75e1218e33a4cd6 (version=TLS1.2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Thu, 21 Jan 2021 06:03:22
 GMT
Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
Received: by smtp.codeaurora.org (Postfix, from userid 1001)
        id D9666C43461; Thu, 21 Jan 2021 06:03:21 +0000 (UTC)
Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1])
        (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
        (No client certificate requested)
        (Authenticated sender: saiprakash.ranjan)
        by smtp.codeaurora.org (Postfix) with ESMTPSA id D7656C433CA;
        Thu, 21 Jan 2021 06:03:20 +0000 (UTC)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Thu, 21 Jan 2021 11:33:20 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To:     Mathieu Poirier <mathieu.poirier@linaro.org>
Cc:     Al Grant <Al.Grant@arm.com>,
        Suzuki Poulose <Suzuki.Poulose@arm.com>,
        Mike Leach <mike.leach@linaro.org>, coresight@lists.linaro.org,
        Stephen Boyd <swboyd@chromium.org>,
        Denis Nikitin <denik@chromium.org>,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, leo.yan@linaro.org,
        mnissler@google.com
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode
 tracing
In-Reply-To: <20210120184839.GB708905@xps15>
References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org>
 <20201015160257.GA1450102@xps15>
 <dd400fd7017a5d92b55880cf28378267@codeaurora.org>
 <20210118202354.GC464579@xps15>
 <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org>
 <DB7PR08MB3355E85C72492D4766F0BEFC86A30@DB7PR08MB3355.eurprd08.prod.outlook.com>
 <20210120184839.GB708905@xps15>
Message-ID: <45b0c83833ac0e2e8d231da3c4bb8e0e@codeaurora.org>
X-Sender: saiprakash.ranjan@codeaurora.org
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2021-01-21 00:18, Mathieu Poirier wrote:
> On Tue, Jan 19, 2021 at 08:36:22AM +0000, Al Grant wrote:
>> Hi Sai,
>> 
>> > From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org
>> > Hi Mathieu,
>> >
>> > On 2021-01-19 01:53, Mathieu Poirier wrote:
>> > > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote:
>> > >> Hello Mathieu, Suzuki
>> > >>
>> > >> On 2020-10-15 21:32, Mathieu Poirier wrote:
>> > >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote:
>> > >> > > On production systems with ETMs enabled, it is preferred to
>> > >> > > exclude kernel mode(NS EL1) tracing for security concerns and
>> > >> > > support only userspace(NS EL0) tracing. So provide an option via
>> > >> > > kconfig to exclude kernel mode tracing if it is required.
>> > >> > > This config is disabled by default and would not affect the
>> > >> > > current configuration which has both kernel and userspace tracing
>> > >> > > enabled by default.
>> > >> > >
>> > >> >
>> > >> > One requires root access (or be part of a special trace group) to
>> > >> > be able to use the cs_etm PMU.  With this kind of elevated access
>> > >> > restricting tracing at EL1 provides little in terms of security.
>> > >> >
>> > >>
>> > >> Apart from the VM usecase discussed, I am told there are other
>> > >> security concerns here regarding need to exclude kernel mode tracing
>> > >> even for the privileged users/root. One such case being the ability
>> > >> to analyze cryptographic code execution since ETMs can record all
>> > >> branch instructions including timestamps in the kernel and there may
>> > >> be other cases as well which I may not be aware of and hence have
>> > >> added Denis and Mattias. Please let us know if you have any questions
>> > >> further regarding this not being a security concern.
>> > >
>> > > Even if we were to apply this patch there are many ways to compromise
>> > > a system or get the kernel to reveal important information using the
>> > > perf subsystem.  I would perfer to tackle the problem at that level
>> > > rather than concentrating on coresight.
>> > >
>> >
>> > Sorry but I did not understand your point. We are talking about the capabilities
>> > of coresight etm tracing which has the instruction level tracing and a lot more.
>> > Perf subsystem is just the framework used for it.
>> > In other words, its not the perf subsystem which does instruction level tracing,
>> > its the coresight etm. Why the perf subsystem should be modified to lockdown
>> > kernel mode? If we were to let perf handle all the trace filtering for different
>> > exception levels, then why do we need the register settings in coresight etm
>> > driver to filter out NS EL* tracing? And more importantly, how do you suppose
>> > we handle sysfs mode of coresight tracing with perf subsystem?
>> 
>> You both have good points. Mathieu is right that this is not a 
>> CoreSight
>> issue specifically, it is a matter of kernel security policy, and 
>> other hardware
>> tracing mechanisms ought to be within its scope. There should be a 
>> general
>> "anti kernel exfiltration" config that applies to all mechanisms 
>> within
>> its scope, and we'd definitely expect that to include Intel PT as well 
>> as ETM.
>> 
>> A kernel config that forced exclude_kernel on all perf events would 
>> deal with
>> ETM and PT in one place, but miss the sysfs interface to ETM.
>> 
>> On the other hand, doing it in the ETM drivers would cover the perf 
>> and sysfs
>> interfaces to ETM, but would miss Intel PT.
>> 
>> So I think what is needed is a general config option that is both 
>> implemented
>> in perf (excluding all kernel tracing events) and by any drivers that 
>> provide
>> an alternative interface to hardware tracing events.
>> 
> 
> I also think this is the right solution.
> 

Thanks for confirming, I will be working on this suggestion.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

