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

[Sai Prakash Ranjan]

On 2021-01-18 20:17, Mattias Nissler wrote:
> On Fri, Jan 15, 2021 at 6:46 AM Sai Prakash Ranjan
> <saiprakash.ranjan@xxxxxxxxxxxxxx> 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