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.