Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing

I know this reply is hopelessly late, but I still want to clarify a
few things (see inline for that) and provide some background on the
thinking that led to this proposal and where we ultimately landed for
the benefit of folks that come across this thread in the future.

The team working on tracing had asked me to provide input on the
security angle. We generally follow principle of least privilege /
attack surface minimization principles, and so the conclusion "kernel
tracing not needed" -> let's turn it off so we have one less thing to
potentially worry about was an easy one. What I hadn't been aware of
is that (a) no such config option exists in the kernel and (b) the
approach that the kernel is taking is to limit access to tracing data
to privileged users (via perf_event_paranoid sysctl, CAP_PERFMON).
Same for leaking kernel code pointers (note that kernel tracing
trivially defeats KASLR), privileged userspace can already read
/proc/kallsysms. While I would still like the kernel to give us a
build time option to disable kernel tracing, we can work with the
current state of affairs.

On Wed, Mar 10, 2021 at 4:17 PM Sai Prakash Ranjan
[off-list ref] wrote:

Hi Andi,

On 2021-03-09 20:14, Andi Kleen wrote:

quoted

quoted

The disk encryption is just one example

The intention behind that example was to illustrate the point that
there are some data items that the kernel should hide to all of
userspace, including privileged processes. I know this has been
controversial in the past, but I hope we all agree that the kernel (if
configured appropriately) is aiming to do so.

and there might be others

quoted

quoted

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.

quoted

quoted

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.

Timing side channels have been a constant source of grief in crypto
implementations for decades now. Things have become better in the most
popular implementations, but bugs continue to be found. I happened to
chat about this topic with David Benjamin (boringssl maintainer)
recently, and his take was that timing side channels are a well
understood problem meanwhile, but in practice few implementations get
the details right. And the thing with high-resolution timestamps in
traces is that it gives you a tool to observe timing differences
closer to the source (so less noise) than if you just measure syscall
latency from userspace. So, in theory you are right - data-dependent
branches should not exist in crypto code, and if they do we should
just fix them, since they're potentially exploitable already. In
practice, timestamp information in tracing data can act as a
magnifying glass that may well make a difference between whether a
timing side channel is problematic in practice or not.

quoted

quoted

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.

quoted

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.

quoted

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

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

 From what I know, newer ARM A-profile cores doesn't allow data tracing.
And you
are saying that just the instruction tracing cannot be used to infer any
important data.

There are few security folks in CC who probably can give us more details
on how
branch tracing can be used for an exploit. @mnissler?

Thanks,
Sai

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

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