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

[David Gstir]

> On 10.10.2022, at 17:15, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> 
> On Mon, Oct 10, 2022 at 11:15:00AM +0000, Pankaj Gupta wrote:
>>> 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?

I believe what Herbert means are drivers registered with the cipher name 
prefix “p”. E.g. [1] registers multiple “paes” variants. There was a
previous patch set for CAAM where this was suggested as well [2].

- David

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/ccree/cc_cipher.c#n1011
[2] https://lore.kernel.org/linux-crypto/20200716073610.GA28215@xxxxxxxxxxxxxxxxxxx/