[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM9PR04MB82112828E21FDA2043073216E8479@AM9PR04MB8211.eurprd04.prod.outlook.com>
Date: Tue, 13 Sep 2022 10:01:13 +0000
From: Varun Sethi <V.Sethi@....com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Pankaj Gupta <pankaj.gupta@....com>,
"jarkko@...nel.org" <jarkko@...nel.org>,
"a.fatoum@...gutronix.de" <a.fatoum@...gutronix.de>,
"Jason@...c4.com" <Jason@...c4.com>,
"jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
"zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
"dhowells@...hat.com" <dhowells@...hat.com>,
"sumit.garg@...aro.org" <sumit.garg@...aro.org>,
"david@...ma-star.at" <david@...ma-star.at>,
"michael@...le.cc" <michael@...le.cc>,
"john.ernberg@...ia.se" <john.ernberg@...ia.se>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"serge@...lyn.com" <serge@...lyn.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"j.luebbe@...gutronix.de" <j.luebbe@...gutronix.de>,
"ebiggers@...nel.org" <ebiggers@...nel.org>,
"richard@....at" <richard@....at>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
Sahil Malhotra <sahil.malhotra@....com>,
Kshitiz Varshney <kshitiz.varshney@....com>,
Horia Geanta <horia.geanta@....com>
Subject: 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@...dor.apana.org.au>
> Sent: Tuesday, September 13, 2022 7:36 AM
> To: Varun Sethi <V.Sethi@....com>
> Cc: Pankaj Gupta <pankaj.gupta@....com>; jarkko@...nel.org;
> a.fatoum@...gutronix.de; Jason@...c4.com; jejb@...ux.ibm.com;
> zohar@...ux.ibm.com; dhowells@...hat.com; sumit.garg@...aro.org;
> david@...ma-star.at; michael@...le.cc; john.ernberg@...ia.se;
> jmorris@...ei.org; serge@...lyn.com; davem@...emloft.net;
> j.luebbe@...gutronix.de; ebiggers@...nel.org; richard@....at;
> keyrings@...r.kernel.org; linux-crypto@...r.kernel.org; linux-
> integrity@...r.kernel.org; linux-kernel@...r.kernel.org; linux-security-
> module@...r.kernel.org; Sahil Malhotra <sahil.malhotra@....com>; Kshitiz
> Varshney <kshitiz.varshney@....com>; Horia Geanta <horia.geanta@....com>
> 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@...dor.apana.org.au> 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
Powered by blists - more mailing lists