LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [RFC PATCH 1/2] crypto: Allow working with key references
@ 2019-05-29 22:48 Richard Weinberger
  2019-05-29 22:48 ` [RFC PATCH 2/2] crypto: mxs-dcp: Implement reference keys Richard Weinberger
  2019-05-30  2:33 ` [RFC PATCH 1/2] crypto: Allow working with key references Herbert Xu
  0 siblings, 2 replies; 6+ messages in thread
From: Richard Weinberger @ 2019-05-29 22:48 UTC (permalink / raw)
  To: linux-crypto
  Cc: linux-arm-kernel, linux-kernel, linux-imx, festevam, kernel,
	s.hauer, shawnguo, davem, herbert, david, Richard Weinberger

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(+)

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
-- 
2.16.4


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [RFC PATCH 2/2] crypto: mxs-dcp: Implement reference keys
  2019-05-29 22:48 [RFC PATCH 1/2] crypto: Allow working with key references Richard Weinberger
@ 2019-05-29 22:48 ` Richard Weinberger
  2019-05-30  2:33 ` [RFC PATCH 1/2] crypto: Allow working with key references Herbert Xu
  1 sibling, 0 replies; 6+ messages in thread
From: Richard Weinberger @ 2019-05-29 22:48 UTC (permalink / raw)
  To: linux-crypto
  Cc: linux-arm-kernel, linux-kernel, linux-imx, festevam, kernel,
	s.hauer, shawnguo, davem, herbert, david, Richard Weinberger

DCP allows working with secure keys. These keys can reside in a
protected memory region of the crypto accelerator, burned in
eFuses or being an internal chip key. To use these keys a key
reference is transferred to the chip instead of a AES key.
For DCP these references can be:
0x00 to 0x03: Key slot number in the secure memory region
0xfe: Unique device key
0xff: OTP key (burned in eFuse)

To utilize this functionality we check for the
CRYPTO_TFM_REQ_REF_KEY flag, if it is set the key as provided
via mxs_dcp_aes_setkey() is used as reference.

Signed-off-by: Richard Weinberger <richard@nod.at>
---
 drivers/crypto/mxs-dcp.c | 77 +++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 63 insertions(+), 14 deletions(-)

diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index b4429891e368..22b048a3a91b 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -147,6 +147,10 @@ static struct dcp *global_sdcp;
 
 #define MXS_DCP_CONTEXT				0x50
 
+#define MXS_DCP_KEY				0x60
+#define MXS_DCP_KEY_IDX(id, word)		(((id) << 4) | (word))
+#define MXS_DCP_KEYDATA				0x70
+
 #define MXS_DCP_CH_N_CMDPTR(n)			(0x100 + ((n) * 0x40))
 
 #define MXS_DCP_CH_N_SEMA(n)			(0x110 + ((n) * 0x40))
@@ -158,6 +162,7 @@ static struct dcp *global_sdcp;
 #define MXS_DCP_CONTROL0_HASH_TERM		(1 << 13)
 #define MXS_DCP_CONTROL0_HASH_INIT		(1 << 12)
 #define MXS_DCP_CONTROL0_PAYLOAD_KEY		(1 << 11)
+#define MXS_DCP_CONTROL0_OTP_KEY		(1 << 10)
 #define MXS_DCP_CONTROL0_CIPHER_ENCRYPT		(1 << 8)
 #define MXS_DCP_CONTROL0_CIPHER_INIT		(1 << 9)
 #define MXS_DCP_CONTROL0_ENABLE_HASH		(1 << 6)
@@ -222,15 +227,22 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 	struct dcp *sdcp = global_sdcp;
 	struct dcp_dma_desc *desc = &sdcp->coh->desc[actx->chan];
 	struct dcp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
+	struct crypto_async_request *arq = &req->base;
+	bool key_referenced = !!(crypto_tfm_get_flags(arq->tfm) &
+				 CRYPTO_TFM_REQ_REF_KEY);
+	dma_addr_t src_phys, dst_phys, key_phys = {0};
 	int ret;
 
-	dma_addr_t key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
-					     2 * AES_KEYSIZE_128,
-					     DMA_TO_DEVICE);
-	dma_addr_t src_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_in_buf,
-					     DCP_BUF_SZ, DMA_TO_DEVICE);
-	dma_addr_t dst_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_out_buf,
-					     DCP_BUF_SZ, DMA_FROM_DEVICE);
+	if (!key_referenced) {
+		key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
+						     2 * AES_KEYSIZE_128,
+						     DMA_TO_DEVICE);
+	}
+
+	src_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_in_buf,
+				  DCP_BUF_SZ, DMA_TO_DEVICE);
+	dst_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_out_buf,
+				  DCP_BUF_SZ, DMA_FROM_DEVICE);
 
 	if (actx->fill % AES_BLOCK_SIZE) {
 		dev_err(sdcp->dev, "Invalid block size!\n");
@@ -243,8 +255,12 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 		    MXS_DCP_CONTROL0_INTERRUPT |
 		    MXS_DCP_CONTROL0_ENABLE_CIPHER;
 
-	/* Payload contains the key. */
-	desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
+	if (key_referenced) {
+		desc->control0 |= MXS_DCP_CONTROL0_OTP_KEY;
+	} else {
+		/* Payload contains the key. */
+		desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
+	}
 
 	if (rctx->enc)
 		desc->control0 |= MXS_DCP_CONTROL0_CIPHER_ENCRYPT;
@@ -258,18 +274,26 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
 	else
 		desc->control1 |= MXS_DCP_CONTROL1_CIPHER_MODE_CBC;
 
+	if (key_referenced)
+		desc->control1 |= sdcp->coh->aes_key[0] << 8;
+
 	desc->next_cmd_addr = 0;
 	desc->source = src_phys;
 	desc->destination = dst_phys;
 	desc->size = actx->fill;
-	desc->payload = key_phys;
+	if (key_referenced)
+		desc->payload = 0;
+	else
+		desc->payload = key_phys;
 	desc->status = 0;
 
 	ret = mxs_dcp_start_dma(actx);
 
 aes_done_run:
-	dma_unmap_single(sdcp->dev, key_phys, 2 * AES_KEYSIZE_128,
-			 DMA_TO_DEVICE);
+	if (!key_referenced) {
+		dma_unmap_single(sdcp->dev, key_phys, 2 * AES_KEYSIZE_128,
+				 DMA_TO_DEVICE);
+	}
 	dma_unmap_single(sdcp->dev, src_phys, DCP_BUF_SZ, DMA_TO_DEVICE);
 	dma_unmap_single(sdcp->dev, dst_phys, DCP_BUF_SZ, DMA_FROM_DEVICE);
 
@@ -498,15 +522,40 @@ static int mxs_dcp_aes_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
 			      unsigned int len)
 {
 	struct dcp_async_ctx *actx = crypto_ablkcipher_ctx(tfm);
+	bool key_referenced = !!(crypto_ablkcipher_get_flags(tfm) &
+				 CRYPTO_TFM_REQ_REF_KEY);
 	unsigned int ret;
 
 	/*
-	 * AES 128 is supposed by the hardware, store key into temporary
+	 * AES 128 is supported by the hardware, store key into temporary
 	 * buffer and exit. We must use the temporary buffer here, since
 	 * there can still be an operation in progress.
 	 */
 	actx->key_len = len;
-	if (len == AES_KEYSIZE_128) {
+
+	if (key_referenced) {
+		/*
+		 * If a hardware key is used, no software fallback is possible.
+		 */
+		if (len != AES_KEYSIZE_128)
+			return -EINVAL;
+
+		/*
+		 * DCP supports the following key slots.
+		 */
+		switch (key[0]) {
+		case 0x00:
+		case 0x01:
+		case 0x02:
+		case 0x03:
+		case 0xfe:
+		case 0xff:
+			memcpy(actx->key, key, len);
+			return 0;
+		default:
+			return -EINVAL;
+		}
+	} else if (len == AES_KEYSIZE_128) {
 		memcpy(actx->key, key, len);
 		return 0;
 	}
-- 
2.16.4


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH 1/2] crypto: Allow working with key references
  2019-05-29 22:48 [RFC PATCH 1/2] crypto: Allow working with key references Richard Weinberger
  2019-05-29 22:48 ` [RFC PATCH 2/2] crypto: mxs-dcp: Implement reference keys Richard Weinberger
@ 2019-05-30  2:33 ` Herbert Xu
  2019-05-30  7:23   ` Richard Weinberger
  1 sibling, 1 reply; 6+ messages in thread
From: Herbert Xu @ 2019-05-30  2:33 UTC (permalink / raw)
  To: Richard Weinberger
  Cc: linux-crypto, linux-arm-kernel, linux-kernel, linux-imx,
	festevam, kernel, s.hauer, shawnguo, davem, david

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH 1/2] crypto: Allow working with key references
  2019-05-30  2:33 ` [RFC PATCH 1/2] crypto: Allow working with key references Herbert Xu
@ 2019-05-30  7:23   ` Richard Weinberger
  2019-06-03  7:59     ` Harald Freudenberger
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Weinberger @ 2019-05-30  7:23 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Linux Crypto Mailing List, linux-arm-kernel, linux-kernel,
	linux-imx, festevam, kernel, Sascha Hauer, shawnguo, davem,
	david

----- 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH 1/2] crypto: Allow working with key references
  2019-05-30  7:23   ` Richard Weinberger
@ 2019-06-03  7:59     ` Harald Freudenberger
  2019-06-03 14:15       ` Herbert Xu
  0 siblings, 1 reply; 6+ messages in thread
From: Harald Freudenberger @ 2019-06-03  7:59 UTC (permalink / raw)
  To: Richard Weinberger, Herbert Xu
  Cc: Linux Crypto Mailing List, linux-arm-kernel, linux-kernel,
	linux-imx, festevam, kernel, Sascha Hauer, shawnguo, davem,
	david

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
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH 1/2] crypto: Allow working with key references
  2019-06-03  7:59     ` Harald Freudenberger
@ 2019-06-03 14:15       ` Herbert Xu
  0 siblings, 0 replies; 6+ messages in thread
From: Herbert Xu @ 2019-06-03 14:15 UTC (permalink / raw)
  To: Harald Freudenberger
  Cc: Richard Weinberger, Linux Crypto Mailing List, linux-arm-kernel,
	linux-kernel, linux-imx, festevam, kernel, Sascha Hauer,
	shawnguo, davem, david

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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-06-03 14:15 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-29 22:48 [RFC PATCH 1/2] crypto: Allow working with key references Richard Weinberger
2019-05-29 22:48 ` [RFC PATCH 2/2] crypto: mxs-dcp: Implement reference keys Richard Weinberger
2019-05-30  2:33 ` [RFC PATCH 1/2] crypto: Allow working with key references Herbert Xu
2019-05-30  7:23   ` Richard Weinberger
2019-06-03  7:59     ` Harald Freudenberger
2019-06-03 14:15       ` Herbert Xu

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).