Hi Herbert, Please find response inline. Regards Varun > -----Original Message----- > From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, September 13, 2022 7:36 AM > To: Varun Sethi <V.Sethi@xxxxxxx> > Cc: Pankaj Gupta <pankaj.gupta@xxxxxxx>; jarkko@xxxxxxxxxx; > a.fatoum@xxxxxxxxxxxxxx; Jason@xxxxxxxxx; jejb@xxxxxxxxxxxxx; > zohar@xxxxxxxxxxxxx; dhowells@xxxxxxxxxx; sumit.garg@xxxxxxxxxx; > david@xxxxxxxxxxxxx; michael@xxxxxxxx; john.ernberg@xxxxxxxx; > jmorris@xxxxxxxxx; serge@xxxxxxxxxx; davem@xxxxxxxxxxxxx; > j.luebbe@xxxxxxxxxxxxxx; ebiggers@xxxxxxxxxx; richard@xxxxxx; > keyrings@xxxxxxxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx; linux- > integrity@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-security- > module@xxxxxxxxxxxxxxx; Sahil Malhotra <sahil.malhotra@xxxxxxx>; Kshitiz > Varshney <kshitiz.varshney@xxxxxxx>; Horia Geanta <horia.geanta@xxxxxxx> > 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: > > > > > On Wed, Sep 07, 2022 at 09:58:45AM +0000, Pankaj Gupta wrote: > > > > > > > > There are 3rd party IP(s), which uses kernel for crypto-algorithm's > operations. > > > > 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 <herbert@xxxxxxxxxxxxxxxxxxx> 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
