Re: [EXT] Re: [PATCH v0 3/8] crypto: hbk flags & info added to the tfm

On Mon, Oct 10, 2022 at 11:15:00AM +0000, Pankaj Gupta wrote:

quoted

Nack.  You still have not provided a convincing argument why this is necessary
since there are plenty of existing drivers in the kernel already providing similar
features.

CAAM is used as a trusted source for trusted keyring. CAAM can expose
these keys either as plain key or HBK(hardware bound key- managed by
the hardware only and never visible in plain outside of hardware).

Thus, Keys that are inside CAAM-backed-trusted-keyring, can either be
plain key or HBK. So the trusted-key-payload requires additional flag
& info(key-encryption-protocol)  to help differentiate it from each
other. Now when CAAM trusted-key is presented to the kernel crypto
framework, the additional information associated with the key, needs
to be passed to the hardware driver. Currently the kernel keyring and
kernel crypto frameworks are associated for plain key, but completely
dis-associated for HBK. This patch addresses this problem.

Similar capabilities (trusted source), are there in other crypto
accelerators on NXP SoC(s). Having hardware specific crypto algorithm
name, does not seems to be a scalable solution.

Do you mean to say that other drivers that use hardware-backed keys do
so by setting "cra_name" to something particular? Like instead of "aes"
it'd be "aes-but-special-for-this-driver"? If so, that would seem to
break the design of the crypto API. Which driver did you see that does
this? Or perhaps, more generally, what are the drivers that Herbert is
talking about when he mentions the "plenty of existing drivers" that
already do this?

Jason