headers
Phil Sutter | 25 May 18:08
Favicon

RFC: support for MV_CESA with TDMA

Hi,

The following patch series adds support for the TDMA engine built into
Marvell's Kirkwood-based SoCs, and enhances mv_cesa.c in order to use it
for speeding up crypto operations. Kirkwood hardware contains a security
accelerator, which can control DMA as well as crypto engines. It allows
for operation with minimal software intervenience, which the following
patches implement: using a chain of DMA descriptors, data input,
configuration, engine startup and data output repeat fully automatically
until the whole input data has been handled.

The point for this being RFC is backwards-compatibility: earlier
hardware (Orion) ships a (slightly) different DMA engine (IDMA) along
with the same crypto engine, so in fact mv_cesa.c is in use on these
platforms, too. But since I don't possess hardware of this kind, I am
not able to make this code IDMA-compatible. Also, due to the quite
massive reorganisation of code flow, I don't really see how to make TDMA
support optional in mv_cesa.c.

Greetings, Phil
Permalink | Reply | 13 comments |
headers
Phil Sutter | 25 May 15:54
Favicon

[PATCH 1/4] mv_cesa: add an expiry timer in case anything goes wrong

The timer triggers when 500ms have gone by after triggering the engine
and no completion interrupt was received. The callback then tries to
sanitise things as well as possible.

Signed-off-by: Phil Sutter <phil.sutter <at> viprinet.com>
---
 drivers/crypto/mv_cesa.c |   41 +++++++++++++++++++++++++++++++----------
 1 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c
index e6ecc5f..8327bed 100644
--- a/drivers/crypto/mv_cesa.c
+++ b/drivers/crypto/mv_cesa.c
@@ -23,6 +23,7 @@

 #define MV_CESA	"MV-CESA:"
 #define MAX_HW_HASH_SIZE	0xFFFF
+#define MV_CESA_EXPIRE		500 /* msec */

 /*
  * STM:
@@ -85,6 +86,7 @@ struct crypto_priv {
 	spinlock_t lock;
 	struct crypto_queue queue;
 	enum engine_status eng_st;
+	struct timer_list completion_timer;
 	struct crypto_async_request *cur_req;
 	struct req_progress p;
 	int max_req_size;
@@ -136,6 +138,29 @@ struct mv_req_hash_ctx {
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mathias Krause | 24 May 11:13

[PATCH] crypto: sha1 - use Kbuild supplied flags for AVX test

Commit ea4d26ae ("raid5: add AVX optimized RAID5 checksumming")
introduced x86/ arch wide defines for AFLAGS and CFLAGS indicating AVX
support in binutils based on the same test we have in x86/crypto/ right
now. To minimize duplication drop our implementation in favour to the
one in x86/.

Signed-off-by: Mathias Krause <minipli <at> googlemail.com>
---

This should be applied to cryptodev-2.6.git after it contains the above
mentioned commit, e.g. after cryptodev-2.6.git rebased to/merged v3.5-rc1.

 arch/x86/crypto/Makefile          |    7 -------
 arch/x86/crypto/sha1_ssse3_asm.S  |    2 +-
 arch/x86/crypto/sha1_ssse3_glue.c |    6 +++---
 3 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index e191ac0..479f95a 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -34,12 +34,5 @@ salsa20-x86_64-y := salsa20-x86_64-asm_64.o salsa20_glue.o
 serpent-sse2-x86_64-y := serpent-sse2-x86_64-asm_64.o serpent_sse2_glue.o

 aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o
-
 ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o
-
-# enable AVX support only when $(AS) can actually assemble the instructions
-ifeq ($(call as-instr,vpxor %xmm0$(comma)%xmm1$(comma)%xmm2,yes,no),yes)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Horia Geanta | 21 May 18:53
Favicon

[RFC/PATCH] crypto: talitos - replace the tasklet implementation with NAPI

Hi,

During performance measurements & optimization phase, we found out that we get
better numbers (in the range of 9-10%) by using the NAPI approach for the
crypto engine interrupt mechanism instead of tasklet.
We found out that for the tasklet-based interrupt mechanism, we were facing
imbalanced processing - NET RX softirq was running more frequently than the
crypto tasklet.

The patch replaces the tasklet-based implementation with NAPI. It is based on
latest crypto-2.6 tree.

I am aware of the fact that using NAPI for anything else than net devices might
be frowned upon, that's why I am adding the netdev folks to comment, advise.

Thanks,
Horia

From 30f6247fa5ada7e53523492ca4e70b61e3f5aeeb Mon Sep 17 00:00:00 2001
From: Horia Geanta <horia.geanta <at> freescale.com>
Date: Wed, 2 May 2012 18:40:03 +0300
Subject: [RFC/PATCH] crypto: talitos - replace the tasklet implementation with NAPI

This patch updates the current tasklet implement to NAPI so as
the system is more balanced in the terms that the packet submission
and the packet forwarding after being processed can be done at
the same priority.

Signed-off-by: Sandeep Malik <Sandeep.Malik <at> freescale.com>
Signed-off-by: Horia Geanta <horia.geanta <at> freescale.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
平民化的出国留学服务 | 21 May 13:08

免交40万留学保证金，打造平民化的出国留学服务，爱尔兰名校等您来深造

您还在为家庭不够富裕，而不能让品学兼优的孩子出国深造而苦恼吗？
您还在为国内教育资源分配严重不均，而不能让自己的孩子获得理想的教育环境而发愁吗？

免交40万留学保证金，打造平民化的出国留学服务！
让工薪家庭孩子也可以一圆出国留学梦！

爱尔兰名校等您来深造！
想了解详情的请联系QQ: 2636882155   或者立即回复邮箱: 2636882155 <at> qq.com
想了解详情的请联系QQ: 2636882155   或者立即回复邮箱: 2636882155 <at> qq.com
想了解详情的请联系QQ: 2636882155   或者立即回复邮箱: 2636882155 <at> qq.com
 
 
现诚招全国各地出国留学顾问。
零风险！高回报！共享朝阳般的教育产业大蛋糕！
请联系QQ: 2636882155
请联系QQ: 2636882155
请联系QQ: 2636882155
Permalink | Reply | 0 comments |
headers
Mr.Saeed Ahmed. | 9 May 08:27

Will You Be Trusted?


Dear Friend,

As you read this, I don't want you to feel sorry for me,because, I
believe everyone will die someday,and am contacting you because
I really do need your help and I want you to help me with all your
effort and time for just seven to fourteen workings days of your time.I
want you to be honest and truthful with me that you will help me
with my last wish as a dying man.

Please i need a reliable person who will usethe Money($18 milliondollars)to
build orphanage home or charity organization.

Please kindly reply to my most confidential email if you are really
interested in helping me please: mr.saeed01 <at> linuxmail.org

God be with you.

Mr.Saeed Ahmed.

----------------------------------------------------------------
FME Webmail
www.educacao.niteroi.rj.gov.br
Permalink | Reply | 0 comments |
headers
Rodel Miguel | 14 May 06:46
Picon

CRYPTO_ALG_TYPE_ABLKCIPHER concepts guide

Hello Experts,

I am writing a driver for my AES encryption hardware.  It is a
hardware which can do encryption of 4k bytes of data every time.  I
have tried creating a driver based on geode-aes.c code which uses the
CRYPTO_ALG_TYPE_BLKCIPHER interface.  While testing the driver, I
found out that the limit for this type of API is 512 bytes of data
sent on every encryption/decryption call.  I have sent the dm-crypt
mailing list a query about this and they said that this limit cannot
be changed at the moment.

I am now looking at a different type of crypto API which is the
CRYPTO_ALG_TYPE_ABLKCIPHER but I could not find any
tutorials/documentation which would guide to the minimum code required
to create this type of driver.  I looked at the mv_cesa.c but I am
still quite lost at the procedures in doing this type of driver.  The
reason I want to explore this driver is that I am assuming that the
CRYPTO_ALG_TYPE_ABLKCIPHER type of interface would allow me to collect
4k bytes of data first before doing DMA to my hardware for
encryption/decryption.  Is this a correct assumption?

Is there a good documentation that would lay out the requirements to
write an asynchronous type of block cipher?

Thank you very much for your help!

Kind Regards,
Rodel
Permalink | Reply | 0 comments |
headers
Alexander Clouter | 12 May 10:45
Picon
Favicon

[PATCH] crypto: mv_cesa requires on CRYPTO_HASH to build

Without CRYPTO_HASH being selected, mv_cesa has a lot of hooks
into undefined exports.
----
  MODPOST 81 modules
  Kernel: arch/arm/boot/Image is ready
  AS      arch/arm/boot/compressed/head.o
  GZIP    arch/arm/boot/compressed/piggy.gzip
  CC      arch/arm/boot/compressed/misc.o
  CC      arch/arm/boot/compressed/decompress.o
ERROR: "crypto_ahash_type" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_final" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_register_ahash" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_unregister_ahash" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_update" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_digest" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_shash_setkey" [drivers/crypto/mv_cesa.ko] undefined!
ERROR: "crypto_alloc_shash" [drivers/crypto/mv_cesa.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
make: *** Waiting for unfinished jobs....
----

Signed-off-by: Alexander Clouter <alex <at> digriz.org.uk>
---
 drivers/crypto/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e707979..07dbc77 100644
--- a/drivers/crypto/Kconfig
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rodel Miguel | 11 May 18:58
Picon

Writing Asynchronous Block Ciphers

Hello,

I would like to know if anyone has a tutorial/document link in writing
a CRYPTO_ALG_TYPE_ABLKCIPHER crypto device driver?  I am looking at
drivers/cipher/mv_cesa.c but there are lots of things going on which
are hardware context related.  I would like to know what the minimum
requirements for an asynchronous block cipher drivers are before I
hand over (DMA) the collected data to my encryption hardware.

Thanks in advance for your help!

Kind Regards,
Rodel
Permalink | Reply | 0 comments |
headers
Jussi Kivilinna | 11 May 15:00
Picon
Picon
Favicon

[PATCH 1/2] crypto: aesni-intel: use crypto_[un]register_algs

Combine all crypto_alg to be registered and use new crypto_[un]register_algs
functions. Simplifies init/exit code and reduce object size.

Cc: Huang Ying <ying.huang <at> intel.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna <at> mbnet.fi>
---
 arch/x86/crypto/aesni-intel_glue.c |  727 +++++++++++++++---------------------
 1 file changed, 305 insertions(+), 422 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index c799352..20c6220 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -222,27 +222,6 @@ static void aes_decrypt(struct crypto_tfm *tfm, u8 *dst, const u8 *src)
 	}
 }

-static struct crypto_alg aesni_alg = {
-	.cra_name		= "aes",
-	.cra_driver_name	= "aes-aesni",
-	.cra_priority		= 300,
-	.cra_flags		= CRYPTO_ALG_TYPE_CIPHER,
-	.cra_blocksize		= AES_BLOCK_SIZE,
-	.cra_ctxsize		= sizeof(struct crypto_aes_ctx)+AESNI_ALIGN-1,
-	.cra_alignmask		= 0,
-	.cra_module		= THIS_MODULE,
-	.cra_list		= LIST_HEAD_INIT(aesni_alg.cra_list),
-	.cra_u	= {
-		.cipher	= {
-			.cia_min_keysize	= AES_MIN_KEY_SIZE,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kasatkin, Dmitry | 11 May 10:58
Picon
Favicon

async hash & hmac

Hello,

When allocating hmac like: crypto_alloc_ahash("hmac(sha1)", ..),
it is actually fallsback to  "shash" hmac and software shash hash
implementation..
Even when HW accelerator provides AHASH it will not be used with hmac.

Basically HW driver needs to provide its own implementation for async
hmac, like I did for omap-sham.

		.cra_name		= "hmac(sha1)",
		.cra_driver_name	= "omap-hmac-sha1",

Is that correct, right?

Thanks.

- Dmitry
Permalink | Reply | 1 comment |

Gmane