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

[Varun Sethi]

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&amp;data=05%7C01%7CV.Sethi%40nxp.com%7C6
> 51bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&amp;sdata=b%2BjXwEqMEomgvSpLVnNzuWRNbmfQF4pX5hitrFh
> Frww%3D&amp;reserved=0
> PGP Key:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgondor.ap
> ana.org.au%2F~herbert%2Fpubkey.txt&amp;data=05%7C01%7CV.Sethi%40nxp.
> com%7C651bdc5f5da249c7f23408da952c9980%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C637986316034004134%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&amp;sdata=6VRL5smACsEevXL8HKs2ADlni9G%2F9J0q7E
> 3Q2emxVzU%3D&amp;reserved=0