linux-integrity.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Pankaj Gupta <pankaj.gupta@nxp.com>,
	"jarkko@kernel.org" <jarkko@kernel.org>,
	"a.fatoum@pengutronix.de" <a.fatoum@pengutronix.de>,
	"gilad@benyossef.com" <gilad@benyossef.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"zohar@linux.ibm.com" <zohar@linux.ibm.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"sumit.garg@linaro.org" <sumit.garg@linaro.org>,
	"david@sigma-star.at" <david@sigma-star.at>,
	"michael@walle.cc" <michael@walle.cc>,
	"john.ernberg@actia.se" <john.ernberg@actia.se>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"serge@hallyn.com" <serge@hallyn.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"j.luebbe@pengutronix.de" <j.luebbe@pengutronix.de>,
	"ebiggers@kernel.org" <ebiggers@kernel.org>,
	"richard@nod.at" <richard@nod.at>,
	"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	Sahil Malhotra <sahil.malhotra@nxp.com>,
	Kshitiz Varshney <kshitiz.varshney@nxp.com>,
	Horia Geanta <horia.geanta@nxp.com>,
	Varun Sethi <V.Sethi@nxp.com>
Subject: Re: [EXT] Re: [PATCH v0 3/8] crypto: hbk flags & info added to the tfm
Date: Fri, 14 Oct 2022 16:19:41 -0300	[thread overview]
Message-ID: <Y0m2TU5k78I1AR+p@ziepe.ca> (raw)
In-Reply-To: <Y0aDiLp7BztzwNez@gondor.apana.org.au>

On Wed, Oct 12, 2022 at 05:06:16PM +0800, Herbert Xu wrote:

> > Rather, drivers that do AES should be called "aes". For this hardware
> > key situation, I guess that means keys have a type (in-memory vs
> > hardware-resident). Then, a crypto operation takes an "algorithm" and a
> > "key", and the abstraction then picks the best implementation that's
> > compatible with both the "algorithm" and the "key".
> 
> No the key is already in a specific hardware bound to some driver.
> The user already knows where the key is and therefore they know
> which driver it is.

Do they?

We have HW that can do HW resident keys as as well, in our case it is
plugged into the storage system with fscrypt and all the crypto
operations are being done "inline" as the data is DMA'd into/out of
the storage. So, no crypto API here.

I would say the user knows about the key and its binding in the sense
they loaded a key into the storage device and mounted a fscrypt
filesystem from that storage device - but the kernel may not know this
explicitly.

> > If you don't want a proliferation of different ways of doing the same
> > thing, maybe the requirement should be that the author of this series
> > also converts the existing "paes" kludge to use the new thing he's
> > proposing?
> 
> Yes that would definitely be a good idea.  We should also talk to the
> people who added paes in the first place, i.e., s390.

Yes, it would be nice to see a comprehensive understand on how HW
resident keys can be modeled in the keyring. Almost every computer now
has a TPM that is also quite capable of doing operations with these
kinds of keys. Seeing the whole picture, including how we generate and
load/save/provision these things seems important.

Jason

  reply	other threads:[~2022-10-14 19:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 13:08 [PATCH v0 0/8] Hardware Bound key added to Trusted Key-Ring Pankaj Gupta
2022-10-06 13:08 ` [PATCH v0 1/8] hw-bound-key: introducing the generic structure Pankaj Gupta
2022-10-12  8:52   ` Jarkko Sakkinen
2022-10-12  8:53   ` Jarkko Sakkinen
2022-10-06 13:08 ` [PATCH v0 2/8] keys-trusted: new cmd line option added Pankaj Gupta
2022-10-06 12:37   ` Ben Boeckel
2022-10-06 13:08 ` [PATCH v0 3/8] crypto: hbk flags & info added to the tfm Pankaj Gupta
2022-10-07  6:58   ` Herbert Xu
2022-10-10 11:15     ` [EXT] " Pankaj Gupta
2022-10-10 15:15       ` Jason A. Donenfeld
2022-10-10 21:35         ` [EXT] " David Gstir
2022-10-11  9:03         ` [EXT] " Herbert Xu
2022-10-11 11:32           ` Pankaj Gupta
2022-10-11 20:01           ` Jason A. Donenfeld
2022-10-12  9:06             ` Herbert Xu
2022-10-14 19:19               ` Jason Gunthorpe [this message]
2022-10-20  4:26                 ` Eric Biggers
2022-10-20 19:23                   ` Jason Gunthorpe
2022-10-20 21:28                     ` Eric Biggers
2022-10-20 23:42                       ` Jason Gunthorpe
2022-10-11 11:05         ` Pankaj Gupta
2022-10-12  8:57   ` Jarkko Sakkinen
2022-10-06 13:08 ` [PATCH v0 4/8] sk_cipher: checking for hw bound operation Pankaj Gupta
2022-10-12  8:59   ` Jarkko Sakkinen
2022-10-06 13:08 ` [PATCH v0 5/8] keys-trusted: re-factored caam based trusted key Pankaj Gupta
2022-10-06 13:08 ` [PATCH v0 6/8] KEYS: trusted: caam based black key Pankaj Gupta
2022-10-06 12:42   ` Ben Boeckel
2022-10-06 12:52     ` James Bottomley
2022-10-06 13:08 ` [PATCH v0 7/8] caam alg: symmetric key ciphers are updated Pankaj Gupta
2022-10-12  9:01   ` Jarkko Sakkinen
2022-10-06 13:08 ` [PATCH v0 8/8] dm-crypt: consumer-app setting the flag-is_hbk Pankaj Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0m2TU5k78I1AR+p@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=Jason@zx2c4.com \
    --cc=V.Sethi@nxp.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=davem@davemloft.net \
    --cc=david@sigma-star.at \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=gilad@benyossef.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=j.luebbe@pengutronix.de \
    --cc=jarkko@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=john.ernberg@actia.se \
    --cc=keyrings@vger.kernel.org \
    --cc=kshitiz.varshney@nxp.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=pankaj.gupta@nxp.com \
    --cc=richard@nod.at \
    --cc=sahil.malhotra@nxp.com \
    --cc=serge@hallyn.com \
    --cc=sumit.garg@linaro.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).