All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
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,
	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 06:44:23 -0800	[thread overview]
Message-ID: <20210309144423.GD203350@tassilo.jf.intel.com> (raw)
In-Reply-To: <20210309063828.26392-1-saiprakash.ranjan@codeaurora.org>

> 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.

Then you don't have any leaks relating to branch tracing.

> 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.

It's just a general property that if some code that is handling secrets
is data dependent it already leaks.


> 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

There's no victim with branch tracing, unless it is already leaky.

> 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?

For a useful security mitigation you need a threat model first I would say.

So you need to have at least some idea how an attack with branch
tracing would work.


> Initial change was to restrict this only to HW assisted instruction tracing [1]

I don't think it's needed for instruction tracing.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@linux.intel.com>
To: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
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,
	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 06:44:23 -0800	[thread overview]
Message-ID: <20210309144423.GD203350@tassilo.jf.intel.com> (raw)
In-Reply-To: <20210309063828.26392-1-saiprakash.ranjan@codeaurora.org>

> 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.

Then you don't have any leaks relating to branch tracing.

> 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.

It's just a general property that if some code that is handling secrets
is data dependent it already leaks.


> 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

There's no victim with branch tracing, unless it is already leaky.

> 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?

For a useful security mitigation you need a threat model first I would say.

So you need to have at least some idea how an attack with branch
tracing would work.


> Initial change was to restrict this only to HW assisted instruction tracing [1]

I don't think it's needed for instruction tracing.

-Andi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-03-09 14:45 UTC|newest]

Thread overview: 26+ 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 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-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-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-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 19:59   ` Andi Kleen
2021-03-04 20:17   ` Andi Kleen
2021-03-04 20:17     ` Andi Kleen
2021-03-09  6:38     ` Sai Prakash Ranjan
2021-03-09 14:44       ` Andi Kleen [this message]
2021-03-09 14:44         ` Andi Kleen
2021-03-10 15:17         ` Sai Prakash Ranjan
2021-06-10 13:28           ` Mattias Nissler
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=20210309144423.GD203350@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=acme@kernel.org \
    --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=saiprakash.ranjan@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.