RE: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added to the tfm

Hi Herbert,
Please find response inline.

Regards
Varun

-----Original Message-----
From: Herbert Xu <herbert@gondor.apana.org.au>
Sent: Tuesday, September 13, 2022 7:36 AM
To: Varun Sethi <redacted>
Cc: Pankaj Gupta <pankaj.gupta@nxp.com>; jarkko@kernel.org;
a.fatoum@pengutronix.de; Jason@zx2c4.com; jejb@linux.ibm.com;
zohar@linux.ibm.com; dhowells@redhat.com; sumit.garg@linaro.org;
david@sigma-star.at; michael@walle.cc; john.ernberg@actia.se;
jmorris@namei.org; serge@hallyn.com; davem@davemloft.net;
j.luebbe@pengutronix.de; ebiggers@kernel.org; richard@nod.at;
keyrings@vger.kernel.org; linux-crypto@vger.kernel.org; linux-
integrity@vger.kernel.org; linux-kernel@vger.kernel.org; linux-security-
module@vger.kernel.org; Sahil Malhotra [off-list ref]; Kshitiz
Varshney [off-list ref]; Horia Geanta [off-list ref]
Subject: Re: [EXT] Re: [RFC PATCH HBK: 2/8] hw-bound-key: flag-is_hbk added
to the tfm

Caution: EXT Email

On Mon, Sep 12, 2022 at 05:19:44PM +0000, Varun Sethi wrote:

quoted

quoted

On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote:

quoted

There are 3rd party IP(s), which uses kernel for crypto-algorithm's

operations.

quoted

quoted

quoted

Modifying the algorithm name in these IP(s), is not always allowed
or easy to

maintain.

So the objective is to support out-of-tree modules?

[Varun] No, the intention is not to use out of tree modules but to allow

seamless use of crytpo ciphers with keys backed by security co-processors (keys
only visible to security co-processors), by Linux kernel and userspace
components. Hardware backed keys are being introduced as a variant of existing
Trusted keys, with the difference that these are not un-sealed and released in
plain to the kernel memory. With the current patchset, the existing set of ciphers
can be used along with newly introduced hardware backed flag. The security co-
processor driver is able to interpret the flag and subsequently program the
hardware, to interpret the supplied key as a hardware backed key.

Well I asked why isn't the existing arrangement for hardware key algorithms
sufficient, and I was given the response that you needed this for compatibility
with third-party IP(s).

Now are you saying this is not the case? So the existing framework should work
then?

[Varun] The proposed patchset makes things more scalable. With the hardware backed key flag, there's no need for the security co-processor driver to register separate set of algorithms. This makes things simpler and more scalable for the consumers (OpenSSL, AF_ALG, KTLS etc), as they can continue to use standard set of algorithms and leave the key specific complexity to the driver.

Cheers,
--
Email: Herbert Xu [off-list ref] Home Page:
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
ana.org.au%2F~herbert%2F&data=05%7C01%7CV.Sethi%40nxp.com%7C6
51bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c5c301635
%7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
%7C%7C%7C&sdata=b%2BjXwEqMEomgvSpLVnNzuWRNbmfQF4pX5hitrFh
Frww%3D&reserved=0
PGP Key:
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
ana.org.au%2F~herbert%2Fpubkey.txt&data=05%7C01%7CV.Sethi%40nxp.
com%7C651bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c
5c301635%7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C3000%7C%7C%7C&sdata=6VRL5smACsEevXL8HKs2ADlni9G%2F9J0q7E
3Q2emxVzU%3D&reserved=0