Re: crypto: algif_hash - Only export and import on sockets with data

2015-10-30 Thread Stephan Mueller 
Am Freitag, 30. Oktober 2015, 20:16:51 schrieb Herbert Xu:

Hi Herbert,

> 
> setkey should be needed as the subsequent accept will all be based
> on the same parent fd, meaning that they will all use a single tfm.
> 
> Please try the following patch.

Testing complete: patch solves the oops and allows to successfully perform 
HMAC even when having subsequent accepts and operating on those subsequent 
accepts.

-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] nx-842: Endian swap ->count before handing over to the nx-842 compressor

2015-10-30 Thread Ram Pai 
The nx-842 compressor overshoots the output buffer corrupting memory. Verified
that the following patch fixes the issue on a little-endian system.

Signed-off-by: Ram Pai 
---
 drivers/crypto/nx/nx-842-powernv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/crypto/nx/nx-842-powernv.c 
b/drivers/crypto/nx/nx-842-powernv.c
index 3750e13..3b80ea7 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -66,7 +66,7 @@ static void setup_indirect_dde(struct data_descriptor_entry 
*dde,
   unsigned int dde_count, unsigned int byte_count)
 {
dde->flags = 0;
-   dde->count = dde_count;
+   dde->count = cpu_to_be32(dde_count);
dde->index = 0;
dde->length = cpu_to_be32(byte_count);
dde->address = cpu_to_be64(nx842_get_pa(ddl));

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] nx-842: Ignore bit 3 of condition register returned by icswx

2015-10-30 Thread Ram Pai 
icswx occasionally under heavy load sets bit 3 of condition register 0.
It has no software implication.

Currently that bit is interpreted by the driver as a failure, when
it should have calmly ignored it.

Signed-off-by: Ram Pai 
---
 arch/powerpc/include/asm/icswx.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/icswx.h b/arch/powerpc/include/asm/icswx.h
index 9f8402b..bce20c7 100644
--- a/arch/powerpc/include/asm/icswx.h
+++ b/arch/powerpc/include/asm/icswx.h
@@ -177,7 +177,7 @@ static inline int icswx(__be32 ccw, struct 
coprocessor_request_block *crb)
: "r" (ccw_reg), "r" (crb)
: "cr0", "memory");
 
-   return (int)((cr >> 28) & 0xf);
+   return (int)((cr >> 28) & 0xe);
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

2015-10-30 Thread Heiko Stuebner 
Hi,

first of all, thanks for working on this, it will be really cool to see the
crypto accelerator supported in the kernel :-)

Am Freitag, 30. Oktober 2015, 16:22:46 schrieb Zain Wang:
> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher 
> mode.
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/rk_crypto/Makefile  |   3 +
>  drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>  drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>  .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 
> +
>  5 files changed, 1190 insertions(+)
>  create mode 100644 drivers/crypto/rk_crypto/Makefile
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
> 
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index c3ced6f..00d103c 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/

as Mark said in the other mail, there may very well follow other Rockchip
crypto-related drivers, so maybe it might be better to name the core
option CONFIG_CRYPTO_DEV_ROCKCHIP. And then maybe define
CONFIG_CRYPTO_DEV_RK3288 in a Kconfig in the subdirectory (like vmx does).


> diff --git a/drivers/crypto/rk_crypto/Makefile 
> b/drivers/crypto/rk_crypto/Makefile
> new file mode 100644
> index 000..0f62d87
> --- /dev/null
> +++ b/drivers/crypto/rk_crypto/Makefile

generally, a lot of those subdirectories reference only the manufacturer
name, so my suggestion would be to name yours just "rockchip" instead of
"rk_crypto", to also ease readability.


> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
> +rk_crypto_driver-objs := rk3288_crypto.o \
> +  rk3288_crypto_ablkcipher.o \

that looks looks wrong.

(1) the config option does not get defined in any Kconfig file in your set
(2) naming the driver generically while you compile a variant will hinder
multiplatform kernels, because you might want to build both the rk3288
code and some additional stuff?
(3) the _driver suffix is unnecessary

So I guess just name it rk3288_crypto.o ?

[...]

While I have read through the code implementing the device, I haven't
seen anything spring out but do not know enough about the crypto subsystem
itself. But it looks like you got some feedback already anyway from others :-)


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 4/4] crypto: rk_crypto - add DT bindings documentation

2015-10-30 Thread Heiko Stuebner 
Hi,

Am Freitag, 30. Oktober 2015, 16:22:49 schrieb Zain Wang:
> Add DT bindings documentation for the rk3288 crypto drivers.
> 
> Signed-off-by: Zain Wang 
> ---
>  .../devicetree/bindings/crypto/rk-crypto.txt   | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/rk-crypto.txt 
> b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
> new file mode 100644
> index 000..1e50768
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
> @@ -0,0 +1,31 @@
> +Rockchip Electronics And Security Accelerator
> +
> +Required properties:
> +- compatible: should be "rockchip,crypto"
> +- reg: base physical address of the engine and length of memory mapped
> +   region.
> +- interrupts: interrupt number
> +- clocks: clock specifiers
> +- clock-names: "aclk_crypto" used to clock data
> +"hclk_crypto" used to clock data
> +"srst_crypto" used to clock crypto accelerator
> +"apb_pclk"used to clock dma

The TRM area of the crypto IP block does not specifiy any special naming for
its clocks, but as a general rule clock names are in the scope of the ip block
so there is no need to add _crypto to every one of them :-) .

I'd suggest clock-names as "aclk", "hclk", "crypto" for the devicetree, with
crypto being the clock that actually drives the operation.


Secondly, why do you need to drive the clock of the peripheral dma-
controller itself (your apb_pclk)? The documentation in the TRM is
quite sparse, so this might very well be justified, but it looks odd that
you need to control the dmac1-clock when it looks like the crypto block
is doing its own dma and neither system-dma has any crypto-related
channel.

So I'd really like some explanation for this :-)


Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 4/4] crypto: rk_crypto - add DT bindings documentation

2015-10-30 Thread Mark Rutland 
On Fri, Oct 30, 2015 at 04:22:49PM +0800, Zain Wang wrote:
> Add DT bindings documentation for the rk3288 crypto drivers.
> 
> Signed-off-by: Zain Wang 
> ---
>  .../devicetree/bindings/crypto/rk-crypto.txt   | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt
> 
> diff --git a/Documentation/devicetree/bindings/crypto/rk-crypto.txt 
> b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
> new file mode 100644
> index 000..1e50768
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
> @@ -0,0 +1,31 @@
> +Rockchip Electronics And Security Accelerator
> +
> +Required properties:
> +- compatible: should be "rockchip,crypto"

Choose a more specific name. Rockchip could easily come up with another
crypto accelerator later.

> +- reg: base physical address of the engine and length of memory mapped
> +   region.
> +- interrupts: interrupt number
> +- clocks: clock specifiers
> +- clock-names: "aclk_crypto" used to clock data
> +"hclk_crypto" used to clock data
> +"srst_crypto" used to clock crypto accelerator
> +"apb_pclk"used to clock dma
> +-status: Enable

No need to mention the status property.

Thanks,
Mark.

> +
> +Examples:
> +
> + crypto: cypto-controller@ff8a {
> + compatible = "rockchip,crypto";
> + reg = <0xff8a 0x4000>;
> + interrupts = ;
> + clocks = <&cru ACLK_CRYPTO>,
> +  <&cru HCLK_CRYPTO>,
> +  <&cru SRST_CRYPTO>,
> +  <&cru ACLK_DMAC1>;
> +
> + clock-names = "aclk_crypto",
> +   "hclk_crypto",
> +   "srst_crypto",
> +   "apb_pclk";
> + status = "okay";
> + };
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

crypto: algif_hash - Only export and import on sockets with data

2015-10-30 Thread Herbert Xu 
On Fri, Oct 30, 2015 at 12:10:51PM +0100, Stephan Mueller wrote:
> Am Freitag, 30. Oktober 2015, 14:02:27 schrieb Harsh Jain:
> 
> Hi Harsh,
> 
> >Hi Stephan,
> >
> >If we add sendmsg() in between 2 accept calls then the setkey problem
> >will happen?
> >
> >handle->opfd = accept(handle->tfmfd, NULL, 0);
> >sendmsg()
> >handle->opfd = accept(handle->opfd, NULL, 0);
> >sendmsg()
> >handle->opfd = accept(handle->opfd, NULL, 0);
> 
> Without testing, I would very much expect that, because the setkey does not 
> apply to the subordinate tfm.

setkey should be needed as the subsequent accept will all be based
on the same parent fd, meaning that they will all use a single tfm.

Please try the following patch.

---8<---
The hash_accept call fails to work on sockets that have not received
any data.  For some algorithm implementations it may cause crashes.

This patch fixes this by ensuring that we only export and import on
sockets that have received data.

Cc: sta...@vger.kernel.org
Reported-by: Harsh Jain 
Signed-off-by: Herbert Xu 

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 1396ad0..bbda6b4 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -181,11 +181,14 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
+   bool more = ctx->more;
int err;
 
-   err = crypto_ahash_export(req, state);
-   if (err)
-   return err;
+   if (more) {
+   err = crypto_ahash_export(req, state);
+   if (err)
+   return err;
+   }
 
err = af_alg_accept(ask->parent, newsock);
if (err)
@@ -194,12 +197,14 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
sk2 = newsock->sk;
ask2 = alg_sk(sk2);
ctx2 = ask2->private;
-   ctx2->more = 1;
+   ctx2->more = more;
 
-   err = crypto_ahash_import(&ctx2->req, state);
-   if (err) {
-   sock_orphan(sk2);
-   sock_put(sk2);
+   if (more) {
+   err = crypto_ahash_import(&ctx2->req, state);
+   if (err) {
+   sock_orphan(sk2);
+   sock_put(sk2);
+   }
}
 
return err;
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] crypto: add entry for sm3-256

2015-10-30 Thread Jarkko Sakkinen 
Added entry for sm3-256 to the following tables:

* hash_algo_name
* hash_digest_size

Needed for TPM 2.0 trusted key sealing.

Signed-off-by: Jarkko Sakkinen 
---
 crypto/hash_info.c | 2 ++
 include/crypto/hash_info.h | 3 +++
 include/uapi/linux/hash_info.h | 1 +
 3 files changed, 6 insertions(+)

diff --git a/crypto/hash_info.c b/crypto/hash_info.c
index 3e7ff46..7b1e0b1 100644
--- a/crypto/hash_info.c
+++ b/crypto/hash_info.c
@@ -31,6 +31,7 @@ const char *const hash_algo_name[HASH_ALGO__LAST] = {
[HASH_ALGO_TGR_128] = "tgr128",
[HASH_ALGO_TGR_160] = "tgr160",
[HASH_ALGO_TGR_192] = "tgr192",
+   [HASH_ALGO_SM3_256] = "sm3-256",
 };
 EXPORT_SYMBOL_GPL(hash_algo_name);
 
@@ -52,5 +53,6 @@ const int hash_digest_size[HASH_ALGO__LAST] = {
[HASH_ALGO_TGR_128] = TGR128_DIGEST_SIZE,
[HASH_ALGO_TGR_160] = TGR160_DIGEST_SIZE,
[HASH_ALGO_TGR_192] = TGR192_DIGEST_SIZE,
+   [HASH_ALGO_SM3_256] = SM3256_DIGEST_SIZE,
 };
 EXPORT_SYMBOL_GPL(hash_digest_size);
diff --git a/include/crypto/hash_info.h b/include/crypto/hash_info.h
index e1e5a3e..56f217d 100644
--- a/include/crypto/hash_info.h
+++ b/include/crypto/hash_info.h
@@ -34,6 +34,9 @@
 #define TGR160_DIGEST_SIZE 20
 #define TGR192_DIGEST_SIZE 24
 
+/* not defined in include/crypto/ */
+#define SM3256_DIGEST_SIZE 32
+
 extern const char *const hash_algo_name[HASH_ALGO__LAST];
 extern const int hash_digest_size[HASH_ALGO__LAST];
 
diff --git a/include/uapi/linux/hash_info.h b/include/uapi/linux/hash_info.h
index ca18c45..ebf8fd8 100644
--- a/include/uapi/linux/hash_info.h
+++ b/include/uapi/linux/hash_info.h
@@ -31,6 +31,7 @@ enum hash_algo {
HASH_ALGO_TGR_128,
HASH_ALGO_TGR_160,
HASH_ALGO_TGR_192,
+   HASH_ALGO_SM3_256,
HASH_ALGO__LAST
 };
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/3] TPM2: select hash algorithm for a trusted key

2015-10-30 Thread Jarkko Sakkinen 
Jarkko Sakkinen (3):
  keys, trusted: select the hash algorithm
  crypto: add entry for sm3-256
  tpm: choose hash algorithm for sealing when using TPM 2.0

 Documentation/security/keys-trusted-encrypted.txt |  3 ++
 crypto/hash_info.c|  2 ++
 drivers/char/tpm/tpm.h| 10 --
 drivers/char/tpm/tpm2-cmd.c   | 42 +--
 include/crypto/hash_info.h|  3 ++
 include/keys/trusted-type.h   |  1 +
 include/uapi/linux/hash_info.h|  1 +
 security/keys/Kconfig |  1 +
 security/keys/trusted.c   | 20 ++-
 9 files changed, 76 insertions(+), 7 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel tainted while exporting shash context using af_alg interface

2015-10-30 Thread Stephan Mueller 
Am Freitag, 30. Oktober 2015, 14:02:27 schrieb Harsh Jain:

Hi Harsh,

>Hi Stephan,
>
>If we add sendmsg() in between 2 accept calls then the setkey problem
>will happen?
>
>handle->opfd = accept(handle->tfmfd, NULL, 0);
>sendmsg()
>handle->opfd = accept(handle->opfd, NULL, 0);
>sendmsg()
>handle->opfd = accept(handle->opfd, NULL, 0);

Without testing, I would very much expect that, because the setkey does not 
apply to the subordinate tfm.
>
>If yes, Then may be it is expected behavior and user is supposed to
>set the key explicitly with some other system call.Why I am saying
>this is. I remember somewhere in kernel code I read some comment
>related to setkey operations.

I would like to wait for Herbert to chime in here on how he thinks this would 
work.
>
>In that case my patch should work. 1 doubt I have related to patch is
>do I need to set "ctx->more" =1 after initialisation.
>
>Correct me If I am wrong.
>
>
>Thanks for your support.
>
>
>regards
>Harsh Jain
>
>On Wed, Oct 28, 2015 at 4:53 PM, Stephan Mueller  wrote:
>> Am Mittwoch, 28. Oktober 2015, 16:24:34 schrieb Harsh Jain:
>> 
>> Hi Harsh,
>> 
>>>Hi Stephan,
>>>
>>>I tried your patch on my machine. Kernel is not crashing. The openssl
>>>break with this. Can you share HMAC program which you are suspecting
>>>it will not work or do you already have some test written in
>>>libkcapi/test.sh which will fail.
>>>
>> See comments above test/kcapi-main.c:cavs_hash
>> 
>>  * HMAC command line invocation:
>>  * $ ./kcapi -x 3 -c "hmac(sha1)" -k
>>  6e77ebd479da794707bc6cde3694f552ea892dab
>> 
>> -p
>> 31b62a797adbff6b8a358d2b5206e01fee079de8cdfc4695138bba163b4efbf30127343e7fd
>> 4fbc696c3d38d8f27f57c024b5056f726ceeb4c31d98e57751ec8cbe8904ee0f9b031ae6a0c
>> 55da5e062475b3d7832191d4057643ef5fa446801d59a04693e573a8159cd2416b7bd39c7f0
>> fe63c599365e04d596c05736beaab58> 
>>  * 7f204ea665666f5bd2b370e546d1b408005e4d85
>> 
>> To do that, apply your patch and then
>> 
>> 1. open lib/kcapi-kernel-if.c and change line 567 from
>> 
>> handle->opfd = accept(handle->tfmfd, NULL, 0);
>> 
>> 
>> to
>> 
>> handle->opfd = accept(handle->tfmfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> 
>> You will see that the hash commands will pass, the HMAC fails
>> 
>> Without your patch, the kernel crashes (same as with your OpenSSL code).
>> 
>> The reason is that setkey is applied on the TFM that is not conveyed to the
>> subsequent TFMs generated with new accepts.
>> 
>>>Regards
>>>Harsh Jain
>>>
>>>On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller  
wrote:
 Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
 
 Hi Harsh,
 
> However, any error in user space should not crash the kernel. So, a fix
> should be done. But I think your code is not correct as it solidifies a
> broken user space code.
 
 After thinking a bit again, I think your approach is correct after all. I
 was able to reproduce the crash by simply adding more accept calls to my
 test code. And I can confirm that your patch works, for hashes.
 
 *BUT* it does NOT work for HMAC as the key is set on the TFM and the
 subsequent accepts do not transport the key. Albeit your code prevents
 the
 kernel from crashing, the HMAC calculation will be done with an empty key
 as
 the setkey operation does not reach the TFM handle in the subordinate
 accept() call.
 
 So, I would think that the second accept is simply broken, for HMAC at
 least.
 
 Herbert, what is the purpose of that subordinate accept that is
 implemented
 with hash_accept? As this is broken for HMACs, should it be removed
 entirely?
 
 --
 Ciao
 Stephan
>>>
>>>--
>>>To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>>>the body of a message to majord...@vger.kernel.org
>>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>> Ciao
>> Stephan


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

2015-10-30 Thread Stephan Mueller 
Am Freitag, 30. Oktober 2015, 16:22:46 schrieb Zain Wang:

Hi Zain,

>Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
>mode. The names registered are:
>ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
>You can alloc tags above in your case.
>
>And other algorithms and platforms will be added later on.
>
>Signed-off-by: Zain Wang 
>---
> drivers/crypto/Makefile|   1 +
> drivers/crypto/rk_crypto/Makefile  |   3 +
> drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
> drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
> .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502
>+ 5 files changed, 1190 insertions(+)
> create mode 100644 drivers/crypto/rk_crypto/Makefile
> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
> create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
>
>diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
>index c3ced6f..00d103c 100644
>--- a/drivers/crypto/Makefile
>+++ b/drivers/crypto/Makefile
>@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
> obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
> obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
> obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
>+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
>diff --git a/drivers/crypto/rk_crypto/Makefile
>b/drivers/crypto/rk_crypto/Makefile new file mode 100644
>index 000..0f62d87
>--- /dev/null
>+++ b/drivers/crypto/rk_crypto/Makefile
>@@ -0,0 +1,3 @@
>+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
>+rk_crypto_driver-objs := rk3288_crypto.o \
>+   rk3288_crypto_ablkcipher.o \
>diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c
>b/drivers/crypto/rk_crypto/rk3288_crypto.c new file mode 100644
>index 000..fe55d7e
>--- /dev/null
>+++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
>@@ -0,0 +1,393 @@
>+/*
>+ *Crypto acceleration support for Rockchip RK3288
>+ *
>+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
>+ *
>+ * Author: Zain Wang 
>+ *
>+ * This program is free software; you can redistribute it and/or modify it
>+ * under the terms and conditions of the GNU General Public License,
>+ * version 2, as published by the Free Software Foundation.
>+ *
>+ * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
>+ */
>+
>+#include "rk3288_crypto.h"
>+#include 
>+#include 
>+#include 
>+#include 
>+#include 
>+
>+struct crypto_info_t *crypto_p;
>+
>+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
>+{
>+  if (clk_prepare_enable(dev->clk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
>+  __func__, __LINE__);
>+  return -ENOENT;
>+  }
>+  if (clk_prepare_enable(dev->aclk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
>+  __func__, __LINE__);
>+  goto err_aclk;
>+  }
>+  if (clk_prepare_enable(dev->hclk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
>+  __func__, __LINE__);
>+  goto err_hclk;
>+  }
>+  if (clk_prepare_enable(dev->pclk)) {
>+  dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
>+  __func__, __LINE__);
>+  goto err_pclk;
>+  }
>+  return 0;
>+
>+err_pclk:
>+  clk_disable_unprepare(dev->hclk);
>+err_hclk:
>+  clk_disable_unprepare(dev->aclk);
>+err_aclk:
>+  clk_disable_unprepare(dev->clk);
>+
>+  return -ENOENT;
>+}
>+
>+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
>+{
>+  clk_disable_unprepare(dev->hclk);
>+  clk_disable_unprepare(dev->aclk);
>+  clk_disable_unprepare(dev->pclk);
>+  clk_disable_unprepare(dev->clk);
>+}
>+
>+static int check_alignment(struct scatterlist *sg_src,
>+ struct scatterlist *sg_dst,
>+ int align_mask)
>+{
>+  int in, out, align;
>+
>+  in = IS_ALIGNED((u32)sg_src->offset, 4) &&
>+   IS_ALIGNED(sg_src->length, align_mask);
>+  if (sg_dst == NULL)
>+  return in;
>+  out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
>+IS_ALIGNED(sg_dst->length, align_mask);
>+  align = in && out;
>+
>+  return (align && (sg_src->length == sg_dst->length));
>+}
>+
>+static int rk_load_data(struct crypto_info_t *dev,
>+struct scatterlist *sg_src,
>+struct scatterlist *sg_dst)
>+{
>+  uint32_t count;
>+  int ret;
>+
>+  dev->aligned = dev->aligned ?
>+  check_alignment(sg_src, sg_dst, dev->align_size) :
>+  dev->aligned;
>+  if (dev->aligned) {
>+  count = min(dev->left_bytes, s

Re: [RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

2015-10-30 Thread LABBE Corentin 
On Fri, Oct 30, 2015 at 04:22:46PM +0800, Zain Wang wrote:
> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher 
> mode.
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/rk_crypto/Makefile  |   3 +
>  drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
>  drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
>  .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 
> +
>  5 files changed, 1190 insertions(+)
>  create mode 100644 drivers/crypto/rk_crypto/Makefile
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
>  create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c
> 
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index c3ced6f..00d103c 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
> diff --git a/drivers/crypto/rk_crypto/Makefile 
> b/drivers/crypto/rk_crypto/Makefile
> new file mode 100644
> index 000..0f62d87
> --- /dev/null
> +++ b/drivers/crypto/rk_crypto/Makefile
> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
> +rk_crypto_driver-objs := rk3288_crypto.o \
> +  rk3288_crypto_ablkcipher.o \
> diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c 
> b/drivers/crypto/rk_crypto/rk3288_crypto.c
> new file mode 100644
> index 000..fe55d7e
> --- /dev/null
> +++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
> @@ -0,0 +1,393 @@
> +/*
> + *Crypto acceleration support for Rockchip RK3288
> + *
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Author: Zain Wang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
> + */
> +
> +#include "rk3288_crypto.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct crypto_info_t *crypto_p;
> +
> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
> +{
> + if (clk_prepare_enable(dev->clk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
> + __func__, __LINE__);
> + return -ENOENT;
> + }
> + if (clk_prepare_enable(dev->aclk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
> + __func__, __LINE__);
> + goto err_aclk;
> + }
> + if (clk_prepare_enable(dev->hclk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
> + __func__, __LINE__);
> + goto err_hclk;
> + }
> + if (clk_prepare_enable(dev->pclk)) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
> + __func__, __LINE__);
> + goto err_pclk;
> + }
> + return 0;
> +
> +err_pclk:
> + clk_disable_unprepare(dev->hclk);
> +err_hclk:
> + clk_disable_unprepare(dev->aclk);
> +err_aclk:
> + clk_disable_unprepare(dev->clk);
> +
> + return -ENOENT;
> +}
Please return the error value given by clk_prepare_enable()

> +
> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
> +{
> + clk_disable_unprepare(dev->hclk);
> + clk_disable_unprepare(dev->aclk);
> + clk_disable_unprepare(dev->pclk);
> + clk_disable_unprepare(dev->clk);
> +}
> +
> +static int check_alignment(struct scatterlist *sg_src,
> +struct scatterlist *sg_dst,
> +int align_mask)
> +{
> + int in, out, align;
> +
> + in = IS_ALIGNED((u32)sg_src->offset, 4) &&
> +  IS_ALIGNED(sg_src->length, align_mask);
> + if (sg_dst == NULL)
> + return in;
> + out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
> +   IS_ALIGNED(sg_dst->length, align_mask);
> + align = in && out;
> +
> + return (align && (sg_src->length == sg_dst->length));
> +}
> +
> +static int rk_load_data(struct crypto_info_t *dev,
> +   struct scatterlist *sg_src,
> +   struct scatterlist *sg_dst)
> +{
> + uint32_t count;
u32 is prefered over uint32_t

> + int ret;
> +
> + dev->aligned = dev

Re: [RESEND PATCH 2/4] clk: rockchip: set an id for crypto clk

2015-10-30 Thread Heiko Stuebner 
Hi Zain,

Am Freitag, 30. Oktober 2015, 16:22:47 schrieb Zain Wang:
> set an id for crypto clk, so that it can be called in other part.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/clk/rockchip/clk-rk3288.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3288.c 
> b/drivers/clk/rockchip/clk-rk3288.c
> index 9040878..d74bd5d 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
> __initdata = {
>   RK3288_CLKGATE_CON(0), 4, GFLAGS),
>   GATE(0, "c2c_host", "aclk_cpu_src", 0,
>   RK3288_CLKGATE_CON(13), 8, GFLAGS),
> - COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
> + COMPOSITE_NOMUX(SRST_CRYPTO, "crypto", "aclk_cpu_pre", 0,

the id you want to use actually is a soft-reset index, not a clock-id.
You would need to add a real id, in this case with an sclk_ prefix.

>   RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
>   RK3288_CLKGATE_CON(5), 4, GFLAGS),
>   GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
> 

It should probably look more like below, but as suggested by Stephen Boyd
in another thread, we should coordinate with Chris to add more necessary clock
ids in one go:
 8< ---
diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..9fd9f5a 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
-   COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+   COMPOSITE_NOMUX(SCLK_CRYPTO, "sclk_crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..9e0a5e9 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_CRYPTO125
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
2.6.1

 8< ---
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/5] crypto: AF_ALG -- add setpubkey setsockopt call

2015-10-30 Thread Stephan Mueller 
Am Freitag, 30. Oktober 2015, 17:16:47 schrieb Marcel Holtmann:

Hi Marcel,

>Hi Stephan,
>
>> For supporting asymmetric ciphers, user space must be able to set the
>> public key. The patch adds a new setsockopt call for setting the public
>> key.
>> 
>> Signed-off-by: Stephan Mueller 
>> ---
>> crypto/af_alg.c | 14 +++---
>> include/crypto/if_alg.h |  1 +
>> 2 files changed, 12 insertions(+), 3 deletions(-)
>> 
>> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
>> index a8e7aa3..bf6528e 100644
>> --- a/crypto/af_alg.c
>> +++ b/crypto/af_alg.c
>> @@ -173,13 +173,16 @@ static int alg_bind(struct socket *sock, struct
>> sockaddr *uaddr, int addr_len) }
>> 
>> static int alg_setkey(struct sock *sk, char __user *ukey,
>> -  unsigned int keylen)
>> +  unsigned int keylen, bool pubkey)
>> {
>> 
>>  struct alg_sock *ask = alg_sk(sk);
>>  const struct af_alg_type *type = ask->type;
>>  u8 *key;
>>  int err;
>> 
>> +if (pubkey && !type->setpubkey)
>> +return -EOPNOTSUPP;
>> +
>> 
>>  key = sock_kmalloc(sk, keylen, GFP_KERNEL);
>>  if (!key)
>>  
>>  return -ENOMEM;
>> 
>> @@ -188,7 +191,10 @@ static int alg_setkey(struct sock *sk, char __user
>> *ukey,> 
>>  if (copy_from_user(key, ukey, keylen))
>>  
>>  goto out;
>> 
>> -err = type->setkey(ask->private, key, keylen);
>> +if (pubkey)
>> +err = type->setpubkey(ask->private, key, keylen);
>> +else
>> +err = type->setkey(ask->private, key, keyless);
>
>why is this kind of hackery needed? Why not just introduce alg_setpubkey to
>keep this a lot cleaner.

You are fully correct. I wanted to spare a re-implementation of the setkey 
function. But instead of that hack, having something like the following would 
be much cleaner:

setkey_common() {
...
heavy lifting
...
}

setpubkey() {
setkey_common(type->setpubkey)
}

setkey() {
setkey_common(type->setkey)
}

>> out:
>>  sock_kzfree_s(sk, key, keylen);
>> 
>> @@ -212,12 +218,14 @@ static int alg_setsockopt(struct socket *sock, int
>> level, int optname,> 
>>  switch (optname) {
>> 
>>  case ALG_SET_KEY:
>> +case ALG_SET_PUBKEY:
>>  if (sock->state == SS_CONNECTED)
>>  
>>  goto unlock;
>>  
>>  if (!type->setkey)
>>  
>>  goto unlock;
>> 
>> -err = alg_setkey(sk, optval, optlen);
>> +err = alg_setkey(sk, optval, optlen,
>> + (optname == ALG_SET_PUBKEY) ? true : false);
>> 
>>  break;
>
>Same here. Why not give ALG_SET_PUBKEY a separate case statement. Especially
>since you have to check type->setkey vs type->setpubkey.

Same here.

>>  case ALG_SET_AEAD_AUTHSIZE:
>>  if (sock->state == SS_CONNECTED)
>> 
>> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
>> index 018afb2..ca4dc72 100644
>> --- a/include/crypto/if_alg.h
>> +++ b/include/crypto/if_alg.h
>> @@ -49,6 +49,7 @@ struct af_alg_type {
>> 
>>  void *(*bind)(const char *name, u32 type, u32 mask);
>>  void (*release)(void *private);
>>  int (*setkey)(void *private, const u8 *key, unsigned int keylen);
>> 
>> +int (*setpubkey)(void *private, const u8 *key, unsigned int keylen);
>> 
>>  int (*accept)(void *private, struct sock *sk);
>>  int (*setauthsize)(void *private, unsigned int authorize);
>
>Regards
>
>Marcel

Thanks.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH 2/4] clk: rockchip: set an id for crypto clk

2015-10-30 Thread Zain Wang 
set an id for crypto clk, so that it can be called in other part.

Signed-off-by: Zain Wang 
---
 drivers/clk/rockchip/clk-rk3288.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..d74bd5d 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
-   COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+   COMPOSITE_NOMUX(SRST_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] crypto: RSA padding transform

2015-10-30 Thread Marcel Holtmann 
Hi Andrzej,

>>> I can see now that with all these padding schemes there will be more buffer
>>> copied on top of this, so I wonder if it still make sense.
>>> Herbert?
>> 
>> When the padding stuff comes into play, I think the SGL approach avoids
>> memcpy() invocations.
>> 
>> For example, Andrzej's approach currently is to copy the *entire* source data
>> into a buffer where the padding is added.
>> 
>> With SGLs, Andrzej only needs a buffer with the padding (which I would think
>> could even reside on the stack, provided some bounds checks are done), and
>> modify the SGL by preprending the padding buffer to the SGL with the source
>> data.
> 
> Yes, in the case of the padding schemes, using sgl's would actually
> save a memcpy both on encrypt/sign and decrypt/verify.  Whether it'd
> actually help I'm not sure -- the number of pointers you need to
> touch, etc. may add up to around 128/256 bytes of memory access
> anyway.

I think we have akcipher patches using sgl now. Would it make sense to update 
this patch against them.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel tainted while exporting shash context using af_alg interface

2015-10-30 Thread Harsh Jain 
Hi Stephan,

If we add sendmsg() in between 2 accept calls then the setkey problem
will happen?

handle->opfd = accept(handle->tfmfd, NULL, 0);
sendmsg()
handle->opfd = accept(handle->opfd, NULL, 0);
sendmsg()
handle->opfd = accept(handle->opfd, NULL, 0);

If yes, Then may be it is expected behavior and user is supposed to
set the key explicitly with some other system call.Why I am saying
this is. I remember somewhere in kernel code I read some comment
related to setkey operations.

In that case my patch should work. 1 doubt I have related to patch is
do I need to set "ctx->more" =1 after initialisation.

Correct me If I am wrong.


Thanks for your support.


regards
Harsh Jain

On Wed, Oct 28, 2015 at 4:53 PM, Stephan Mueller  wrote:
> Am Mittwoch, 28. Oktober 2015, 16:24:34 schrieb Harsh Jain:
>
> Hi Harsh,
>
>>Hi Stephan,
>>
>>I tried your patch on my machine. Kernel is not crashing. The openssl
>>break with this. Can you share HMAC program which you are suspecting
>>it will not work or do you already have some test written in
>>libkcapi/test.sh which will fail.
>
> See comments above test/kcapi-main.c:cavs_hash
>
>  * HMAC command line invocation:
>  * $ ./kcapi -x 3 -c "hmac(sha1)" -k 6e77ebd479da794707bc6cde3694f552ea892dab
> -p
> 31b62a797adbff6b8a358d2b5206e01fee079de8cdfc4695138bba163b4efbf30127343e7fd4fbc696c3d38d8f27f57c024b5056f726ceeb4c31d98e57751ec8cbe8904ee0f9b031ae6a0c55da5e062475b3d7832191d4057643ef5fa446801d59a04693e573a8159cd2416b7bd39c7f0fe63c599365e04d596c05736beaab58
>  * 7f204ea665666f5bd2b370e546d1b408005e4d85
>
> To do that, apply your patch and then
>
> 1. open lib/kcapi-kernel-if.c and change line 567 from
>
> handle->opfd = accept(handle->tfmfd, NULL, 0);
>
>
> to
>
> handle->opfd = accept(handle->tfmfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
>
> You will see that the hash commands will pass, the HMAC fails
>
> Without your patch, the kernel crashes (same as with your OpenSSL code).
>
> The reason is that setkey is applied on the TFM that is not conveyed to the
> subsequent TFMs generated with new accepts.
>>
>>
>>Regards
>>Harsh Jain
>>
>>On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller  wrote:
>>> Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
>>>
>>> Hi Harsh,
>>>
 However, any error in user space should not crash the kernel. So, a fix
 should be done. But I think your code is not correct as it solidifies a
 broken user space code.
>>>
>>> After thinking a bit again, I think your approach is correct after all. I
>>> was able to reproduce the crash by simply adding more accept calls to my
>>> test code. And I can confirm that your patch works, for hashes.
>>>
>>> *BUT* it does NOT work for HMAC as the key is set on the TFM and the
>>> subsequent accepts do not transport the key. Albeit your code prevents the
>>> kernel from crashing, the HMAC calculation will be done with an empty key
>>> as
>>> the setkey operation does not reach the TFM handle in the subordinate
>>> accept() call.
>>>
>>> So, I would think that the second accept is simply broken, for HMAC at
>>> least.
>>>
>>> Herbert, what is the purpose of that subordinate accept that is implemented
>>> with hash_accept? As this is broken for HMACs, should it be removed
>>> entirely?
>>>
>>> --
>>> Ciao
>>> Stephan
>>
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>>the body of a message to majord...@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> Ciao
> Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH 3/4] ARM: dts: rockchip: Add Crypto drivers for rk3288

2015-10-30 Thread Zain Wang 
Add Crypto drivers for rk3288 including crypto controller and dma clk.

Signed-off-by: Zain Wang 
---
 arch/arm/boot/dts/rk3288.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..1706706 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -170,6 +170,22 @@
};
};
 
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = <&cru ACLK_CRYPTO>,
+<&cru HCLK_CRYPTO>,
+<&cru SRST_CRYPTO>,
+<&cru ACLK_DMAC1>;
+
+   clock-names = "aclk_crypto",
+ "hclk_crypto",
+ "srst_crypto",
+ "apb_pclk";
+   status = "okay";
+   };
+
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

2015-10-30 Thread Zain Wang 
Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher mode.
The names registered are:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.

And other algorithms and platforms will be added later on.

Signed-off-by: Zain Wang 
---
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rk_crypto/Makefile  |   3 +
 drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
 drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
 .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 +
 5 files changed, 1190 insertions(+)
 create mode 100644 drivers/crypto/rk_crypto/Makefile
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c

diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..00d103c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto/
diff --git a/drivers/crypto/rk_crypto/Makefile 
b/drivers/crypto/rk_crypto/Makefile
new file mode 100644
index 000..0f62d87
--- /dev/null
+++ b/drivers/crypto/rk_crypto/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_RK3288) += rk_crypto_driver.o
+rk_crypto_driver-objs := rk3288_crypto.o \
+rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rk_crypto/rk3288_crypto.c 
b/drivers/crypto/rk_crypto/rk3288_crypto.c
new file mode 100644
index 000..fe55d7e
--- /dev/null
+++ b/drivers/crypto/rk_crypto/rk3288_crypto.c
@@ -0,0 +1,393 @@
+/*
+ *Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell/cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct crypto_info_t *crypto_p;
+
+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
+{
+   if (clk_prepare_enable(dev->clk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'clk'\n",
+   __func__, __LINE__);
+   return -ENOENT;
+   }
+   if (clk_prepare_enable(dev->aclk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
+   __func__, __LINE__);
+   goto err_aclk;
+   }
+   if (clk_prepare_enable(dev->hclk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
+   __func__, __LINE__);
+   goto err_hclk;
+   }
+   if (clk_prepare_enable(dev->pclk)) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'pclk'\n",
+   __func__, __LINE__);
+   goto err_pclk;
+   }
+   return 0;
+
+err_pclk:
+   clk_disable_unprepare(dev->hclk);
+err_hclk:
+   clk_disable_unprepare(dev->aclk);
+err_aclk:
+   clk_disable_unprepare(dev->clk);
+
+   return -ENOENT;
+}
+
+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
+{
+   clk_disable_unprepare(dev->hclk);
+   clk_disable_unprepare(dev->aclk);
+   clk_disable_unprepare(dev->pclk);
+   clk_disable_unprepare(dev->clk);
+}
+
+static int check_alignment(struct scatterlist *sg_src,
+  struct scatterlist *sg_dst,
+  int align_mask)
+{
+   int in, out, align;
+
+   in = IS_ALIGNED((u32)sg_src->offset, 4) &&
+IS_ALIGNED(sg_src->length, align_mask);
+   if (sg_dst == NULL)
+   return in;
+   out = IS_ALIGNED((u32)sg_dst->offset, 4) &&
+ IS_ALIGNED(sg_dst->length, align_mask);
+   align = in && out;
+
+   return (align && (sg_src->length == sg_dst->length));
+}
+
+static int rk_load_data(struct crypto_info_t *dev,
+ struct scatterlist *sg_src,
+ struct scatterlist *sg_dst)
+{
+   uint32_t count;
+   int ret;
+
+   dev->aligned = dev->aligned ?
+   check_alignment(sg_src, sg_dst, dev->align_size) :
+   dev->aligned;
+   if (dev->aligned) {
+   count = min(dev->left_bytes, sg_src->length);
+   dev->left_bytes -= count;
+
+   ret = dma_map_sg(dev->dev, sg_src, 1, DMA_TO_DEVICE);
+   if (!ret

[RESEND PATCH 4/4] crypto: rk_crypto - add DT bindings documentation

2015-10-30 Thread Zain Wang 
Add DT bindings documentation for the rk3288 crypto drivers.

Signed-off-by: Zain Wang 
---
 .../devicetree/bindings/crypto/rk-crypto.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt

diff --git a/Documentation/devicetree/bindings/crypto/rk-crypto.txt 
b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
new file mode 100644
index 000..1e50768
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rk-crypto.txt
@@ -0,0 +1,31 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: should be "rockchip,crypto"
+- reg: base physical address of the engine and length of memory mapped
+   region.
+- interrupts: interrupt number
+- clocks: clock specifiers
+- clock-names: "aclk_crypto" used to clock data
+  "hclk_crypto" used to clock data
+  "srst_crypto" used to clock crypto accelerator
+  "apb_pclk"used to clock dma
+-status: Enable
+
+Examples:
+
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = <&cru ACLK_CRYPTO>,
+<&cru HCLK_CRYPTO>,
+<&cru SRST_CRYPTO>,
+<&cru ACLK_DMAC1>;
+
+   clock-names = "aclk_crypto",
+ "hclk_crypto",
+ "srst_crypto",
+ "apb_pclk";
+   status = "okay";
+   };
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH 0/4] Crypto: add crypto accelerator support for rk3288

2015-10-30 Thread Zain Wang 
This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc),
and the more algorithms or new hash drivers will be added later on.

Zain Wang (4):
  Crypto: Crypto driver support aes/des/des3 for rk3288
  clk: rockchip: set an id for crypto clk
  ARM: dts: rockchip: Add Crypto drivers for rk3288
  crypto: rk_crypto - add DT bindings documentation

 .../devicetree/bindings/crypto/rk-crypto.txt   |  31 ++
 arch/arm/boot/dts/rk3288.dtsi  |  16 +
 drivers/clk/rockchip/clk-rk3288.c  |   2 +-
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rk_crypto/Makefile  |   3 +
 drivers/crypto/rk_crypto/rk3288_crypto.c   | 393 
 drivers/crypto/rk_crypto/rk3288_crypto.h   | 291 
 .../crypto/rk_crypto/rk3288_crypto_ablkcipher.c| 502 +
 8 files changed, 1238 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/rk-crypto.txt
 create mode 100644 drivers/crypto/rk_crypto/Makefile
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.c
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto.h
 create mode 100644 drivers/crypto/rk_crypto/rk3288_crypto_ablkcipher.c

-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/5] crypto: AF_ALG -- add setpubkey setsockopt call

2015-10-30 Thread Marcel Holtmann 
Hi Stephan,

> For supporting asymmetric ciphers, user space must be able to set the
> public key. The patch adds a new setsockopt call for setting the public
> key.
> 
> Signed-off-by: Stephan Mueller 
> ---
> crypto/af_alg.c | 14 +++---
> include/crypto/if_alg.h |  1 +
> 2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index a8e7aa3..bf6528e 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -173,13 +173,16 @@ static int alg_bind(struct socket *sock, struct 
> sockaddr *uaddr, int addr_len)
> }
> 
> static int alg_setkey(struct sock *sk, char __user *ukey,
> -   unsigned int keylen)
> +   unsigned int keylen, bool pubkey)
> {
>   struct alg_sock *ask = alg_sk(sk);
>   const struct af_alg_type *type = ask->type;
>   u8 *key;
>   int err;
> 
> + if (pubkey && !type->setpubkey)
> + return -EOPNOTSUPP;
> +
>   key = sock_kmalloc(sk, keylen, GFP_KERNEL);
>   if (!key)
>   return -ENOMEM;
> @@ -188,7 +191,10 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
>   if (copy_from_user(key, ukey, keylen))
>   goto out;
> 
> - err = type->setkey(ask->private, key, keylen);
> + if (pubkey)
> + err = type->setpubkey(ask->private, key, keylen);
> + else
> + err = type->setkey(ask->private, key, keyless);

why is this kind of hackery needed? Why not just introduce alg_setpubkey to 
keep this a lot cleaner.

> 
> out:
>   sock_kzfree_s(sk, key, keylen);
> @@ -212,12 +218,14 @@ static int alg_setsockopt(struct socket *sock, int 
> level, int optname,
> 
>   switch (optname) {
>   case ALG_SET_KEY:
> + case ALG_SET_PUBKEY:
>   if (sock->state == SS_CONNECTED)
>   goto unlock;
>   if (!type->setkey)
>   goto unlock;
> 
> - err = alg_setkey(sk, optval, optlen);
> + err = alg_setkey(sk, optval, optlen,
> +  (optname == ALG_SET_PUBKEY) ? true : false);
>   break;

Same here. Why not give ALG_SET_PUBKEY a separate case statement. Especially 
since you have to check type->setkey vs type->setpubkey.

>   case ALG_SET_AEAD_AUTHSIZE:
>   if (sock->state == SS_CONNECTED)
> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
> index 018afb2..ca4dc72 100644
> --- a/include/crypto/if_alg.h
> +++ b/include/crypto/if_alg.h
> @@ -49,6 +49,7 @@ struct af_alg_type {
>   void *(*bind)(const char *name, u32 type, u32 mask);
>   void (*release)(void *private);
>   int (*setkey)(void *private, const u8 *key, unsigned int keylen);
> + int (*setpubkey)(void *private, const u8 *key, unsigned int keylen);
>   int (*accept)(void *private, struct sock *sk);
>   int (*setauthsize)(void *private, unsigned int authorize);

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html