From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: ak@linux.intel.com
Cc: acme@kernel.org, al.grant@arm.com,
alexander.shishkin@linux.intel.com, coresight@lists.linaro.org,
denik@chromium.org, dianders@chromium.org, jolsa@redhat.com,
leo.yan@linaro.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
mark.rutland@arm.com, mathieu.poirier@linaro.org,
mike.leach@linaro.org, mingo@redhat.com, mnissler@chromium.org,
namhyung@kernel.org, peterz@infradead.org,
saiprakash.ranjan@codeaurora.org, suzuki.poulose@arm.com,
swboyd@chromium.org
Subject: Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing
Date: Tue, 9 Mar 2021 12:08:28 +0530 [thread overview]
Message-ID: <20210309063828.26392-1-saiprakash.ranjan@codeaurora.org> (raw)
In-Reply-To: <87tupqu10c.fsf@linux.intel.com>
Hi Andi,
On 2021-03-05 01:47, Andi Kleen wrote:
> Andi Kleen <ak@linux.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.
>
The disk encryption is just one example and there might be others which
we might not be aware of yet and we are not suspecting there is something
wrong with the crypto code that needs to be fixed. Here the idea was to
restrict an external(in the sense that its not related to crypto or any
other security related component) entity such as hardware assisted tracing
like ARM coresight and so on. I don't see why or how the crypto code needs
to be fixed for something that is not related to it although it is affected.
The analogy would be like of the victims and a perpetrator. Lets take coresight
as an example for perpetrator and crypto as the victim here. Now we can try
to harden the protection and safeguard the victims which may or may not be
successful but it will be possible only if we know the victims beforehand.
If we just know one victim (lets say crypto code here), what happens to the
others which we haven't identified yet? Do we just wait for someone to write
an exploit based on this and then scramble to fix it?
Now the other foolproof way of saving the victims would be locking down the
perpetrator which would definitely save all the victims but that needs the
perpetrator to be identified. In our case, the perpetrator (coresight or any
other hw tracing) is already known, so we want to lock it down or restrict it
so that if there is actually a vulnerability in crypto or other areas, then
this HW assisted tracing wouldn't be able to help exploit it.
Initial change was to restrict this only to HW assisted instruction tracing [1]
but Peter wasn't convinced that this applies to only instruction tracing. Hence
this change for all kernel level pmu tracing. And this is a configurable option
via kernel config so that we don't force it on everyone. This config is also
required for coresight etm drivers because they have a sysfs mode of tracing as
well in addition to perf mode.
[1] https://lore.kernel.org/lkml/cover.1611909025.git.saiprakash.ranjan@codeaurora.org/
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2021-03-09 6:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 19:04 [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing Sai Prakash Ranjan
2021-03-01 19:04 ` [PATCHv2 1/4] " Sai Prakash Ranjan
2021-03-01 22:42 ` Doug Anderson
2021-03-01 19:04 ` [PATCHv2 2/4] perf evsel: Print warning for excluding kernel mode instruction tracing Sai Prakash Ranjan
2021-03-01 22:43 ` Doug Anderson
2021-03-02 6:45 ` Sai Prakash Ranjan
2021-03-01 19:04 ` [PATCHv2 3/4] coresight: etm4x: Add support to exclude kernel mode tracing Sai Prakash Ranjan
2021-03-01 22:43 ` Doug Anderson
2021-03-02 6:41 ` Sai Prakash Ranjan
2021-03-01 19:04 ` [PATCHv2 4/4] coresight: etm3x: " Sai Prakash Ranjan
2021-03-01 22:43 ` Doug Anderson
2021-03-02 6:46 ` Sai Prakash Ranjan
2021-03-04 19:59 ` [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing Andi Kleen
2021-03-04 20:17 ` Andi Kleen
2021-03-09 6:38 ` Sai Prakash Ranjan [this message]
2021-03-09 14:44 ` Andi Kleen
2021-03-10 15:17 ` Sai Prakash Ranjan
2021-06-10 13:28 ` Mattias Nissler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210309063828.26392-1-saiprakash.ranjan@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=al.grant@arm.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=denik@chromium.org \
--cc=dianders@chromium.org \
--cc=jolsa@redhat.com \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=mnissler@chromium.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=swboyd@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox