> 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
