[3/4] coresight: etm4x: Add support to exclude kernel mode tracing

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. Perf subsystem interface for ETMs use
the newly introduced kernel config CONFIG_EXCLUDE_KERNEL_HW_ITRACE
to exclude kernel mode tracing, but there is an additional interface
via sysfs for ETMs which also needs to be handled to exclude kernel
mode tracing. So we use this same generic kernel config to handle
the sysfs mode of tracing. This config is disabled by default and
would not affect the current configuration which has both kernel and
userspace tracing enabled by default.

Tested-by: Denis Nikitin <denik@chromium.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
---
 drivers/hwtracing/coresight/coresight-etm4x-core.c | 14 +++++++++++++-
 .../hwtracing/coresight/coresight-etm4x-sysfs.c    |  3 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

Hi,

On Fri, Jan 29, 2021 at 11:08 AM Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>

> @@ -1202,6 +1207,13 @@ void etm4_config_trace_mode(struct etmv4_config *config)

>         /* excluding kernel AND user space doesn't make sense */

>         WARN_ON_ONCE(mode == (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER));

>

> +       if (!(mode & ETM_MODE_EXCL_KERN) && IS_ENABLED(CONFIG_EXCLUDE_KERNEL_HW_ITRACE)) {

> +               dev_err(&drvdata->csdev->dev,

> +                       "Kernel mode tracing is not allowed, check your kernel config\n");

> +               config->mode |= ETM_MODE_EXCL_KERN;

> +               return;


So I'm not an expert on this code, but the above looks suspicious to
me.  Specifically you are still modifying "config->mode" even though
printing an "error" (dev_err, not dev_warn) and then skipping the rest
of this function.  Since you're skipping the rest of this function
you're not applying the access, right?  Naively I'd have expected one
of these:

1. Maybe the "dev_err" should be a "dev_warn" and then you shouldn't
"return".  In this case you're just implicitly adding
"ETM_MODE_EXCL_KERN" (and shouting) but then making things work.  Of
course, then what happens if the user already specified
"ETM_MODE_EXCL_USER" too?  As per the comment above that "doesn't make
sense".  ...so maybe the code wouldn't behave properly...

2. Maybe you should be modifying this function to return an error code.

3. Maybe you should just be updating the one caller of this function
to error check this right at the beginning of the function and then
fail the sysfs write if the user did the wrong thing.  Then in
etm4_config_trace_mode you could just have a WARN_ON_ONCE if the
kernel wasn't excluded...

-Doug

Hi,

Thanks for taking a look, comments inline.

On 2021-02-23 01:44, Doug Anderson wrote:
> Hi,

> 

> On Fri, Jan 29, 2021 at 11:08 AM Sai Prakash Ranjan

> <saiprakash.ranjan@codeaurora.org> wrote:

>> 

>> @@ -1202,6 +1207,13 @@ void etm4_config_trace_mode(struct etmv4_config 

>> *config)

>>         /* excluding kernel AND user space doesn't make sense */

>>         WARN_ON_ONCE(mode == (ETM_MODE_EXCL_KERN | 

>> ETM_MODE_EXCL_USER));

>> 

>> +       if (!(mode & ETM_MODE_EXCL_KERN) && 

>> IS_ENABLED(CONFIG_EXCLUDE_KERNEL_HW_ITRACE)) {

>> +               dev_err(&drvdata->csdev->dev,

>> +                       "Kernel mode tracing is not allowed, check 

>> your kernel config\n");

>> +               config->mode |= ETM_MODE_EXCL_KERN;

>> +               return;

> 

> So I'm not an expert on this code, but the above looks suspicious to

> me.  Specifically you are still modifying "config->mode" even though

> printing an "error" (dev_err, not dev_warn) and then skipping the rest

> of this function.  Since you're skipping the rest of this function

> you're not applying the access, right?  Naively I'd have expected one

> of these:

> 

> 1. Maybe the "dev_err" should be a "dev_warn" and then you shouldn't

> "return".  In this case you're just implicitly adding

> "ETM_MODE_EXCL_KERN" (and shouting) but then making things work.  Of

> course, then what happens if the user already specified

> "ETM_MODE_EXCL_USER" too?  As per the comment above that "doesn't make

> sense".  ...so maybe the code wouldn't behave properly...

> 

> 2. Maybe you should be modifying this function to return an error code.

> 


mode_store() which is the caller of this function sets the config->mode
based on the value passed in the sysfs, so if the user passes the mode
which doesn't exclude the kernel even though the kernel config is 
enabled
and the code just sets it, then that is an error and the user should be
warned about, so I used dev_err, but I can change it to dev_warn if that
is preferred. And to make sysfs mode show the original mode after 
failure,
I set the mode in etm4_config_trace_mode().

But you are right, I am skipping to set the config for other mode bits
and returning which is wrong, will fix it as you suggest below.

> 3. Maybe you should just be updating the one caller of this function

> to error check this right at the beginning of the function and then

> fail the sysfs write if the user did the wrong thing.  Then in

> etm4_config_trace_mode you could just have a WARN_ON_ONCE if the

> kernel wasn't excluded...

> 


Right, will do this.

Thanks,
Sai

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