[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yx/lc1YjWm9+df1r@gondor.apana.org.au>
Date: Tue, 13 Sep 2022 10:05:39 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Varun Sethi <V.Sethi@....com>
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
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?
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists