Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
---
  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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux