Hi Andi, On 2021-03-05 01:47, Andi Kleen wrote: > Andi Kleen <ak@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/ Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
