----- Ursprüngliche Mail ----- > Von: "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> > An: "richard" <richard@xxxxxx> > CC: "Linux Crypto Mailing List" <linux-crypto@xxxxxxxxxxxxxxx>, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, "linux-kernel" > <linux-kernel@xxxxxxxxxxxxxxx>, linux-imx@xxxxxxx, festevam@xxxxxxxxx, "kernel" <kernel@xxxxxxxxxxxxxx>, "Sascha Hauer" > <s.hauer@xxxxxxxxxxxxxx>, shawnguo@xxxxxxxxxx, davem@xxxxxxxxxxxxx, "david" <david@xxxxxxxxxxxxx> > Gesendet: Donnerstag, 30. Mai 2019 04:33:57 > Betreff: Re: [RFC PATCH 1/2] crypto: Allow working with key references > On Thu, May 30, 2019 at 12:48:43AM +0200, Richard Weinberger wrote: >> Some crypto accelerators allow working with secure or hidden keys. >> This keys are not exposed to Linux nor main memory. To use them >> for a crypto operation they are referenced with a device specific id. >> >> This patch adds a new flag, CRYPTO_TFM_REQ_REF_KEY. >> If this flag is set, crypto drivers should tread the key as >> specified via setkey as reference and not as regular key. >> Since we reuse the key data structure such a reference is limited >> by the key size of the chiper and is chip specific. >> >> TODO: If the cipher implementation or the driver does not >> support reference keys, we need a way to detect this an fail >> upon setkey. >> How should the driver indicate that it supports this feature? >> >> Signed-off-by: Richard Weinberger <richard@xxxxxx> > > We already have existing drivers doing this. Please have a look > at how they're doing it and use the same paradigm. You can grep > for paes under drivers/crypto. Thanks for the pointer. So the preferred way is defining a new crypto algorithm prefixed with "p" and reusing setkey to provide the key reference. Thanks, //richard
