[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tupqu10c.fsf@linux.intel.com>
Date: Thu, 04 Mar 2021 12:17:39 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
Cc: Mathieu Poirier <mathieu.poirier@...aro.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Leo Yan <leo.yan@...aro.org>, Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>, coresight@...ts.linaro.org,
Stephen Boyd <swboyd@...omium.org>,
Denis Nikitin <denik@...omium.org>,
Mattias Nissler <mnissler@...omium.org>,
Al Grant <al.grant@....com>, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing
Andi Kleen <ak@...ux.intel.com> writes:
>
> Normally disk encryption is in specialized work queues. It's total
> overkill to restrict all of the kernel if you just want to restrict
> those work queues.
>
> I would suggest some more analysis where secrets are actually stored
> and handled first.
Also thinking about this more:
You really only want to limit data tracing here.
If tracing branches could reveal secrets the crypto code would be
already insecure due to timing side channels. If that's the
case it would already require fixing the crypto code.
-Andi
Powered by blists - more mailing lists