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

[Al Grant]

Hi Sai,

> From: saiprakash.ranjan=codeaurora.org at 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.

Al


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