Re: [PATCH] crypto: caam - remove HMAC key hex dumps from hash_digest_key

[Thorsten Blum]

On Wed, Mar 18, 2026 at 04:46:34PM +0900, Herbert Xu wrote:
> On Tue, Mar 17, 2026 at 12:20:30PM +0100, Thorsten Blum wrote:
> >
> > This is not specifically about caam, but (debug) logging of potentially
> > sensitive key material should generally be avoided, imho. Some other
> > recent examples:
> > 
> > https://lore.kernel.org/lkml/20260227230008.858641-2-thorsten.blum@xxxxxxxxx/
> > https://lore.kernel.org/lkml/20260303132552.65235-2-thorsten.blum@xxxxxxxxx/
> > https://lore.kernel.org/lkml/20260303190350.78705-2-thorsten.blum@xxxxxxxxx/
> > 
> > > Is there a scenario where production systems will run with debugging
> > > enabled in caam?
> > 
> > I don't know - possibly.
> 
> I think a better solution is to turn these sensitive printk's to
> pr_devel.  That way you can still get them by recompiling the kernel
> but they won't be enabled in any distro kernels.
> 
> What do you think?

Sounds reasonable. However, the code is already using the debug-gated
print_hex_dump_debug(), which can also be enabled at runtime with
CONFIG_DYNAMIC_DEBUG.

So I think the question is not necessarily print_hex_dump_debug() vs.
pr_devel(), but whether we want to:

- keep the debug-only hex dumps
- remove the sensitive dumps

My main concern is that with CONFIG_DYNAMIC_DEBUG enabled, which doesn't
require DEBUG, these raw key dumps can still be turned on at runtime in
a deployed kernel.

If we want to keep the dumps for debug-only kernels, then #ifdef DEBUG
plus print_hex_dump() might be a good compromise.