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
Date: Fri, 16 Oct 2020 14:00:53 +0530 [thread overview]
Message-ID: <2b5c14ca55b57430ac1d7aac533d45de@codeaurora.org> (raw)
In-Reply-To: <c02be978-5d78-b88d-ea87-b9958b6e3a05@arm.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: denik@chromium.org, mathieu.poirier@linaro.org,
peterz@infradead.org, linux-arm-msm@vger.kernel.org,
coresight@lists.linaro.org, linux-kernel@vger.kernel.org,
swboyd@chromium.org, linux-arm-kernel@lists.infradead.org,
mike.leach@linaro.org
Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing
Date: Fri, 16 Oct 2020 14:00:53 +0530 [thread overview]
Message-ID: <2b5c14ca55b57430ac1d7aac533d45de@codeaurora.org> (raw)
In-Reply-To: <c02be978-5d78-b88d-ea87-b9958b6e3a05@arm.com>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-16 8:32 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 12:45 [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing Sai Prakash Ranjan
2020-10-15 12:45 ` Sai Prakash Ranjan
2020-10-15 14:27 ` Suzuki K Poulose
2020-10-15 14:27 ` Suzuki K Poulose
2020-10-16 8:30 ` Sai Prakash Ranjan [this message]
2020-10-16 8:30 ` Sai Prakash Ranjan
2020-10-15 16:02 ` Mathieu Poirier
2020-10-15 16:02 ` Mathieu Poirier
[not found] ` <CADDJ8CXS8gGuXL45vR6xiHwJhZNcUJPvHMVYSGR6LDETRPJFiQ@mail.gmail.com>
2020-10-16 7:24 ` Leo Yan
2020-10-16 7:24 ` Leo Yan
2020-10-16 8:40 ` Sai Prakash Ranjan
2020-10-16 8:40 ` Sai Prakash Ranjan
2020-10-16 9:24 ` Leo Yan
2020-10-16 9:24 ` Leo Yan
2020-10-16 10:30 ` Sai Prakash Ranjan
2020-10-16 10:30 ` Sai Prakash Ranjan
2020-10-16 11:38 ` Suzuki Poulose
2020-10-16 11:38 ` Suzuki Poulose
2020-10-16 13:14 ` Leo Yan
2020-10-16 13:14 ` Leo Yan
2020-10-16 13:17 ` Suzuki Poulose
2020-10-16 13:17 ` Suzuki Poulose
2020-10-16 11:11 ` Suzuki Poulose
2020-10-16 11:11 ` Suzuki Poulose
2021-01-15 5:46 ` Sai Prakash Ranjan
2021-01-18 14:47 ` Mattias Nissler
2021-01-18 14:47 ` Mattias Nissler
2021-01-19 5:12 ` Sai Prakash Ranjan
2021-01-18 20:23 ` Mathieu Poirier
2021-01-18 20:23 ` Mathieu Poirier
2021-01-19 5:21 ` Sai Prakash Ranjan
2021-01-19 8:36 ` Al Grant
2021-01-19 8:36 ` Al Grant
2021-01-19 9:51 ` Sai Prakash Ranjan
2021-01-19 10:33 ` Suzuki K Poulose
2021-01-19 10:33 ` Suzuki K Poulose
2021-01-19 11:56 ` Al Grant
2021-01-19 11:56 ` Al Grant
2021-01-20 5:13 ` Sai Prakash Ranjan
2021-01-19 12:00 ` Sai Prakash Ranjan
2021-01-20 18:48 ` Mathieu Poirier
2021-01-20 18:48 ` Mathieu Poirier
2021-01-21 6:03 ` Sai Prakash Ranjan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2b5c14ca55b57430ac1d7aac533d45de@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=coresight@lists.linaro.org \
--cc=denik@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.