diff mbox series

[RFC,1/2] crypto: Allow working with key references

Message ID 20190529224844.25203-1-richard@nod.at (mailing list archive)
State RFC
Headers show
Series [RFC,1/2] crypto: Allow working with key references | expand

Commit Message

Richard Weinberger May 29, 2019, 10:48 p.m. UTC
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@nod.at>
---
 include/linux/crypto.h | 1 +
 1 file changed, 1 insertion(+)

Comments

Herbert Xu May 30, 2019, 2:33 a.m. UTC | #1
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@nod.at>

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.

Cheers,
Richard Weinberger May 30, 2019, 7:23 a.m. UTC | #2
----- Ursprüngliche Mail -----
> Von: "Herbert Xu" <herbert@gondor.apana.org.au>
> An: "richard" <richard@nod.at>
> CC: "Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>, linux-arm-kernel@lists.infradead.org, "linux-kernel"
> <linux-kernel@vger.kernel.org>, linux-imx@nxp.com, festevam@gmail.com, "kernel" <kernel@pengutronix.de>, "Sascha Hauer"
> <s.hauer@pengutronix.de>, shawnguo@kernel.org, davem@davemloft.net, "david" <david@sigma-star.at>
> 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@nod.at>
> 
> 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
Harald Freudenberger June 3, 2019, 7:59 a.m. UTC | #3
On 30.05.19 09:23, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Herbert Xu" <herbert@gondor.apana.org.au>
>> An: "richard" <richard@nod.at>
>> CC: "Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>, linux-arm-kernel@lists.infradead.org, "linux-kernel"
>> <linux-kernel@vger.kernel.org>, linux-imx@nxp.com, festevam@gmail.com, "kernel" <kernel@pengutronix.de>, "Sascha Hauer"
>> <s.hauer@pengutronix.de>, shawnguo@kernel.org, davem@davemloft.net, "david" <david@sigma-star.at>
>> 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@nod.at>
>> 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.
The "p" in paes is because we call it "protected key aes". I think you are not limited
to the "p". What Herbert tries to point out is that you may define your own
cipher with an unique name and there you can handle your secure key references
as you like. You may use the s390 paes implementation as a starting point.

regards Harald Freudenberger <freude@linux.ibm.com>

>
> Thanks,
> //richard
>
Herbert Xu June 3, 2019, 2:15 p.m. UTC | #4
On Mon, Jun 03, 2019 at 09:59:53AM +0200, Harald Freudenberger wrote:
>
> The "p" in paes is because we call it "protected key aes". I think you are not limited
> to the "p". What Herbert tries to point out is that you may define your own
> cipher with an unique name and there you can handle your secure key references
> as you like. You may use the s390 paes implementation as a starting point.

Well we have one other driver that is also using the paes name
ccree so I think we should all use this name for hardware keys
with AES.  Only the driver name needs to be unique.

Cheers,
diff mbox series

Patch

diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index f2565a103158..737ea00e026b 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -121,6 +121,7 @@ 
 #define CRYPTO_TFM_REQ_FORBID_WEAK_KEYS	0x00000100
 #define CRYPTO_TFM_REQ_MAY_SLEEP	0x00000200
 #define CRYPTO_TFM_REQ_MAY_BACKLOG	0x00000400
+#define CRYPTO_TFM_REQ_REF_KEY		0x00000800
 #define CRYPTO_TFM_RES_WEAK_KEY		0x00100000
 #define CRYPTO_TFM_RES_BAD_KEY_LEN   	0x00200000
 #define CRYPTO_TFM_RES_BAD_KEY_SCHED 	0x00400000